sslwrap

sslwrap is a simple Unix service that sits over any simple TCP service such as POP3, IMAP, SMTP, and encrypts all of the data on the connection using TLS/SSL. It uses ssleay to support SSL version 2 and 3. It can run out of inetd. It can also encrypt data for services located on another computer.

It works with the servers you already have, and does not require any modifications to your existing servers.

In this document:

Installation

Just follow these steps to build sslwrap. 

Make ssleay

You will need to get and build OpenSSL or ssleay. OpenSSL is available from www.openssl.org. The ssleay FAQ lists the current mirror locations for ssleay. Just follow the instructions to build it. sslwrap assumes that the libraries will be in /usr/local/ssl/lib and the includes in /usr/local/ssl/include. These are the default locations for the Makefiles included with ssleay.

Note that in the U.S. it appears that you must link with RSAREF from RSA Data Security, Inc. instead of using the ssleay public key algorithms. This is described in the ssleay documentation. There may be additional use restrictions imposed by the RSAREF license.

sslwrap was tested with ssleay 0.8.1 and 0.9.0b and OpenSSL 0.9.3b, and OpenSSL 0.9.4.

Make sslwrap

You can get sslwrap source as a tar/gzip file via HTTP here:

http://www.rickk.com/sslwrap/sslwrap.tar.gz

The file is approximately 20K.

Then unzip and untar the files:

gunzip sslwrap.tar.gz
tar xf sslwrap.tar

Just do a "make" and (hopefully) the file "sslwrap" will be created. The Makefile assumes gcc; you will need to edit it for other compilers and options. There isn't much in there, though.

If you are using ssleay instead of OpenSSL comment out the first OPENSSL= line and uncomment out the second one in Makefile.

If you are using Solaris you will probably need to remove the "#" from the beginning of the line that reads "EXTLIBS = -lxnet" in the Makefile.

I copied the built version of sslwrap to /usr/local/sbin, but you may prefer a different location. It doesn't matter where is is, as long as your inetd.conf file points to the location you put the file.

Get a certificate

You need a certificate for your server. You can make a self-signed certificate with no encryption by using these commands from the ssleay FAQ:

cd /usr/local/ssl/certs
/usr/local/ssl/bin/req -new -x509 -nodes -out server.pem -keyout server.pem -days 365
ln -s server.pem `/usr/local/ssl/bin/x509 -noout -hash < server.pem`.0

There is information on getting a real server certificate from a Certificate Authority (CA) in the ssleay FAQ. Note that Verisign previously would not issue a certificate for a server using ssleay; though this may have changed.

There is a security problem with sslwrap: it requires an unencrypted private key. Since sslwrap runs out of inetd it is not particularly convenient to prompt the server operator for the private key password. I'm only using sslwrap for the link encryption (not server identity verification), so I'm using a self-signed certificate, and I'm not as concerned about the private key being stolen.

You can use self-signed certificates using Netscape Navigator 2.0 or later, or Microsoft Internet Explorer 3.02 or later. The client will need to go through several dialogs to add the certificate, either for the session or until expiration.

You will want to chmod 600 your certificate file so that normal users won't be able to read your unencrypted private key.

Also, when req prompts for you "Common Name (eg, YOUR name) []" enter your host name, not your name, for a server certificate. Netscape 3.0.2 and later allow wildcards (i.e. "*.acme.com") but Microsoft Internet Explorer 4.0 does not. The hostname can be an IP CNAME, but must match whatever you specified to connect to (in the https URL, mail configuration, etc.) or you will get a warning dialog in the client.

You can also use sslwrap without a certificate; to do this use the -nocert option in the command line for either inetd or daemon mode.

Add to /etc/services

According to IANA, the following port numbers have been assigned for SSL:

https 443/tcp     # http protocol over TLS/SSL
smtps 465/tcp     # smtp protocol over TLS/SSL
nntps 563/tcp     # nttp protocol 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
ftps-data 989/tcp # ftp protocol, data, over TLS/SSL
ftps 990/tcp      # ftp protocol, control, over TLS/SSL

If you do not have the entries above in /etc/services, you will probably want to add them.

Note that you cannot front-end ftp data connections with sslwrap nor can you front-end UDP services. While you can front-end telnet using sslwrap, only the "sslonly" variant of telnet is supported. Other SSL telnet implementations such as SSL-MZtelnet also support SSL via telnet option negotiation to the standard telnet port (23) instead of using the special port (992).

While you can front-end your HTTP server with sslwrap, you're better off using apache-ssl. It is more efficient and won't adversely affect your logs. If you use sslwrap, all connections appear to come from "localhost". The Stronghold version of Apache also comes with a Thawte certificate. Using a self-signed certificate for electronic commerce is probably not a good idea.

You cannot front-end SMTP service with Netscape Communicator 4.5 and later clients. Due to a change in port assignments by IANA, there is no longer a smtps service port (465), and there won't ever be one assigned. Instead, smtps can only be negotiated on the standard SMTP port (25), and therefore cannot easily be wrapped.

Running out of inetd

If you want to run sslwrap out of inetd, you will need to edit inetd.conf to add all of the services you want to front-end:

https stream tcp nowait sslwrap /usr/sbin/tcpd /usr/local/sbin/sslwrap
-cert /usr/local/ssl/certs/server.pem -port 80

imaps stream tcp nowait sslwrap /usr/sbin/tcpd /usr/local/sbin/sslwrap
-cert /usr/local/ssl/certs/server.pem -port 143

telnets stream tcp nowait sslwrap /usr/sbin/tcpd /usr/local/sbin/sslwrap
-cert /usr/local/ssl/certs/server.pem -port 23

pop3s stream tcp nowait sslwrap /usr/sbin/tcpd /usr/local/sbin/sslwrap
-cert /usr/local/ssl/certs/server.pem -port 110 

This example is from Linux; your inetd.conf file may vary.

The service (https, imaps, telnets, pop3s, etc.) is the service identifier you added to /etc/services.

I created a user which has no login privileges and is pretty much like "nobody" called "sslwrap" to run sslwrap. Note that sslwrap has not been analyzed extensively and it is not recommended that you run it setuid root, nor does it need to be. But you do need to make sure it can read the private certificate file.

The -cert parameter specifies the certificate file which may be the self-signed certificate you created above, or a real certificate. The certificate file's private key must not be encrypted.

There is a -nocert option; it means you do not have a server certificate. This still encrypts the connection. You won't have to create a certificate, but it could make it easier for someone to spoof being your server and capture passwords that way if you had access to your LAN or DNS. Note: This is not compatible with all SSL implementations! If you use Microsoft Outlook Express for Macintosh version 4.5, for example, you cannot make any connections to servers in -nocert mode ("Security failure. The server reply is invalid").

The -port parameter specifies the port to connect to. When a connection comes in via SSL, a connection is made to localhost and this port. This is the port that the actual service is listening on.

The -addr parameter specifies the address to connect to. In the absence of the -addr parameter a connection is made to localhost. The parameter must be an IP address in dotted decimal notation, such as 123.45.67.89.

You will need to restart inetd, typically by using kill -HUP <pid of inetd>.

Using -exec

Instead of doing a loopback IP connection as described above, you can use the -exec option to directly execute a program. For security reasons, I recommend using the standard inetd configuration specified above, instead.

imaps stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/sslwrap
-cert /usr/local/ssl/certs/server.pem -exec /usr/local/sbin/imapd

This example is from Linux; your inetd.conf file may vary.

The service (https, imaps, telnets, pop3s, etc.) is the service identifier you added to /etc/services.

One important caveat with using -exec mode is that sslwrap has to run as whatever user is necessary to run the program you are executing. For example, imapd generally must be run as root to access user mailboxes, and since it is run out of inetd it is not setuid root. But if sslwrap directly spawns imapd using the -exec option, it too must be run as root. I do not recommend running sslwrap as root.

The -cert parameter specifies the certificate file which may be the self-signed certificate you created above, or a real certificate. The certificate file's private key must not be encrypted.

There is a -nocert option; it means you do not have a server certificate. This still encrypts the connection. You won't have to create a certificate, but it could make it easier for someone to spoof being your server and capture passwords that way if you had access to your LAN or DNS. Note: This is not compatible with many SSL implementations! If you use Microsoft Outlook Express for Macintosh version 4.5, for example, you cannot make any connections to servers in -nocert mode ("Security failure. The server reply is invalid").

The -exec parameter specifies what application to run. You cannot specify any parameters; it must be an executable that can run with no options!

You will need to restart inetd, typically by using kill -HUP <pid of inetd>.

Running as a daemon

You can also run sslwrap as a daemon instead of running out of inetd but this is not recommended. The code does not currently correctly handle forking correctly, and has not been tested much. It also invites a potential security problem if you want to listen on standard SSL ports because sslwrap would have to run as root, and this is not recommended. It is mainly here for testing purposes.

/usr/local/sbin/sslwrap -cert /usr/local/ssl/certs/server.pem \
-port 80 -accept 443 &

/usr/local/sbin/sslwrap -cert /usr/local/ssl/certs/server.pem \
-port 143 -accept 993 &

/usr/local/sbin/sslwrap -cert /usr/local/ssl/certs/server.pem \
-port 23 -accept 992 &

/usr/local/sbin/sslwrap -cert /usr/local/ssl/certs/server.pem \
-port 110 -accept 995 &

You might type in commands like this, or perhaps add it to one of the startup files, like rc.inet2.

I created a user which has no login privileges and is pretty much like "nobody" called "sslwrap" to run sslwrap for inetd. This works fine for inetd, but the problem is that you must be root to bind to a 'reserved port' (less than 1024) under Unix. This would require running sslwrap setuid root. Since sslwrap has not been analyzed to be sure it's safe to run setuid root, I really have to warn against doing this. You really should use inetd instead of daemon mode.

The -cert parameter specifies the certificate file which may be the self-signed certificate you created above, or a real certificate. The certificate file's private key must not be encrypted.

There is a -nocert option; it means you do not have a server certificate. This still encrypts the connection. You won't have to create a certificate, but it could make it easier for someone to spoof being your server and capture passwords that way if you had access to your LAN or DNS. Note: This is not compatible with all SSL implementations! If you use Microsoft Outlook Express for Macintosh version 4.5, for example, you cannot make any connections to servers in -nocert mode ("Security failure. The server reply is invalid").

The -port parameter specifies the port to connect to. When a connection comes in via SSL, a connection is made to localhost and this port. This is the port that the actual service is listening on.

The -addr parameter specifies the address to connect to. In the absence of the -addr parameter a connection is made to localhost. The parameter must be an IP address in dotted decimal notation, such as 123.45.67.89.

The -accept parameter specifies the port to listen on (that is, accept connection on). This is the SSL port number.

Connecting To Another Machine

You can "ssl-ize" a service running on a computer other than the one you're running sslwrap on. Of course anyone between you and the server your connecting on can still look at your clear text data, but if you'll be connecting to the SSL server from an even more distant or insecure area, you may still have benefits from doing this.

Remote connection can be done from inetd or as a daemon; add a "-addr" parameter to the command line:

imaps stream tcp nowait sslwrap /usr/sbin/tcpd /usr/local/sbin/sslwrap
-cert /usr/local/ssl/certs/server.pem -port 143 -addr 123.45.67.89

The address must be specified in dotted decimal notation and be an IP address, not a hostname.

Testing

sslwrap has only been lightly tested by me. It works for what I wanted it for (SSL IMAP with Microsoft Outlook 98, though previously I used Netscape Communicator), and I do not guarantee it will work for you. It has been tested in the following environment:

My server is running RedHat Linux 6.0 on the x86 platform. I have front-ended IMAP (University of Washington server), POP3 (Qualcomm qpopper), Apache HTTP server, telnet (MIT ktelnetd), and SMTP (sendmail) successfully.

I have tested the server using Netscape Communicator 4.01a for both HTTP and IMAP under Windows 95 and Windows NT; it works quite well. Note, however, that Netscape Communicator 4.5 cannot use SSL SMTP. This is because Netscape removed all of the functionality for SMTP on port 465 in versions 4.5 and later.

I have tested it with https using Microsoft Internet Explorer 4.0.1 under Windows 95. Microsoft Outlook 98 Beta 2 under Windows NT also was able to use SSL POP3 successfully, as well. Note that you must use a version of Internet Explorer later than 3.02 when you're using a self-signed certificate because older versions do not allow certificates made by certificate authority that is not on the list of approved CAs. Unfortunately, you cannot remember an unknown CA like you can with Netscape, so you are frequently prompted to allow the unknown CA. A real server certificate would probably work fine, but this is not necessarily recommended because of the requirement for an unencrypted private key.

A later test, done March 19, 1998, on a different computer, yielded somewhat different results with Microsoft Outlook 98 Beta 2 under Windows NT 4.0 (Service Pack 3). In this case, I was able to use my self-signed server certificate for both IMAP and SMTP without warning. I cannot explain why this would be the case, but I am both happy (that I don't get a dialog every time I connect) and sad (that I wasn't warned about an unknown CA)!

I have since switched to using Microsoft Outlook 98 and it seems to work quite well for SSL IMAP and SSL SMTP. In fact, it works a little better than Netscape Communication because it breaks the connection less often. If your sslwrap server is not really fast, generating the temporary keys at the beginning of each connection can take several seconds.

Aside from not being recommended for security reasons, running sslwrap in daemon mode has not been tested very much. I really suggest using inetd mode instead of daemon mode.


Release Notes

Version 2.0.6

December 6, 2000

Version 2.0.5

September 28, 1999

Version 2.0.4

September 26, 1999

Version 2.0.3

March 10, 1999 (From User Contribution)

Version 2.0.2

November 19, 1998 (From User Contributions)

Version 2.0.1

November 11, 1998 (From User Contributions)

Version 2.0:

September 21, 1998

 


Legal

sslwrap is written by Rick Kaseguma
Copyright 1997-1999 Rick Kaseguma
All Rights Reserved

This code is based on ssleay, Copyright 1995-1997 Eric Young

The latest version of this document is available here: http://www.rickk.com/sslwrap/

You can use sslwrap for any purpose you like, subject to underlying conditions imposed by the SSLeay library that is is based on. There are no additional commercial use, redistribution, or other restrictions imposed by me. There is no warranty. I make no guarantees that this will actually work or it will be secure. Use with caution.

Since sslwrap itself contains no encryption code, I don't believe there should be any restrictions on export.

If you have comments, suggestions, bug fixes, or if you are successfully using sslwrap, send a note to sslwrap3 (at) rickk.com. Thanks!