sslwrap - simple TCP service encryption using TLS/SSL sslwrap [-addr arg] [-cert file⎪-nocert] [-rsa file]
[-verify arg] [-Verify arg] [-nbio] [-nbio_test]
[-debug] [-state] [-cipher arg] [-quit]
[-no_tmp_rsa] [-ssl2⎪-ssl3] [-bugs] -port arg
-accept arg
-addr arg Address to connect to (default is127.0.0.1)-port arg port to connect to-accept arg port to accept on (default is stdin forinetd)-verify arg turn on peer certificate verification-Verify arg turn on peer certificate verification,must have a cert.-cert arg certificate file to use, PEM format assumed(default is server.pem)-key arg RSA file to use, PEM format assumed, in certfile if not specified (default is server.pem)-nbio Run with non-blocking IO-nbio_test test with the non-blocking test bio-debug Print more output-state Print the SSL states-nocert Don't use any certificates (Anon-DH)-cipher arg play with 'openssl ciphers' to see what goeshere-quiet No server output-no_tmp_rsa Do not generate a tmp RSA key-ssl2 Just talk SSLv2-ssl3 Just talk SSLv3-bugs Turn on SSL bug
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.
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/bin/ssl/usr/bin/ssl/openssl req -new -x509 -nodes \-out /etc/sslwrap/server.pem -keyout \/etc/sslwrap/server.pem \-days 365ln -s server.pem `/usr/bin/ssl/openssl -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.
Add to /etc/services According to IANA, the following port numbers have been assigned for SSL:
https 443/tcp # http protocol over TLS/SSLssmtp 465/tcp # smtp protocol over TLS/SSLnntps 563/tcp # nttp protocol over TLS/SSLtelnets 992/tcp # telnet protocol over TLS/SSLimaps 993/tcp # imap4 protocol over TLS/SSLircs 994/tcp # irc protocol over TLS/SSLpop3s 995/tcp # POP3 protocol over TLS/SSLftps-data 989/tcp # ftp protocol, data, over TLS/SSLftps 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.
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/sbin/sslwrap -cert /etc/sslwrap/server.pem -port 80imaps stream tcp nowait sslwrap /usr/sbin/tcpd \/usr/sbin/sslwrap -cert /etc/sslwrap/server.pem -port 143telnets stream tcp nowait sslwrap /usr/sbin/tcpd \/usr/sbin/sslwrap -cert /etc/sslwrap/server.pem -port 23pop3s stream tcp nowait sslwrap /usr/sbin/tcpd \/usr/sbin/sslwrap -cert /etc/sslwrap/server.pem -port 110
The service (https, imaps, telnets, pop3s, etc.) is the service identifier you added to /etc/services.
Running as daemon You can also run sslwrap as a daemon instead of running out of inetd.
/usr/sbin/sslwrap -cert /etc/sslwrap/server.pem -port 80 \-accept 443 &/usr/sbin/sslwrap -cert /etc/sslwrap/server.pem -port 143 \-accept 993 &/usr/sbin/sslwrap -cert /etc/sslwrap/server.pem -port 23 \-accept 992 &/usr/sbin/sslwrap -cert /etc/sslwrap/server.pem -port 110 \-accept 995 &
You might type in commands like this, or perhaps add it to one of the startup files, like /etc/inet.d.
Connection 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/sbin/sslwrap -cert /etc/sslwrap/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. 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 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. This man page is not part of the sslwrap source package. It was created for the Debian GNU/Linux distribution. sslwrapconfig(1) Debian GNU/Linux, Raphael Bossek <[email protected]> sslwrap is written by Rick Kaseguma <[email protected]> More information can be found at the sslwrap web site at http://www.rickk.com/sslwrap/