Speed troubleshooting by understanding SSL encryption

Provides a solid understanding of how SSL works and explains its security mechanisms so that you can troubleshoot errors when they happen

Secure Socket Layer (SSL) forms the backbone of secure Internet communications between Web sites and computers accessing those sites. It protects passwords, encrypts traffic and transactions, and prevents hackers from capturing data as it flows between computers to servers. If your organization relies on SSL, you need to have a solid understanding of how it works so that you can troubleshoot errors and problems and explain its security mechanisms to nontechies who want to verify that Internet transactions can be trusted.

SSL and encryption
Encryption is the actual process that protects the data. Encryption uses a mathematical process called a cipher to make data unusable to anyone except the intended recipient (or recipients). Encryption technology first found its use in war as a way to safely communicate orders without worry that the enemy would learn of them.

As you're well aware, there's a constant war raging on the Internet as hackers try to attack Web sites and commercial traffic, trying to gain customer information such as credit cards and Social Security numbers. SSL uses several encryption techniques to protect your data. There are three basic kinds of encryption, and SSL uses all three of them. They are:
  • Hash
  • Symmetric
  • Asymmetric

Hashes are used by SSL to ensure that the messages from the sender (either the client or the server) have not been tampered with during the exchange. Hashes aren't encryption in the truest sense of the word since hashes don't allow the original data to be retrieved. A hash, also called a one-way hash, takes an arbitrarily large value and uses an algorithm to create a small signature for the message. The hash is valuable because it's unlikely that you'll be able to reproduce the hash without the original message.

Hashes are used with the other two encryption mechanisms to ensure that a message was not tampered with during transit. The hash is encrypted to prevent tampering. When the recipient receives the message, software on the receiving machine generates a hash the same way the sender did. The recipient then decrypts the hash sent along with the message and verifies it against the hash that it calculated. If the two hashes match, then the recipient software knows that the message was not tampered with during transit.

Most of the communication in SSL is handled through symmetric encryption. Symmetric encryption utilizes the same key value in conjunction with a cipher at the sending computer and receiving computer to encrypt and decrypt data. Symmetric encryption is computationally fast. This makes it the proper choice for large amounts of encryption, such as the body of an SSL communication.

The primary problem with symmetric encryption is that you must share a key between the originator and the recipient. Sharing this key can be difficult because you must share the key in a way that hackers can't intercept. The best way to do this is to utilize a third kind of encryption called asymmetric encryption.

Asymmetric encryption is different from symmetric encryption in that the keys used to encrypt and decrypt the data are not the same. There is a private key and a public key. Either key can be used to encrypt or decrypt the data, but the same key can't be used twice.

The public key is exposed to everyone so that if you want to send a message to only the intended recipient, you can use it with assurance that only the recipient will be able to read the contents. The private key is never shared, and because of this fact, only the owner of the key pair can decrypt the message.

Asymmetric encryption does have its weaknesses, though. First, asymmetric encryption is more computationally complex than symmetric encryption. This means that it's a poor choice for encrypting large blocks of data such as the body of an SSL conversation, because it takes longer for the message to be encrypted due to the complexity of the key. Second, although you know that the only key that can decrypt the data is the associated private key, there is no assurance that the person who has the private key is who they say they are. Verifying the originator requires another piece of the SSL puzzle called the certificate.

Certificates bundle up the public key for an asymmetric key pair, some information about who the owner of the key is, and then, an asymmetric key pair identifying the party or parties who are verifying the identity of the holder of the certificate. Certificates are issued by a certificate authority (CA). The certificate authority has its own public-private key pair that it uses to sign the certificates it issues.

When a certificate authority issues a certificate, it establishes the public-private key pair, encapsulates some information about whom it has issued the key pair to, and then encrypts it with the CA's private key. The client unpacks the certificate with the CA's public key, which is also included in the certificate. The client knows who the owner of the public-private key pair should be because the certificate authority has signed the information by using its private key. The client can then know that the certificate authority believes the owner of the certificate is the correct owner.

The only remaining challenge is determining what certificate authorities to trust. Once you establish trust with a relatively small number of certificate authorities, you can trust a much larger number of certificates. Certificate authorities that are trusted are called trusted root certificate authorities—or more frequently, the shortened "trusted roots." Each computer stores the certificate of the root certification authorities it trusts in a special store, which it consults for a match when it's confronted with a certificate.

Companies like VeriSign, Thawte, and several others have convinced Microsoft to be included in the trusted root certificates that are added to the store when the operating system is installed. Similarly, other operating systems have sets of trusted root certificate authorities. If you get an SSL certificate from one of these providers, the certificates will be accepted as correct as long as the client receives your certificate from the address that is signed into it.

Time limits and certificate revocation lists
In addition to the identity of the owner of the certificate, there are a set of timestamps indicating when the certificate was issued as well as when the certificate will expire. Certificates are designed to expire after a period of time for a simple reason. The longer that a certificate is in circulation, the greater the chance is that the certificate's private key will be discovered or reverse-engineered. Although the cryptographic algorithms used are very difficult to reverse-engineer, it is possible with time to use brute force to deduce the private key. Setting an expiration date prevents both of these situations from happening.

Despite the protection that time limits provide, there is occasionally a problem where a CA issues a certificate that should not have been issued. Several years ago, there was a much publicized case where VeriSign accidentally created a certificate for an individual who claimed to be an authorized employee for Microsoft. This certificate, once issued, appeared to be perfectly valid. This means that the person would be able to impersonate Microsoft until the expiration of the certificate. Fortunately, expiration was built into the design of certificates.

In order to ensure that the certificate authority still believes the person holding the certificate is who the certificate says he is, a client program can check the certificate revocation list. The certificate revocation list is a special Web-based call that can be used to determine if the certificate authority still believes that the certificate should be valid. Because of this mechanism, VeriSign revoked the fake Microsoft certificate by adding it to its certificate revocation list. This didn't invalidate the certificate itself; however, it did provide a way for intelligent clients to verify the certificate's validity.

When the story first came to light, none of the versions of Internet Explorer checked the certificate revocation list for a certificate. However, shortly after the problem, patches were released to allow Internet Explorer to check certificate revocation lists. Most Web browsers today now check the certificate revocation list.

Putting it together
Now that you're learned the fundamental pieces of the SSL puzzle, it's time to put them all together into the sequence of events that happens every time you go to a secure Web site.

The first step is the request by the client to the SSL-based server. This is done by providing information about the SSL versions, ciphers, and details that the client supports along with some randomly generated data.

The SSL server responds with its supported SSL information, some randomly generated data, the server's SSL certificate, and finally a request for the client to authenticate itself, if necessary. The client can be authenticated with either a client SSL certificate or via a typical username-password pair.

The client checks the certificate by inspecting the information about the root certificate authority, the expiration time, and the name of the owner. The client will then check the certificate revocation list of the certificate authority to guarantee that the certificate has not been revoked. If anything is wrong with the certificate, the Web browser typically flags the user to let the user decide whether to continue or not. If everything is okay, the process continues.

The client then generates a random key that it would like to use, encrypts it with the server's public key, and attaches any authentication information. If the information is a username-password pair, the information is also encrypted with the server's public key.

The server verifies the authentication information of the client, if requested. It then decrypts the key that the client requested with its private key. The client and server use this key as a master key from which other symmetric keys will be generated. The other generated symmetric keys, called session keys, are used for the bulk of the encryption between the client and the server.

Making informed decisions
Now you should have a good idea of how SSL security works, and you can use this knowledge to make informed decisions when prompted with questions by a browser during an SSL transaction. You can also use this knowledge to explain the veracity of SSL security to nontechies that need assurances about the safety and security of online transactions—although you should probably find some nontechnical analogies to help clarify the concepts.

Editor's Picks