Using SSL to protect your servers

by Mark Wilkinson

$Id: ssl-protect.html,v 1.3 2002/11/04 14:49:55 mhw Exp $


If you run a publicly accessible server (be it a web server, email server or whatever) but you want to keep some of your content private, then you really should think about using SSL to protect your information. SSL will encrypt the traffic that flows across the public network, so it cannot be read by anyone other than the desired recipient. That's useful if you're using usernames and passwords to access resources, because otherwise the usernames and passwords would be traversing the internet in the clear. You'll find that most servers have some form of support for tunneling their basic protocol inside an SSL encrypted channel.

First an overview of how SSL works. SSL uses a symmetric encryption algorithm to encrypt and decrypt the data which is transfered between a client and a server. Symmetric encryption algorithms rely on both sender and receiver sharing a secret key of some size which is used to drive the encryption algorithm. When you don't know which web server or web browsers you'll be talking to you need some way of agreeing on a secret key for the duration of a connection. SSL uses public-key encryption techniques to agree on the secret key. It also uses public-key techniques to attempt to give some guarantee about the identity of the parties at each end of an SSL link.

An SSL-enabled web server needs a key pair (one public, one private). The keys are used as follows:

  1. web server sends public key to web browser
  2. web browser generates random secret key for symmetric encryption session
  3. web browser encrypts session key with web server's public key
  4. web browser sends encrypted session key to web server
  5. web server decrypts session key using private key
  6. communication takes place using symmetric algorithm and session key
The problem here is that an attacker could substitute their own public key for that sent to the web browser and intercept all following communications, a classic man-in-the-middle attack.

SSL gets round this by having the public keys be signed by certification authorities. Public key signing involves a certification authority encrypting a secure hash of some data (in this case the web server's public key and some other credentials) with the certification authority's private key. Anyone receiving the signed public key (collectively termed a certificate) can check the signature using the certification authority's public key and be (reasonably) sure that the web server's public key has not been tampered with by a man-in-the-middle. A number of common certification authorities have their public keys distributed with the common web browsers (Netscape, Internet Explorer) purely for this purpose. Of course, we now rely on the attacker not inserting their own certification keys in the browser we downloaded from the Internet, but it's a bit more secure...

Now, you can't produce a server certificate without a certification authority key pair, and obviously the private keys of the certification authorities are closely guarded secrets. Not only that, but the commercial certification authorities charge money for this service, which you might not be able to justfify. Fortunately you can do the job yourself if you have the right tools to hand. In practical terms, the only thing that distinguishes what the certification authorities do from what you can do yourself is the fact that the certification authority's keys are probably distributed with the commercial web browsers. This might be important if your web site is going to be used by the general public.

Further Reading

mod_ssl is one module that provides SSL facilities to the Apache web server (the other main one is Apache-SSL). The mod_ssl user manual gives a more detailed explanation of SSL.

How to do it

Don't just take my word for it...

Here are other writings on this subject: