Back to Rick's Home Pagesslwrap 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:
Just follow these steps to build sslwrap.
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.
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.
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.
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.
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.
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>.
You can also run sslwrap as a daemon instead of running out of inetd.
/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.
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.
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.
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.
September 28, 1999
September 26, 1999
March 10, 1999 (From User Contribution)
November 19, 1998 (From User Contributions)
November 11, 1998 (From User Contributions)
September 21, 1998
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 sslwrap@rickk.com. Thanks!
Back to Rick's Home Page