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.
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.pemNow 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.
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."
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:143will 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/imapdWill 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
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