The latest version of the ssl specification is the third major version of the ssl protocol. And, although ssl version 3.0 is well established, some existing systems may support only earlier versions of the proto- col. One of the decisions facing developers of current ssl systems is whether to support communication with those older implementa- tions. Adding such support will require additional work, and may re- sult in slightly weaker security. Supporting older versions will provide the greatest degree of interoperability, however. Fortunately, ssl ver- sion 3.0 mechanisms can easily accommodate compatibility with ear- lier versions.
The details of ssl versions prior to 3.0 are outside the scope of this book. However, since compatibility with version 2.0 remains a feature of the latest popular Web browsers, even engineers whose only con- cern is version 3.0 may find it useful to understand some aspects of version 2.0 compatibility. Network engineers looking at captured
protocol traces, for example, may well discover version 2.0 Client- Hello messages crossing their networks. To aid in such understand- ing, this section looks at how systems negotiate ssl versions, the details of the version 2.0 ClientHello message, and version 2.0 cipher suites.
5.1.1 Negotiating SSL Versions
If a system wants to interoperate with both ssl version 2.0 and ssl version 3.0 systems, one obvious requirement is that the system itself must implement both ssl version 2.0 and version 3.0. It uses the ver- sion 2.0 implementation to communicate with other version 2.0 sys- tems, and the version 3.0 implementation to communicate with version 3.0 systems. This simple statement raises the obvious ques- tion: How does the system know which is which?
The answer lies in the very first message that the two parties ex- change—the ClientHello. The next subsection describes the format of this message in detail, but the essential element of this message is this: a client prepared to support either version 2.0 or version 3.0 sends a version 2.0 ClientHello message. The message is a perfectly legitimate version 2.0 message, but it contains enough hints so that a version 3.0 server, if it’s paying attention, can recognize that the cli- ent also supports version 3.0. Such a server responds using the ssl version 3.0 protocol, and a normal version 3.0 handshake ensues. Figure 5-1 shows how this negotiation works when the server only implements ssl version 2.0. Such a server recognizes the version 2.0 ClientHello message, but it is oblivious to the special 3.0 hints. The server treats it like any other version 2.0 message and continues the version 2.0 handshake negotiation. In contrast, Figure 5-2 shows how a version 3.0 server responds. The server is not only capable of under- standing the version 2.0 ClientHello, it also understands the special hints. The server, therefore, recognizes that the client is capable of ssl version 3.0. It uses the standard version 3.0 handshake process for the rest of the communication.
The server’s responsibilities are fairly simple. If it receives a standard version 2.0 ClientHello (without the version 3.0 hints), it responds
using ssl version 2.0. If it receives a version 3.0 ClientHello or a ver- sion 2.0 ClientHello with the special hints, it responds using version 3.0. Even servers that do not support ssl version 2.0 should still ac- cept and respond to the version 2.0 ClientHello with the special hints. Such servers can reject other version 2.0 messages.
There is one final twist to this process. Since version 3.0 has security improvements over version 2.0, systems should ensure that they’re using version 3.0 in every possible circumstance, even when a mali-
v2 Server v2 ClientHello (with hints)
v2 ServerHello
1
2
Dual Version Client
v2 handshake continues ...
Figure 5-1 Clients can successfully negotiate with a version 2.0 server.
v3 Server v2 ClientHello (with hints)
v3 ServerHello
1
2
Dual Version Client
v3 handshake continues ...
cious party tries to trick them into falling back to version 2.0. The most likely threat is from a malicious system that interposes itself be- tween the client and server. During the negotiation phase, it pretends to be a server when talking to the client, then turns around and pre- tends to be the client when talking to the server. Figure 5-3 shows how such a man-in-the-middle attack might unfold. As the figure shows, the attacker modifies the ClientHello to remove the special version 3.0 hints. This modification will force the client and server to use ssl version 2.0, even though both are capable of the newer (and more secure) version 3.0.
The ssl specification defines a special technique that allows two sys- tems to detect the attack if it were to occur. The client takes the first step. When a dual-version client ends up using ssl version 2.0 rather than version 3.0, it uses special padding values in the version 2.0 Cli- entKeyExchange message. In particular, it sets the last 8 bytes of the padding to the special binary value 00000011. This value indicates that the client could have supported version 3.0. Normal version 2.0 servers will be oblivious to the padding value. Dual version servers
Dual Version Server v2 ClientHello v2 ServerHello 1 3 v2 handshake continues ... Dual Version Client Man-in-the-Middle
Attacker
v2 ClientHello
2
v2 ServerHello
4
(with v3 hints) (hints removed)
that receive a version 2.0 ClientKeyExchange, however, can look for the special padding value. If the server finds it, then an attack is oc- curring. Note that the attacker will not be able to modify the padding (and thus remove the incriminating 00000011 bytes) because the cli- ent encrypts that information using the server’s public key.
5.1.2 SSL Version 2.0 ClientHello
Even servers that support only ssl version 3.0 may still need to un- derstand version 2.0 ClientHello messages. As the previous subsec- tion indicated, they may receive such a message from a dual version client. The actual message contents are similar to those of the version 3.0 ClientHello, but the format is significantly different.
Figure 5-4 shows a typical version 2.0 ClientHello as a dual version client might build it. As the figure shows, the Record Layer is only 2 bytes, and consists of a protocol type (128 is used for handshake mes- sages) and a single byte for the message length. The actual handshake
... 2