Most information security professionals have at least a passing familiarity with the Secure Sockets Layer (SSL) protocol. You're probably aware it's used to authenticate and encrypt Internet communications. However, you might not be familiar with what goes on "under the hood" of SSL. If you currently use SSL in your environment or plan to use it in the future, it's important that you have a basic understanding of the protocol's capabilities...
and its common uses.
SSL has three basic capabilities that may be used independently or in combination to provide security to network-based communications. These capabilities are:
- Authenticating a server to a client
- Encrypting communications between a client and server
- Authenticating a client to a server
The use of SSL for authentication requires that the authenticating party possess an SSL certificate issued by a Certificate Authority (CA). These certificates are normally quite expensive (in the ballpark of $300/year). Therefore, when securing Web traffic (the most common use of SSL), it's often the case that the server authenticates itself to the client, but the client does not authenticate itself to the server. After all, it's not likely that a Web site will be able to convince its users to purchase an SSL certificate!
The beauty of SSL is that it allows authenticated, encrypted communication between parties previously unknown to each other. This process is facilitated through the use of the Public Key Infrastructure of Certificate and Registration Authorities. When a client wishes to initiate SSL communication with a server, it uses a process known as handshaking:
- The client sends a request for SSL communication to the server.
- The server responds by providing its digital certificate to the client and (optionally) requesting a certificate from the client for client authentication.
- The client validates the certificate by using the CA's public key and checking the current Certificate Revocation List (CRL).
- If the server's certificate is valid, the client then creates a master secret key for use in future communication, encrypts it with the server's public key (from the server's certificate) and transmits it to the server. If the server requested client authentication, the client also includes its own digital certificate.
- If the client transmitted a certificate, the server verifies the client's identity using the CA's public key and the CRL.
- The client and server each use the master secret key to generate the symmetric session keys. (Note: The use of these symmetric keys instead of the public keys from the digital certificates is preferred due to the speed advantages inherent in symmetric encryption.)
- All future communications take place using symmetric encryption.
During the initial steps of the handshaking process, the client and server also negotiate the exact cryptographic algorithms that will be used to secure the session.
The true power of SSL security lies in its ubiquitous nature, especially for Web communications. Virtually every computer on the planet is now equipped with a Web browser that supports SSL communication.
About the author
Mike Chapple, CISSP, currently serves as Chief Information Officer of the Brand Institute, a Miami-based marketing consultancy. He previously worked as an information security researcher for the U.S. National Security Agency. His publishing credits include the TICSA Training Guide from Que Publishing, the CISSP Study Guide from Sybex and the upcoming SANS GSEC Prep Guide from John Wiley. He's also the About.com Guide to Databases.