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!


MORE INFORMATION ON SSL:
  • SearchSecurity expert Ed Yakabovicz explains

    Requires Free Membership to View


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.


This was first published in April 2004

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.