Secure Tunneling

 


    Author: MAIL_FSMLABS

    Last updated: 17 Nov 2003

    Copyright (c) 2002 MAIL_FSMLABS.
    Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the GNU Free Documentation License is included here.

    Concept

    Some important, but insecure network services (like HTTP) can be easily protected by SSL/TLS (Secure Sockets Layer / Transport Layer Security) using the stunnel utility. The principle is to have stunnel handle an incoming SSL-encapsulated connection, decrypt the data stream or packets, and forward it to an unmodified service daemon. For example, incoming connections on TCP port 443 (https) are decrypted by stunnel and forwarded to port 80 (http) on the local host.

    HOWTO

    To setup an HTTPS service with thttpd (which does not support SSL/TLS natively) on the local machine, use stunnel with inetd:

    1. For testing purposes only: Generate an RSA key pair and a self-signed certificate using this Makefile in /etc/stunnel/ (it uses the openssl command-line tool). The PEM encoded private key must not be encrypted (do not enter a pass phrase in the key generation dialog) and stored together with the certificate in the same file, i.e. /etc/stunnel/stunnel.pem. Order and blank lines in this file are important.

    2. Start the thttpd daemon, e.g. by invoking /etc/init.d/thttpd start. The daemon will listen on port 80 on all network interfaces (see below for security considerations). The command line to start the thttpd daemon manually may look like the following:

      /usr/sbin/thttpd -l /var/log/thttpd.log -i /var/run/thttpd.pid -d /usr/local/httpd/htdocs

    3. Add the following line to /etc/inetd.conf:

      https stream tcp nowait root /usr/sbin/stunnel -D 7 -r localhost:80 -p /etc/stunnel/stunnel.pem -N https

      The -N https option allows to define the tcpwrapper service name that will be used by stunnel (see hosts.allow(5), hosts.deny(5)).

    4. Restart inetd: /etc/init.d/inetd restart.

    5. You should now be able to browse https://localhost/ (provided that /usr/local/httpd/htdocs is populated).

    Certificates

    A certificate is a file (usually in PEM-encoded X.509 format) that should be able to convince some party (the client) of the authenticity of some public key (of the server). The certificate mechanism uses a Trusted Third Party (the Certificate Authority, CA), which is trusted by both parties (the client and the server) and whose public key is known by both parties. The CA receives the public key from one party (the server), verifies its authenticity (usually by signed paper documents or face-to-face authentication), and signs the server's public key with its own private key. The signed server public key augmented with some information about the issuer (the CA) is the certificate, which is sent back to the server. This happens off-line.

    At communication setup time, the server sends its certificate to the client, and the client uses the CA's public key to verify the validity of the certificate. If the certificate is valid, the client believes in the authenticity of the server's public key contained in the certificate.

    It may be necessary that the CA's public key needs to be signed by another CA that is located at a higher level in a CA hierarchy. Eventually, the root CA's certificate is usually self-signed.

    Which CA should be chosen to issue a certificate, depends on the user group size and public key infrastructure of the application. If all users (clients) belong to the same closed user group (e.g. client machines in a LAN), the CA functionality can be provided by some authority within this closed group (e.g. a server in the LAN), and this CA is also the root CA (i.e. the certificate is self-signed). The certificate generated by the Makefile of the HOWTO above is a self-signed certificate.

    However, if the user group is actually open (e.g. the clients of a public web server), some public CA should be used to sign the server's public key. Well-known public CAs are e.g. VeriSign, TrustCenter, and a-sign.