SSL and TLS Essentials: Securing the Web

	ABOUT THE AUTHOR Stephen A. Thomas is chief architect for Wave7 Optics. He has been actively involved in TCP/IP standards development for nearly two decades, and has co-authored and contributed to numerous Internet RFCs. Mr. Thomas is the author of several books, papers, and articles. Most notably, he has written IPng and the TCP/IP Protocols: Implementing the Next Generation Internet, as well as the recently published SSL and TLS Essentials: Securing the Web.

Security technology provides that trust. And on the Web, the Secure Sockets Layer (SSL) protocol is THE security technology.

If you've ever looked closely at your browser's status bar, you may have noticed that a padlock icon appears when you're viewing some Web pages. That icon indicates that SSL has secured the delivery of that page from the server to your PC. And if the page is a form, SSL can secure the information you provide back to the Web site.

Figure 1: The padlock icon in the Web browser indicates that SSL is securing communications.

For all of those applications, SSL provides nearly all the standard security services, including confidentiality, authentication, and message integrity.

Confidentiality
Confidentiality is the most well-known security service. SSL provides confidentiality by encrypting information that traverses the network. Encryption protects against eavesdroppers, preventing Charles from reading the message that Alice sends to Bob. When SSL encrypts Web sessions, it keeps sensitive information such as passwords, credit card numbers, and account statements safe from prying eyes.

Authentication
Although some consider it less glamorous, authentication is often more important than confidentiality. Authentication lets communicating parties verify each other's identity. With authentication services, Bob can be sure that the message really is from Alice, not from Charles posing as Alice.

Authentication is an important prerequisite to encryption. After all, if Charles is able to masquerade as Alice, encrypted messages that Bob thinks he's sending to Alice will actually go to Charles. Even though no one will have been able to read the encrypted messages in transit, Charles will just decrypt them as part of his masquerade.

For Web browsing and electronic commerce, authentication of Web sites is a critical security service. Without it, a hacker could establish a phony site, sit back, and collect credit cards from unsuspecting users.

Message Integrity
Message integrity is another important security service that SSL provides. It makes sure that Charles isn't able to alter Alice's message while it's in transit. Note that message integrity really is distinct from encryption. In some cases, sophisticated attackers might be able to alter encrypted messages even if they can't decipher their contents. For example, the attacker could simply delete part of the message. SSL, however, lets recipients detect such attacks and respond appropriately.

In the history of cryptography (which stretches back for thousands of years), asymmetric key cryptography is quite recent, having been invented about 30 years ago. Before asymmetric keys, all cryptography relied on shared keys. Both parties in a secure communication had to know the same keys. The challenge with traditional cryptography is key distribution—how do you distribute, manage, and protect those secret keys.

Public key cryptography changes the key distribution problem dramatically. Instead of a single key that both parties share, public key cryptography relies on a pair of keys. It only takes one of the keys to encrypt a message, but you can't decrypt the message unless you know the other key. Because the encryption key alone will not compromise any message, it can be distributed publicly, even published in a newspaper.

Public Key Encryption
Figure 5 on the right demonstrates how public key encryption works. First, Bob creates his pair of keys. This may require quite a bit of complex calculations, but that's not a problem with computers. After Bob creates his key pair, he makes one of those keys publicly available. That's step 2 in the example. In step 3, Alice wants to send Bob something secret. To do that, she looks up Bob's public key and uses that key to encrypt the message. Step 4 shows Alice sending the encrypted message to Bob. Since nobody knows Bob's private key, nobody (not even Alice) can decipher this message. (Of course, Alice probably remembers what it contains.) Finally, in step 5, Bob receives the message and decrypts it with his private key.

Authentication with Digital Signatures
Public key cryptography is also a major advance in authentication technology; it makes digital signatures possible.

To digitally sign a message, Bob encrypts it with his private key. He also continues to publish his public key. When Alice receives the message, she verifies the signature by decrypting it using Bob's public key. If the message decrypts successfully, then Alice is sure that Bob's private key must have encrypted it. And, since only Bob knows his private key, the message must have really come from Bob.

Note that the message in this example is not confidential at all. Anyone can look up Bob's public key and decipher it. If Bob and Alice want confidentiality and authentication, Bob should encipher his message with his private key and then encrypt the result with Alice's public key.

Computational Complexity
Of course, public key cryptography does have some disadvantages. A major one is computational complexity. Public key encryption and decryption can be several orders of magnitude more complex than some symmetric key algorithms.

Solving this problem is actually rather straightforward: use asymmetric and symmetric algorithms together. Bob begins the process with asymmetric cryptography; he publishes his public key.

But Alice does not use that public key to encrypt her messages. Instead, she generates random numbers. It's those random numbers that she encrypts with Bob's public key and sends to Bob. Bob, of course, decrypts those random numbers with his private key.

Then, in step 5, Alice and Bob use the random numbers Alice picked as secret keys for symmetric encryption.

In this approach Alice and Bob have to undergo the computational burden of asymmetric cryptography once—in order to securely exchange keys for symmetric encryption. From then on, however, Alice and Bob use more efficient symmetric algorithms to secure their communications.

Certificate Authorities
Another challenge for public key cryptography is knowing whether to trust a particular public key. Just because Alice reads Bob's public key in a newspaper, can she be sure that it was really Bob that published it? Can she be sure that she's reading a legitimate newspaper and not some clever forgery that Charles has printed up?

To create the necessary trust, public keys are distributed in public key certificates, which are digitally signed by a certificate authority. In signing a public key certificate, the certificate authority vouchsafes for the party's identity.

So when Alice examines Bob's public key, she's actually looking at a public key certificate that's signed by a certificate authority. Alice can verify the authority's digital signature and, so long as she trusts the authority, she can trust Bob's public key.

Now this may seem like nothing more than passing the buck. After all, in order to verify the certificate's signature, Alice needs to know the authority's public key. And that means that she has to trust that public key. Isn't Alice back to square one?

Fortunately, the answer is no. The problem is the same, but it's scale is much more manageable. While there are something like a quarter of a million Web sites today with their own public keys, there are only around 40 commercial certificate authorities. The public keys for these certificate authorities are pre-installed in Web browsers by their vendors.

Figure 8: Certificate authorities are pre-loaded in Web browsers.

To offer a secure Web site, therefore, the site operator has its public key certified by one of these established certificate authorities. A browser that accesses the site may not know whether it can trust the site itself, but it can trust the certificate authority that has signed the site's public key certificate.

Figure 9: SSL's protocol architecture inserts several components between the application and TCP.

The SSL Record Layer is common to all SSL messages. The record layer provides framing and padding for the other SSL components, and for the application. The record layer also identifies the particular SSL component in use for a given message; each of these components is like a separate mini protocol.

The handshake component is responsible for the negotiations that begin an SSL session. As we'll see, the communicating parties negotiate cryptographic algorithms, operating parameters, and key sizes.

The Change Cipher component is the simplest SSL component. There's only one Change Cipher message. It activates the negotiated security parameters for a session.

The Alert component lets the parties exchange error or warning information. It can identify problems with the protocol or potential security problems with the session.

Finally, there's the application itself. In this example that's HTTP. As the figure shows, the application communicates directly with the Record Layer which coordinates the TCP socket interface.

Figure 10 shows how these components contribute to an SSL message. In this case we're looking at a Client Hello message, which is part of the Handshake component. This message, like all SSL messages, begins with the Record Layer header. As the figure shading indicates, the Record Layer is 5 bytes in size. The first byte—22 in the figure—is the component identifier for the rest of the message. The value 22 identifies a Handshake message. The remaining four bytes provide the SSL version number (3.0 here) and the message length.

Figure 10: An SSL Client Hello message includes record layer and handshake components.

The Client Hello message itself follows. The first byte contains the message type. A value of 1 indicates Client Hello. The rest of the message consists of Handshake and Client Hello parameters.

Figure 11: The basic SSL negotiation requires the exchange of nine SSL messages.

The client begins the exchange by sending a Client Hello message. This message lets the server know that the client wants to establish secure communications. It also proposes a list of security parameters that the client would like to use for the communications.

These security parameters are known as "cipher suites"; they identify particular cryptographic algorithms, operating modes, and key sizes. A client can include multiple cipher suites in its Client Hello message. This gives the server the option of selecting from the list.

The server indicates which of the client's proposed cipher suites it prefers in a Server Hello message. This message also tells the client that the server is willing to proceed with the SSL negotiation. The server follows this immediately with a Certificate message. As you might expect, the Certificate message carries the server's public key certificate. This step is how the client learns of the server's public key. The server then sends a Server Hello Done message to the client. This message tells the client that the server has finished its part of the initial negotiations.

Now it's the client's turn. Internally, the client generates random numbers to use as a shared session key. It encrypts the session key with the server's public key and sends the result to the server in a Client Key Exchange message.

Notice that the server doesn't have to digitally sign anything to authenticate itself to the client. The client relies on the server's ability to decipher the Client Key Exchange message to verify the server's identity. If a hacker impersonates the server, the hacker won't have the server's private key, and the hacker won't be able to decipher the Client Key Exchange.

After the Client Key Exchange, the client sends a Change Cipher Spec message. This message tells the server to activate the negotiated cipher suite. From this point forward, all messages from the client will be encrypted using the algorithm from the Server Hello and the session key in the Client Key Exchange. The client follows this message with a Finished message. Since it follows the Change Cipher Spec, the Finished message is encrypted. It ensures that both parties are using the same cryptographic algorithms and parameters. If the message that follows the client's Change Cipher Spec doesn't successfully decrypt as a Finished message, the server knows something has gone amiss. If the decryption succeeds, however, the negotiation has succeeded.

At this point, it's the server's turn to send a Change Cipher Spec message. This message tells the client that all subsequent messages from the server will use the negotiated security. The server follows that message with its own Finished message. Again, this gives the client a way to confirm that the negotiated security is in place.

Alternate SSL Negotiation
One of the characteristics of the basic SSL negotiation is that the server uses only a single public key. That public key is used both for encryption and authentication. The client encrypts using the public key when it creates the Client Key Exchange message. And the public key is used implicitly to authenticate the server by forcing the server to decrypt that message in order to continue.

Historically, however, various governments (including the U.S.) have placed restrictions on the strength of encryption keys. Rarely, however, have there been restrictions on the strength of keys used for authentication. To accommodate this environment, SSL allows a server to use two different public keys. That way, the server can use a key for encryption that conforms to appropriate legal requirements while, at the same time, use a much stronger key for authentication.

Figure 12: An alternate negotiation sequence allows different keys for encryption and authentication.

This operation requires an additional message—the Server Key Exchange. The Server Key Exchange carries a public key that the client should use to encrypt the session key, and the Server Key Exchange message is digitally signed using the server's authentication key. The client must verify that signature using the public key from the Certificate message.

Client Authentication
Another option allows SSL to authenticate the identity of the client as well as the server. The server can request such authentication by sending the client a Certificate Request message. The client responds by sending the server a Certificate message and, later, a Certificate Verify message. The Certificate Verify message digitally signs data from the negotiation's initial messages, including the session key. The server verifies that signature using the public key it receives in the client's Certificate message.

Figure 13: SSL client authentication verifies the client's identity.

Even though SSL defines a client authentication process, it is not very common on the Internet for two main reasons. First, it may not be necessary. Electronic commerce servers, for example, can verify a user's identity by validating their credit card number. Second, client authentication requires that users install and manage public and private keys. Except in specialized environments, those tasks may be too challenging for typical users.

Resuming a Previous Session
As we've seen, establishing an SSL session can be a bit time-consuming. The process can take as many as 13 messages, and it may require up to five public key computations. Fortunately, the client and the server don't have to go through the entire process every time they want to communicate. If two systems have established an SSL session in the past, they can later resume that same session.

Figure 14: Resuming a previous SSL session requires fewer messages.

Here's how it works. When the client sends its Client Hello message, it includes a session ID from the earlier session. By doing so the client proposes to simply resume that earlier session. If the server agrees, it returns the same session ID in its Server Hello message. At that point both parties immediately send Change Cipher Spec and Finished messages and the negotiation is complete. Resuming a session in this manner only takes six messages, and it doesn't require any public key operations.

• Key Exchange Algorithms
  • Rivest, Shami, Adleman (RSA) Public Key
  • Diffie-Hellman with Digital Signature Standard (DSS)
• Symmetric Encryption Algorithms and Key Size
  • Data Encryption Standard (DES)
  • Triple Strength DES (3DES)
  • Rivest Cipher 4 (RC4)
• Message Digest Algorithms
  • Message Digest 5 (MD5)
  • Secure Hash Algorithm (SHA)

SSL was originally developed by Netscape Communications. Although Netscape always promoted open use of the protocol, it was (and still is) proprietary. Indeed, during the height of the browser wars Microsoft promoted a different (though very similar) protocol known as Private Communications Technology.

To fully promote SSL as a true open standard, its developers, along with others in the security community, decided to hand off responsibility for the protocol to a true international standard organization—the Internet Engineering Task Force (IETF). The IETF renamed the protocol TLS, but otherwise made very few changes. TLS version 1.0 is SSL version 3.1.

TLS features a few minor changes to SSL version 3.0, primarily in the addition of more Alert message types and in tweaks to some of the cryptographic computations.

The main benefit to moving the work to the IETF, however, is that it inherits a well-defined and open process to add to and revise the protocol. This has made it much easier to create official definitions of cipher suites that take advantage of advanced cryptographic technology, including elliptic curve cryptography and the new Advanced Encryption Standard algorithm.