SSL Protocol Overview

SSL Version 3, documented in an IETF draft, provides one of the most commonly available security mechanisms on the Internet. SSL stands for Secure Sockets Layer, though IETF is renaming it TLS (Transport Layer Security). Developed by Netscape, SSL is used extensively by web browsers to provide secure connections for transferring credit cards numbers and other sensitive data. An SSL-protected HTTP transfer uses port 443 (instead of HTTP's normal port 80), and is identified with a special URL method - https. Thus, https://www.verisign.com/ would cause an SSL-enabled browser to open a secure SSL session to port 443 at www.verisign.com.

SSL is based on cryptography, the encoding of data in such a way that it can be decoded only by its intended recipient, not by a third party who might be able to intercept the information in transit. The simplest way to do this is for the sender and receiver to use a secret key, which can be used along with an agreed-upon algorithm to scramble the data in such a way that only someone with the key can descramble it. The secret key acts much like a password. One of the most well-known secret key systems is the Data Encryption Standard (DES), developed by the U.S. National Security Agency. SSL uses a secret key system called RC4, developed by RSA, Inc, to encrypt its transfers.

The use of a secret key implies that the participants in the conversation must have selected a key and communicated it among themselves in a secure manner. However, when establishing an Internet connection, there is usually no pre-arranged key, so a means must be provided of securely generating one. This would become a chicken-and-the-egg problem (how do you communicate a secret key with a secret key to encode it?) were it not for public key cryptosystems, of which RSA is the most used.

A public key system, usually based on mathematical principles of modulo arithmetic, uses two keys, not one. Information encrypted with one of the keys can only be decrypted with the other key, and vice versa. You can not encrypt and then decrypt a message with only one key - the result would be gibberish. Typically, one key is published (the public key) and the other keep secret (the private key). Now anyone can encrypt a message using the public key and transmit it across an insecure network, knowing that only the holder of the private key can decrypt it. Not only can you encrypt with the public key, but you can also encrypt with the private key. Anyone can decrypt such a message, but only the private key holder could have generated it in the first place. This gives us a means of digitally signing messages in a way that no one else (without the private key) could duplicate. Thus, public key cryptosystems provide us with both confidentiality (no one can read a message but the receiver) and authenticity (no one can write a message but the sender).

SSL operates using these principles. When an SSL session is established, the server begins by announcing a public key to the client. No encryption is in use initially, so both parties (and any eavesdropper) can read this key, but the client can now transmit information to the server in a way that no one else could decode. The client generates 46 bytes of random data, forms them into a single very large number according to PKCS#1, encrypts them with the server's public key, and sends the result to the server. Only the server, with its private key, can decode the information to determine the 46 original bytes. This shared secret is now used to generate a set of conventional RC4 keys to encrypt the rest of the session.

The only issue that remains is authentication. How does the client know that the server is actually what it claims to be, and not some interlopper sending its own set of public keys? The answer is provided by certificates. A certificate is a cryptographically sealed data object that includes the server's identity and public key. The certificate is signed by computing its hash value and encrypting this with an issuer's private key. If even one bit is changed in the certificate, the hash value changes, and the signature becomes invalid. If the client already possesses the issuer's public key, and trusts the issuer to verify the identity of the server, then the client can be sure that the public key in the certificate is the public key of the server. An interlopper would have know either the private key of the server or the private key of the issuer to successfully impersonate the server.

As it turns out, only a handfull of issuers are needed. For example, VeriSign, the major U.S. issuer, issues certificates only after a background check insures both the identity of the subject, and their authority over a particular DNS name. VeriSign's public keys are hardwired into both Netscape's and Microsoft's web browsers, so a server with a VeriSign-signed certificate can be authenticated by a browser with no additional information. If the server presents a certificate not signed by VeriSign (or another recognized authority), or if the DNS name of the server doesn't match the DNS name in the certificate, a warning message is displayed, and the user may decide how to proceed.

The client can be authenticated as well, by presenting a certificate of its own, then computing a hash of all the SSL messages that have been exchanged up to a certain point, encrypting the result with its private key, and sending this to the server. The server, which can compute the same hash value, having seen all the messages as well, can decrypt using the client's public key, which is part of the certificate, and verify that the two results are the same. Thus the client is authenticated.