Secure Socket Layer


Introduction
The Secure Socket Layer (SSL) is a protocol independent transport layer for sending encrypted information over the Internet. SSL provides encryption preventing eves-droppers from being able to see the information. It also provides authentication to prevent people spoofing their identity. The SSL protocol is an open specification backed by all major vendors including Microsoft and Netscape.

Concepts
The SSL protocol uses public key cryptography. The server has a certificate that includes a public key. At the start of an SSL session, the server sends the browser this certificate. The browser then generates a random number that is used as the session-key. The browser then encrypts this with the server's public key, so only the server can decrypt it with the server's private-key. A session key has now been exchanged that is known only by the browser and the server. This session-key is then used as the key encode data for the rest of the session.

The certificate contains information about the server, and the organization that runs it. Certificates need to be signed by Certificate Authorities to guarantee that the organization running the server is who they say they are. In order to get a signed certificate, you must create a Certificate Request and send that to a Certificate Authority along with appropriate documentation to prove your identity.

For test purposes you can create a self-signed certificate. This allows for data to sent encrypted, but the browser will not be able to check that you're not pretending to be someone else.

Creating a Private Key
Before you create a private key, you must first appreciate its value. If anyone was to get hold of your private key, they could decrypt all your encrypted communication. They could also masquerade as you, and take credit-card orders pretending to be you. It is therefore of great importance that once you generate your key, you keep it secret. For security reasons you should not transmit your private key over a network. For this reason the tools provided to create keys are command line only and the web interface does not display the private key. A program called cert is provided for this purpose. It lives in the $ZEUSHOME/admin/bin directory.

Usage: cert -new -type private -out <private_key_file>
This file will be created with 0400 permissions, so that only the user who created the key can read it.

Creating a Certificate Request
For an SSL enabled browser to connect seamlessly to your site you must now have your new private key signed by a Certificate Authority (CA). The CA will require an X509 certificate request in order to return you a signed key. The cert program can be used to create an appropriate request.

Usage : cert -new -type request -key <private_key_file>
         -out <outfile>
The output file can be sent to a certificate authority, who will, for a fee, supply you with a signed certificate. Zeus recommends Verisign as the best certificate authority to use with your Zeus Server.

Creating a Self-Signed Certificate
For test purposes, you might just want to create a certificate that you sign yourself. This avoids the delays and costs of getting a certificate authority to validate your identity. As users will have no means of validating the certificate these should not generally be used in public sites.

To created a self signed certificate use the following command

Usage : cert -new -type public -key <private_key_file;> 
         -out <output_file>
This will produce a self signed certificate containing your public key.

Making a Server Secure
In order to make a Virtual Server secure you need to follow these instructions.

Chained Certificates
Each public certificate your secure web site presents to its web clients ought to be signed by a trusted CA certificate. Web clients trust certificates signed by several well known CA's (Verisign, Thawte etc).

Other CA's can obtain signing certificates signed by one of these trusted CA's. They can use these certificates to sign public web site certificates. For example:

  1. Trusted root CA 'A' decides that organization 'B' is a legitimate certificate agency and provides them with a public key.
  2. You create your private key and certificate request and ask 'B' to generate and sign a public certificate for you ('C').
  3. You install your certificate C on your secure web site.
However, when a client comes to your web site and looks at your certificate they will reject it if they do not explicitly trust organization B. You need to provide B's certificate as well as your own.

Then, the client will accept your certificate because it can trace the certificate chain of trust back to the root CA 'A' which it does trust.

You can provide a certificate chain to Zeus by concatenating the certificates together into the file you provide containing your public certificate. If your certificate is in the file c.pub and your CA's public certificate is in the file b.pub, do the following:

$ cp c.pub chained.pub
$ cat b.pub >> chained.pub
Present the file 'chained.pub' to Zeus as your public certificate file.

Client-Side Certificates
The SSL specification provides a means for the connecting clients to be sure of the identity of the web site they are connecting to. Client-side certificates enable the web server to similarly authenticate the connecting clients.

Many web clients can be configured with client-side certificates. These certificates can be used to identify the client. You can configure your Zeus server to request or require that connecting clients supply their certificates.

If you require a client-side certificate and the client does not supply one, the SSL connection is rejected (terminated).

If you request or require a client-side certificate and the client does supply one, then the certificate is checked against the root certificates in the $ZEUSHOME/etc/CAs directory. If it has not been issued by one of these CAs or the certificate has expired, the connection is rejected.

You need to restart the web server if you modify the contents of $ZEUSHOME/etc/CAs, and the same root certificate set is shared between all running SSL web sites.

If the connection is accepted, and the client has supplied a certificate, the certificate data is supplied via the supported dynamic content interfaces. For example, you could construct a FastCGI authorizer to perform further checks on the certificate (against a Certificate Revocation List, for example). The variables passed to a CGI-like process are as follows:

Hardware Cryptographic Accelerators

The Zeus Web Server supports delegation, to external hardware, of the cryptographic computations required by SSL. This involves a change to the global configuration of the web server, which is documented elsewhere.