Wrapping POP/IMAP/SMTP stunnel

This was written using stunnel 3.8 as a reference.

To start with, you'll need stunnel. Compilation and installation follow the usual methods. It will install in /usr/local and will create /usr/local/var/stunnel for its use. You can use the stunnel.pem certificate it installs in /usr/local/ssl/certs for testing, it uses a common name of localhost. This certificate is also the default for stunnel, so it makes testing things a little easier.

You should place your certificates that you've created somewhere with minimum privileges, and the certificates cannot have any group or other permission bits set. The reasons for this become apparent in a moment. It is helpful to name the certificates something useful, like mail.pem for the mail server's certificate, or the name of the service it is going to wrap.

Removing the passphrase

Now things get a bit obfuscated due to a lack of documentation. You have this wonderful x509 certificate good for SSL encryption. However, this cannot be used with stunnel in its current form because it is protected by a passphrase. What must be done is to provide the decrypted request certificate with the signed certificate so stunnel and the underlying OpenSSL libraries can use it without the passphrase. The filenames in the below examples assume use of the CA.sh script, but are fairly self explanatory. To decrypt the request certificate, use the following command. It will prompt you for the request certificate's passphrase.

openssl rsa -in newreq.pem -out decryptedcert.pem
Now you concatenate decryptedcert.pem with newcert.pem (the signed certificate) and the resulting file is usable for our purposes. This is why stunnel enforces root only permissions on the certificate files.

Using stunnel

The stunnel program can be run as a daemon or from inetd. Running it from inetd is suboptimal. The author says, "It's slow (SSL needs to be initialized every connection), does not support session cache and will use more memory on heavy load."

Standalone daemon

The two ways for stunnel to wrap a given service are for stunnel to launch the daemon it's wrapping, or proxy to the port the unencrypted service is running on (if at all).

For example, if you have an imapd running on the standard imap port:

stunnel -p /usr/local/ssl/certs/stunnel.pem -d 993 -r localhost:143
will run stunnel using the certificate file specified by the -p option on the port specified by -d and proxy for the daemon running on localhost port 143. While running
stunnel -p /usr/local/ssl/certs/stunnel.pem -d 993 -l /usr/sbin/imapd
Will accomplish the same end result, but will fire off the daemon specified by -l it's self rather than connect to one that is already running.

This method uses similar syntax to the standalone method, save that you do not specify the port number since inetd handles that. Here is an inetd example:

imaps stream tcp nowait root /usr/local/sbin/stunnel stunnel -l /usr/sbin/imapd imapd

SSL ports

Listed below are the IANA assigned ports for SSL services. This is in /etc/services format.

nsiiops      261/tcp   # IIOP Name Service over TLS/SSL
https        443/tcp   # http protocol over TLS/SSL
smtps        465/tcp   # smtp protocol over TLS/SSL (was ssmtp)
nntps        563/tcp   # nntp protocol over TLS/SSL (was snntp)
imap4-ssl    585/tcp   # IMAP4+SSL (use 993 instead)
sshell       614/tcp   # SSLshell
ldaps        636/tcp   # ldap protocol over TLS/SSL (was sldap)
ftps-data    989/tcp   # ftp protocol, data, over TLS/SSL
ftps         990/tcp   # ftp protocol, control, over TLS/SSL
telnets      992/tcp   # telnet protocol over TLS/SSL
imaps        993/tcp   # imap4 protocol over TLS/SSL
ircs         994/tcp   # irc protocol over TLS/SSL
pop3s        995/tcp   # pop3 protocol over TLS/SSL (was spop3)
msft-gc-ssl  3269/tcp  # Microsoft Global Catalog with LDAP/SSL

It is also worth while to note that if you have libwrap installed, stunnel will use it.

There are some instructions for chrooting stunnel on RedHat at http://www.etherboy.com/stunnel/stunnelchroot

Back to main page

Valid HTML 4.0!
Oct 26, 2000