Stunnel 4.00 Builds on Prior Success
By Bri Hatch.
Summary: The recent release of Stunnel version 4.00 picks up where previous versions left off by improving encryptions capabilities and simplifying installation and configuration.
Late last week, the newest version of Stunnel[1], the secure SSL wrapper, was released. Stunnel encapsulates cleartext protocols within strong SSL encryption and can be used to protect pretty much any standard[2] TCP connection, from your mail protocol (POP, IMAP, SMTP) to your own customized application. Stunnel runs on many different operating systems from Linux and other Unix-like systems (*BSD, Solaris, etc) to Windows.
The newest version of Stunnel addresses some of the most oft cited requests:
- Stunnel Configuration files instead of command line options;
- A GUI for Windows users;
- Ability to run as a native Windows service;
- Ability to handle multiple simultaneous connections;
- Stunnel can now chroot for added security;
- X509 cert and key now can be stored in separate files;
- Confusing certificate verification source defaults removed[3];
- Ability to work well even with the buggy and SSL spec-violating Microsoft software;
- Ability to delay DNS lookups until connection time. (Good for daemons on dialup machines.)
This version was in the works for some time and if you've been turned off by Stunnel before, then now's the time to take a look at it again. Now that it uses a configuration file instead of (excessive) command line options, it is much easier to create and understand the configuration. So, let's see a few example.
Say your ISP supports IMAP over SSL, but you are not using a mail client that has SSL support. The mailserver is probably listening on two ports, 143 (IMAP) and 993 (IMAP+SSL). You simply set up Stunnel on your local machine to listen on a local port, say 1143. Stunnel will accept the cleartext IMAP connection on this port, SSL encrypt it, and send it to port 993 on the mail server. The connection is in the clear only from your mail client to the local Stunnel process - everywhere across the Internet it is encrypted, meaning your mail and your password is protected from prying eyes.
Here's what the syntax would have been using Stunnel-3.x:
$ stunnel -d 1143 -c -r mailserver.my_isp.com:993 -N imaps
That translates to:
-d ... Listen on port 1143 for inbound connections. -c Act as an SSL client. -r ... Connect to mailserver:993 -N ... Use 'imaps' as the service name for TCP Wrapper rules[4].
Using the new Stunnel configuration file syntax you'd have the following:
$ cat stunnel.conf client = yes [imaps] accept = 1143 connect = mailserver.my_isp.com:143
And then simply run stunnel:
$ stunnel /path/to/stunnel.conf
You will need to configure your mail client to connect to the new port (1143) on localhost. Your mail program will think it's talking to localhost, but Stunnel will be transparently encrypting your data to the server.
Conversely, if you ran an IMAP server and wanted to support SSL clients, you'd run stunnel with the following stunnel.conf:
$ cat stunnel.conf client = no cert = /path/to/stunnel.pem [imaps] accept = 993 connect = 143
That tells Stunnel to act as an SSL server. It will accept SSL connections on port 993 and redirect them after decryption to the local port 143. If your IMAP server is normally run by inetd/xinetd, you can even optimize this a bit more. Instead of shuttling the decrypted packets to port 143 launch the IMAP server from Stunnel directly:
$ cat stunnel.conf client = no cert = /path/to/stunnel.pem [imaps] accept = 993 exec = /usr/sbin/imapd
This way imapd is launched directly from Stunnel - no wasted cpu cycles and network activity by talking to imapd through inetd/xinetd. If you wanted to support encryption for other protocols too, you just add new service entries to the file. (I'll include some other sample Stunnel configuration options above to make the example more realistic.)
$ cat stunnel.conf # Global Options client = no cert = /path/to/stunnel.cert key = /path/to/stunnel.key debug = daemon.info pid = /var/run/stunnel.pid socket = l:SO_LINGER=1:60 # Service specific configurations [imaps] accept = 993 exec = /usr/sbin/imapd execargs = imapd [pop3s] accept = 995 exec = /usr/sbin/qpopper execargs = qpopper [nntps] accept = 563 connect = 119
Previously you'd need to run several Stunnel daemons, each with a rather hideous set of command line options in order to support the three protocols here (IMAP, POP, and NNTP).
If you've been looking for an easy way to add encryption to your daily life, doing it with Stunnel has gotten even easier. And you can even tell your friends who use Windows[6] that Stunnel now has a GUI and they can be secure[7] as well.
Many thanks go out to Maximus[8] who sponsored the new features. It's always good to see a company helping Open Source products flourish.
NOTES
[1] http://stunnel.mirt.net and http://www.stunnel.org
[2] The main requirements are that the protocol is TCP (not UDP, for example) and does not rely on out-of-band data (OOB) and does not have dynamic channels. FTP, for example, creates and destroys data channels for each transfer, and is not easily protectable with Stunnel.
[3] Said yours introduced confusing defaults truly, and I sincerely apologize. Endless thanks to Mike for destroying that overly 'helpful' logic...
[4] TCP Wrappers use /etc/hosts.allow and /etc/hosts.deny to determine if a connection should be allowed. See the tcpd and hosts_access man pages for more information.
[5] Another option would be to run Stunnel on the local IMAP port (143) and point your mail client to 'localhost'. On Unix, Stunnel would need to be run by root to bind this port, on Windows this is not required.
[6] Wait: if they're using Windows, why are you friends?
[7] Well, as secure as you can be given the platform.
Bri Hatch is Chief Hacker at Onsight, Inc. and author of Hacking Linux Exposed and Building Linux VPNs. He has used cryptographic protocols exclusively since 1992. He changes his passwords daily, and never uses anything less than fifty characters. His ATM pin, however, is 123. Bri can be reached at bri@hackinglinuxexposed.com.
Copyright Bri Hatch, 2002.
This article was first published here in ITworld.com Inc., 118 Turnpike Rd., Southborough, MA 01772 on 10-Sep-2002.