Paranoid Penguin - Rehabilitating Clear-Text Network Applications with Stunnel

The world is full of network applications that get things done, have withstood the test of time and have rotten security. Telnet? Brilliant in its simplicity and versatility, but it transmits your login credentials in clear text. rcp? Ever so ubiquitous and scriptable, but rhosts-based authentication's time has come and gone, thanks to IP spoofing.

Sure, you can swap those old warhorses for their encrypted successors—SSH instead of telnet and scp or rsync-over-SSH for rcp. Or, you can build an all-purpose IPSec tunnel to each remote host with which you communicate. But the latter often is overkill, and the former is easier said than done if your choice of applications in a given scenario isn't completely within your control. Surely there's a way to add strong encryption to legacy network applications.

Consider the mighty SSL wrapper, Stunnel. This month, I explain how to use Stunnel 4.0 in tandem with OpenSSL to bring your legacy applications into the modern era, security-wise. And what about wireless? If you're compelled to use a clear-text network application over a weakly secured wireless medium, such as 802.11b, can Stunnel help? Read on.

You need to understand two things in order to use Stunnel. First, know how your network application uses the network. If it's a simple single-TCP-port application such as telnet, which does all its listening on TCP 23, Stunnel works. If it uses UDP, the portmapper service or any other dynamic port-allocation scheme, Stunnel can't help you. For example, RPC applications don't work, because they use portmapper. FTP uses TCP 21 for control traffic but dynamically assigns arbitrary high ports for data connections, so it's also disqualified.

Second, you need to understand the basics of public key cryptography but not necessarily the ins and outs of X.509 or Public Key Infrastructures. I've described how this works in several previous columns, such as “The 101 Uses of OpenSSH, Part II” [LJ, January 2001]. For now, suffice it to say that in public key cryptography, each participant has two keys: a public key that you share with the other participants and a private key that only you possess. Other people use your public key to encrypt things that they want only you to see; you use your private key to decrypt those things.

Digital signatures work backward from encryption. If you sign something with your private key, anybody can use your public key to verify that the signature was generated with your private key and therefore by you. Again, this depends on only you possessing your private key, no matter how many people have copies of your public key.

In the X.509 world, we call the public key a certificate, which, technically, is a public key bundled with digitally signed information about the public key's owner, including name and e-mail address. We call the private key simply the key. Somewhat confusingly, we sometimes refer to both of them, together, as a certificate. Context helps: when I talk about a passphrase-free certificate, you know I'm talking about a combined key/certificate because the certificate itself, being a public key, can't have a passphrase.

That's by far the most concise explanation I've ever given of public key cryptography and X.509. If it isn't enough for you to decipher the rest of this article, read the Stunnel FAQ or the mighty RSA Crypto FAQ (see the on-line Resources section) for more information. Now it's time to plunge into Stunnel proper.

Chances are, your Linux distribution of choice includes a binary package for Stunnel. Recent releases of SuSE, Fedora and Red Hat Enterprise all include Stunnel version 4. Debian 3.0 (Woody) includes Stunnel version 3.22.

On the one hand, 3.22 is a stable version that's well documented and well understood. On the other hand, Stunnel version 4 is a major rewrite that, among other things, allows for easier management of multiple tunnels. It's the version I'm covering here. If you run Debian, I think it's worth your while to download the latest Stunnel source and compile it yourself.

Compiling Stunnel on any Linux distribution is quick and easy. First, make sure you've already got your distribution's packages for OpenSSL, probably called openssl; OpenSSL development libraries, openssl-devel or libssl096-dev; and TCPwrapper development libraries, libwrap0-dev on Debian, included as part of SuSE's and Fedora's base installations. Then, unpack Stunnel's source code tarball and do a quick:

./configure && make && make install

If for some reason that doesn't work, entering ./configure --help lists advanced precompile configuration options you can pass to the configure script. Once you've installed Stunnel, it's time to create some certificates and start tunneling.

Most of what follows applies only to Stunnel v.4.0.0 and later. If you choose to use, for example, Debian's Stunnel 3.22 package, you need to refer to the documentation included with that package or to the examples on the Stunnel Web site (see Resources); most of that Web site still covers the older version.