The newest version of Stunnel addresses some of the most oft cited
requests:
1) Stunnel Configuration files instead of command line options;
2) A GUI for Windows users;
3) Ability to run as a native Windows service;
4) Ability to handle multiple simultaneous connections;
5) Stunnel can now chroot for added security;
6) X509 cert and key now can be stored in separate files;
7) Confusing certificate verification source defaults removed[3];
8) Ability to work well even with the buggy and SSL spec-violating
Microsoft software;
9) 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.
[8] http://www.maximus.com/
