The Role of Secure Sockets Layer (SSL)

SSL was developed by Netscape in 1996 [Netscape01] for the purpose of securing HTTP data between the Web user and Web server. However, the design of SSL allows it to secure not just HTTP, but any data communicated over any connection-oriented, end-to-end reliable protocol (such as TCP/IP). The protocol uses a combination of public-key algorithms and symmetric-key algorithms to authenticate the server side, optionally authenticate the client side, and secure all communications using encryption between the two sides.

During an SSL connection, the communicating parties exchange all messages using the SSL Record protocol. There are four types of messages:

• Handshake

• Alert

• Change cipher spec

• Application data

Handshake messages negotiate the SSL session parameters, which include authentication information, data encryption algorithm, and so forth. Alert messages indicate an error condition and are either warnings or fatal errors. The ChangeCipherSpec message tells the receiving party that all subsequent messages will be secured using the previously negotiated parameters. Application data represents the data that is being secured by the SSL protocol.

An SSL connection maintains two types of state: session state and connection state. The session state contains the security parameters negotiated by the communicating parties, including authentication information such as certificates, encryption algorithms, and a master "secret" value. A connection state is created for each separate connection (for example, each HTTP GET) and maintains security parameters for that connection, such as encryption key values and sequence numbers.

The idea behind the two states is to avoid the overhead of authentication every time a new connection is set up between the communicating parties. One of the parameters of the session state is a master secret value that is agreed upon after authentication and negotiation of security parameters have occurred. Using this shared secret, the communicating parties can derive new key values for securing new connections, thereby implicitly reauthenticating each other.

When an SSL connection is started, the first order of business is for the communicating parties to negotiate security parameters such as authentication and encryption algorithms. These parameters are referred to in SSL as the CipherSuite, which is represented as an integer. For example, the integer 4 refers to CipherSuite SSL_RSA_WITH_RC4_128_MD5 (authentication using RSA public-key certificate, data encryption using 128-bit RC4, and data integrity using an MD5 hash). A full list of CipherSuite assignments is available in the spec [Netscape01].

The first message sent in this negotiation comes from the client (the initiator of the secure connection) and is known as the ClientHello. The ClientHello contains a list of CipherSuite options that are acceptable to the client for securing the connection. The server responds with either a ServerHello message indicating the CipherSuite to be used or with a fatal alert indicating that none of the client's options were acceptable. The ServerHello also contains a session identifier that can be used by the client for creating future SSL connections. The next messages depend on the selected CipherSuite, but most require server authentication, so the server sends its digital certificate.

The public-key value in the certificate will be used to authenticate the server. The client then generates a random value, encrypts it with the server's public key, and sends it back to the server in the form of the ClientKeyExchange message. The random value is then known by both parties and is used to calculate the session's master secret, from which key values are derived for securing communication data, both for the current connection and future ones. This is also the major step in authenticating the server. Unless the server is the true owner of the public key, it will be unable to create the key values necessary to communicate later in the process.

Lastly, both client and server send a ChangeCipherSpec message, indicating that from this point onward, all messages will be secured using the negotiated security parameters. Both sides then send a "Finished" message, the first message secured with the negotiated security parameters. The Finished message contains a value that is the result of the negotiated hash function value computed on all handshake messages. Both communicating parties ensure that the hash value is correct, and then they continue sending application data secured with the negotiated security.

Figure 2-10 illustrates an SSL handshake.

Figure 2-10. An SSL handshake

When the client wants to create a new network connection with the same server, the overhead of exchanging certificates and key values can be skipped. When sending the ClientHello message, the client can specify the session identifier returned by the ServerHello during the initial connection setup. If the server still has the session information associated with that session identifier, it will send a ChangeCipherSpec to the client, indicating that it still has the session info and has created the pertinent key values to secure this new connection. The client will then send a ChangeCipherSpec message. The two parties can then continue sending secured application data. (See Figure 2-11.)

Figure 2-11. SSL connection reuse of session information

Transport Layer Security (TLS)

The TLS specification was authored in 1999 by Certicom, mostly as an attempt to create an official IETF standard protocol out of SSL 3.0. However, TLS and SSL are not exactly the same. The TLS specification [RFC2246] describes TLS as being based on the SSL 3.0 Protocol Specification as published by Netscape. The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate (although TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0). As the saying goes, the great thing about standards is that there are so many to choose from.

Fortunately, the two protocols are so alike that, despite the fact that they do not interoperate, the mechanism by which a TLS implementation can back down to SSL 3.0 is pretty simple. In fact, TLS identifies itself as version 3.1 to differentiate itself from SSL 3.0 and the older, broken SSL 2.0. The differences between the two protocols include: TLS and SSL 3.0 use a slightly different keyed MAC algorithm (TLS uses the new HMAC [RFC2104], which is very similar to the keyed MAC used in SSL 3.0), TLS chooses more data to include in the MAC (it includes the protocol version along with the data and data type), and TLS does not support FORTEZZA, a hardware-based security token based on the ill-received and mostly unused Skipjack security infrastructure. All of the basic principles of the SSL protocol described in the previous section, such as ClientHello messages and ChangeCipherSpec messages, are the same in both protocols.

Security Issues with SSL/TLS

SSL is a fully disclosed, open protocol that has been reviewed by some of the best in the business [Schneier01]. Despite that, SSL has been reported as "broken" (a session could be hijacked) or similar more than once since its inception. As discussed later in this chapter, Ian Goldberg and David Wagner ten years ago described how they could eavesdrop on a secured SSL session with Netscape version 1.2 and recover the communication being secured in a matter of minutes [Goldberg01]. This demonstrated how an error in the implementation of SSL could undermine its security.

More recently, it was discovered in 2003 that certain browsers allowed SSL communications using the CipherSuite SSL_NULL_WITH_NULL_NULL. This is the initial CipherSuite in SSL communications, the expectation being that the only communication using this CipherSuite are the exchanges described earlier to negotiate one of the secure CipherSuites. However, a malicious Web site, for example, could negotiate use of this CipherSuite, and the client would assume that normal SSL security was in place (the browser would show the lock icon, indicating an SSL session, which would be accurate) even though all communications were actually "in the clear" (unencrypted). Moreover, the malicious Web site could impersonate another, legitimate, Web site, and there would be no name mismatch warning because the CipherSuite SSL_NULL_WITH_NULL_NULL does not require a certificate. (Most browsers raise a warning if the server presents a valid certificate but the name on the certificate does not match the Web site name.)