sslwrap is a simple service for inetd 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. Just follow these steps to build sslwrap.
You will need to get and build ssleay. 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.
You can get sslwrap source as a tar/gzip file here.
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.
I copied the built version of sslwrap to /usr/local/sbin, but you may prefer a different location based on your system. 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 will not issue a certificate for a server using ssleay.
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, so I don't care too much if a hacker gained access to the private server key.
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 may want to chmod 600 your certificate file so that normal users won't be able to read your unencrypted private key.
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 a special port (992).
While you can front-end your HTTP server with sslwrap, you're better off using one of the Apache with SSL variations of Apache. 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 will need to edit inetd.conf to add all of the services you want to front-end:
https stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/sslwrap -cert /usr/local/ssl/certs/server.pem -port 80 imaps stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/sslwrap -cert /usr/local/ssl/certs/server.pem -port 143 telnets stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/sslwrap -cert /usr/local/ssl/certs/server.pem -port 23 pop3s stream tcp nowait root /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.
You do not need to run sslwrap as root, but you do need to make sure it can read the certificate file. You may want to create a special user to run sslwrap that is the owner of the 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.
You will need to restart inetd, typically by using kill -HUP <pid of inetd>.
sslwrap has only been lightly tested by me. It works for what I needed it for, and I do not guarantee it will work for you. It has been tested in the following environment:
The server is running Linux 2.0 on the x86 platform. I have front-ended IMAP (University of Washington server), POP3 (Qualcomm qpopper), Apache HTTP server, and telnet (MIT ktelnetd) successfully.
I have tested the server using Netscape Communicator 4.01a for both HTTP and IMAP under Windows 95.
sslwrap is written by Rick Kaseguma
Copyright 1997 Rick Kaseguma
All Rights Reserved
This code is based on ssleay, Copyright 1995-1997 Eric Young