SSL Demystified

Before a company publishes a new Web site containing content that it wants to protect from prying eyes, an administrator or business unit manager examines what types of data the IIS servers are about to publish. "Maybe the data should be encrypted," a security-minded person suggests. "No problem," the Web server administrator replies. "Purchase those yearly certificates to give us the encryption we need and we'll be just fine."

But just how does encryption really work? What level of encryption do you need? These questions are frequently asked but rarely answered. This month, I discuss the primary method of encryption in IIS—the Secure Sockets Layer (SSL) protocol.

The History of SSL
Netscape developed the original version of SSL in 1994. Netscape's goal was to create an encrypted data path between a client and a server regardless of platform or OS. Netscape also designed SSL to take advantage of new encryption schemes as they become available, such as the recent adoption of the Advanced Encryption Standard (AES), which replaced the Data Encryption Standard (DES).

A few months after it released SSL 1.0, Netscape released an update to the specification as SSL 2.0. In November 1995, Netscape made the specification for SSL 3.0 public. Since 1995, version 3.0 has grown in popularity and become a standard. SSL 3.0 is the version most Web servers, such as IIS 5.0 and IIS 4.0, support today.

You can implement SSL in either 40-bit and 128-bit encryption, (40-bit and 128-bit refer to the size of the session key). A session key is a pair of secret words that a server and client share; these keys are used in the encryption process of every SSL session. Mathematically speaking, the longer the session key, the harder it is to break the encryption of the SSL session and read the transmitted data. SSL is widely used in its 40-bit strength internationally and in its 128-bit strength domestically, although the laws that restrict distribution of encryption technologies always change a few years behind the industry.

SSL Components
SSL takes advantage of the strengths of both public-key and symmetric-key encryption technologies. Public-key technologies securely authenticate clients and servers; they also securely trade secret symmetric keys used in the encryption sessions. Symmetric-key encryption, which is much faster than public-key technologies, encrypts the application data.

SSL works at the Transport and Session layers of the Open System Interconnection (OSI) model to support the Application layer, where both the Web server and browser interoperate. The SSL protocol has two layers—the SSL Record protocol and the SSL Handshake protocol, which Figure 1 shows. The SSL Record protocol permits the encapsulation of higher-level protocols, such as the SSL Handshake protocol and other Application-layer protocols (e.g., HTTP). The SSL Handshake protocol facilitates authentication of servers and clients, negotiation of the SSL session's characteristics, and data transfer.

The SSL Record Protocol
An old railroad company used the slogan "Everything Rides Our Rail." You could say the same thing for the SSL Record protocol. The SSL Record protocol doesn't deal with records, per se; rather, it's the encapsulation method for the SSL Handshake protocol and the SSL Alert protocol. The SSL Record protocol builds the data path between sender and receiver. This data path starts out unencrypted, but before the server sends any secrets or application data, SSL uses public-key encryption to encrypt the data path. All other SSL messages and application data will ride on this protocol. Thus, the SSL Record protocol is the foundation for all data transfer.

The SSL Handshake Protocol
The SSL Handshake protocol runs on top of the SSL Record protocol. During a typical SSL session, the server and client exchange several Handshake protocol messages during the transaction. Depending on the chosen encryption type, a server using the SSL protocol uses public-key encryption technologies to authenticate itself to the client. Table 1 provides a list of all the messages that make up the SSL Handshake protocol. (Some of these messages are sent by the client, some by the server.)

The SSL Alert Protocol
The SSL Alert protocol also runs over the SSL Record protocol. The SSL Alert protocol signals problems with the SSL session ranging from simple warnings (e.g., unknown certificate, revoked certificate, expired certificate) to fatal error messages that immediately terminate the SSL connection. For example, you might receive the You are about to leave a secure Internet connection warning because an SSL client received a closure_notify alert from an SSL server.

How the SSL Protocol Works
The SSL protocol takes messages to be transmitted, breaks up the data into smaller, more manageable fragments, applies a media access control (MAC), and transmits the message. Compression is optional. A typical SSL session begins with a little negotiation. Using the SSL Handshake protocol, an SSL client contacts the server with a ClientHello message, as Figure 2 shows. The SSL client attempts to negotiate session parameters with the SSL server, such as which algorithm to encrypt with, which version of the SSL protocol to use, whether authentication is necessary (i.e., required by either the server or the client), and which type of public-key encryption to use to swap shared secrets.

The client initiates an SSL session by telling the SSL server the latest version of SSL it can support (e.g., SSL 3.0) and which public-key algorithms it supports (e.g., RSA, Diffie-Hellman, Fortezza), in order of preference. If the SSL session is an existing session, the ClientHello message contains a session ID that the client can use to resume a previous SSL session. The ClientHello message also contains a random series of characters used later in the MAC process.

The server responds with a ServerHello message, which contains either the latest version of SSL the server can support or the client's latest version, whichever is earlier. The message contains a random series of characters that are different from those included with the ClientHello message. The ServerHello message also contains a session ID that can resume a previous SSL session. If the client asked the SSL server to present a client certificate, the server presents it. The server offers a certificate that is usually X.509-compatible. Depending on the encryption algorithm, the server might request the client's X.509 certificate in return and pass a server key. The Client then responds with either a No certificate alert or its own certificate, a client key, and an optional Certificate verify message to ask for the client's certificate in return for validation.

When the ClientHello and ServerHello sessions are complete and the client and server have settled on the SSL version, encryption methods, and compression, the ChangeCipherSpec message passes between server and client. The ChangeCipherSpec message is a protocol type, not a Handshake message. A ChangeCipherSpec message contains the chosen encryption algorithm and a Message Authentication C algorithm, such as MD5 or the Secure Hash Algorithm (SHA), used to verify message integrity. This message represents the starting point for the encryption process. After the ChangeCipherSpec message, the Finished message passes between the server and client, and the flow of application data can commence.

The ChangeCipherSpec message signals that a change (e.g., in encryption states) to the state of the SSL session is about to occur. Within SSL, two states for the ChangeCipherSpec message exist—read pending and read current. Any change to the state of an SSL session must first be written into read pending, then copied into read current. This graceful notification process between client and server lets a change in the SSL session occur without having to renegotiate the connection.

SSL also has the ability to resume a previously negotiated session if the TCP communications between client and server are interrupted. During the initial exchange between the SSL client and server, the server gives the client a session ID, which helps the server keep track of that SSL session. The client can ask that the server resume the SSL session without having to renegotiate parameters. In a resumed SSL session, the ClientHello message contains the session ID of the previous SSL session, as Figure 3, page 13, shows. If the SSL server has a match in its cache, the server responds with the same session ID. The client and server go straight to exchanging ChangeCipherSpec messages and Finished messages, and application data follows. If the SSL server doesn't have a match, the server answers with a new session ID. The new ID won't match the client's offering, and the client and server negotiate new session parameters.

The Future Direction of SSL
SSL 3.0 has evolved into the Internet Engineering Task Force (IETF) Transport Layer Security (TLS) 1.0 protocol, sometimes referred to as SSL 3.1. For information about TLS, see IETF Request for Comments (RFC) 2246. SSL discussions contain many references to TLS, and it's likely that you'll see TLS in the next version of IIS.

The Best Protocol
SSL is a combination of the best of symmetric-key encryption and public-key technologies. The protocol is adaptable, and you can use it with new encryption algorithms as they come on the market. When combined with a Web server, this technology lets users conduct private and secure sessions (assuming that both the client and server themselves are reasonably secure). For SSL-related resources, see Related Reading.

Nearly every popular Web server today supports SSL or its successor, TLS, in one version or another. IIS has supported SSL for some time as its built-in encryption mechanism. I would look for the next major release of IIS to support both SSL and TLS.

End of Article