6.3 OpenSSL and Apache (Cont.) - Page 4

6.3.4 Certificates

Before your server can engage in secure sessions it needs a valid certificate which identifies it to browsers. The certificate contains identifying information for your server, a public key used to encrypt messages to you, identification of your certifying authority, and a digital signature from the certifying authority that the browser can use to prevent malicious servers from forging certificates.

As part of the mod_ssl installation you can create a temporary certificate to be used for testing your server. That will get you through the rest of this book, but before you open your site to the public you will need a proper certificate from a well-known certifying authority (CA).

To explain why this is, we need to delve for a moment into how SSL encrypts Internet messages. ³ When the SSL client contacts an SSL server, the server sends its certificate back along with acknowledgment of the connection. This communication takes place in the clear— no secrets have been exchanged yet. Figure 6.1 shows the exchanges in this section.

Figure 6. 1 Secret information exchange

To establish an encrypted channel, the two parties need to exchange secret information. In particular, they need to decide on a session key which will be used to encrypt the data, and the encryption method which applies to it. Obviously if the session key is sent in clear text it won't necessarily stay a secret. To exchange information before establishing the session key, the two parties use asymmetric or public key encryption.

Public key cryptography, most strongly associated with the RSA algorithm, uses a pair of large numbers called the public and private keys to encrypt and decrypt messages. A message encrypted with the public key can be decrypted with the private key, and a message encrypted with the private key can similarly be decrypted with the public key. The crucial aspect of the algorithm is that a party with only one key can not both encrypt and decrypt a message, thus the term asymmetric encryption. Suppose I give everyone my public key (which is why we call it that) and keep my private key a secret. To send a secure message I encrypt it with my private key, and anyone who has my public key can both decrypt it and also be certain that it came from me, since only I can create a message that can be decrypted with the public key. Anyone who has my public key can send me a secure message also, by encrypting it with that key. Assuming that only I have the secret key, only I will be able to decrypt the result.

Public key cryptography is an amazing example of pure mathematics turned useful. It is also computationally expensive, far too much so to be used for large amounts of web traffic. That's why SSL (and other security protocols) use public key cryptography to exchange an initial message between parties that include a session key for symmetric encryption, the more traditional kind of encoding where both parties use a single key to encrypt and decrypt messages. The assumption is that if the session key is used only briefly and is never reused, it is very unlikely that a snooper will figure out the encryption before it is changed again.

Back to our SSL example: the client verifies the certificate (more on this shortly) and uses the server's public key to encrypt a message containing a session key and a choice of algorithm that both parties can use to quickly encrypt and decrypt further messages. The server decrypts the message using its private key, then sends an acknowledgment back that has been encrypted using the session key and a symmetric algorithm.

The role of the certificate, then, is to package up the server's public key along with identifying information used to verify the certificate. This verification is important; it prevents a malicious server from creating a certificate that identifies itself as another party. Part of the certificate is the identity of a CA, which is basically a company that sells trust.

As stated earlier, a certificate contains not only the server's public key and identity but also the CA's identity and digital signature of the public key. That signature is created using the CA's private key to encrypt the server's identification and public key; thus if you have the CA's public key you can decrypt the signature and verify that the server's identification matches their key. Since only the CA's private key can be used to create a valid signature, the browser can trust the certificate— if it trusts the CA, that is.

That sounds like a chicken-and-egg problem, but SSL-enabled web browsers are typically shipped with the identification and public keys of a number of well-known CAs. When a browser gets a certificate signed by an unknown CA it should display a dialog explaining what has happened and warn the user of possible problems; the user can then accept or reject the certificate. Chances are good that you've never seen this warning since sites that use SSL are almost always registered with one of a few popular CAs.

And that leads us to the point of this section: your site must go through the certification process with one of those CAs before you can expect to handle SSL traffic with the Internet at large. Both the Apache-SSL and mod_ssl web sites have lists of CAs which can create certificates for you. The security configuration of your browser will also tell you which CAs your browser will recognize without a warning, so check that list against the list of candidate CAs and then shop around for a good deal with a reputable firm.

As mentioned before, the make certificate step will offer to create a temporary certificate for your testing purposes. Go ahead and use that for now; if nothing else it will show you what the warning about an unknown certificate looks like.

6.3 OpenSSL and Apache - Page 3
Web Development with Apache and Perl
6.3 OpenSSL and Apache (Cont.) - Page 5