The Handshake Protocol is composed of three subprotocols that allow peers to agree upon security parameters for the Record Protocol, authenticate them- selves, instantiate negotiated security parameters, and report error conditions to each other.
The Handshake Protocol is responsible for negotiating a session for the Record Protocol, which consists of the following items:
Session identifier. This is an arbitrary byte sequence chosen by the server to identify a session.
Peer certificate. This is an X.509 certificate of the peer. This element may be absent if authentication is not performed.
Compression method. This is the algorithm used to compress data prior to encryption.
Cipher spec. This specifies the bulk data encryption algorithm (such as Triple DES) and the HMAC one-way hash algorithm (such as SHA-1). It also defines cryptographic attributes (such as hash size).
Master secret. This is a large secret value shared between the client and server.
Is resumable. This is a flag indicating whether the master secret for this session can be used to initiate new sessions.
These items are then used to set Record Protocol security parameters. The resumption feature allows many protected connections to be established from the single handshake. This feature is used to reduce the overhead and is especially important when a client and server have several short connections. The cryptographic parameters are produced by the Handshake Proto- col. When a client and server first start communicating, they agree on a
130 Part III ■ Secure Email
protocol version, select cryptographic algorithms, optionally authenticate each other, and use public key cryptography to establish shared secret values. The Handshake Protocol involves the following six steps. Figure 13-7 illustrates the protocol messages that implement these six steps.
1. Exchange hello messages to negotiate algorithms and exchange random values.
2. Exchange cryptographic parameters to agree on the premaster secret. 3. Optionally exchange certificates and cryptographic information to
authenticate the client and server to each other.
4. Generate a master secret from the premaster secret and exchanged ran- dom values.
5. Provide security parameters to the Record Protocol layer.
6. Confirm that the peer has calculated the same security parameters and that the handshake occurred without tampering.
To improve performance by avoiding pipeline stalls, the change cipher spec message is an independent TLS Protocol content type, and it is not actually a TLS Handshake Protocol message. Figure 7-1 includes the change cipher spec message to show the logical flow.
BobServer ClientHello ServerHello [Certificate] [ServerKeyExchange] [CertificateRequest] ServerHelloDone [Certificate] ClientKeyExchange [CertificateVerify] {ChangeCipherSpec} Finished {ChangeCipherSpec} Finished Protected Application Data
Alice
Legend:
[ ] Optional Handshake Protocol message { } Not really part of the Handshake Protocol
Turner c07.tex V3 - 03/26/2008 5:38pm Page 131
Chapter 7 ■ Protecting Email Passwords, Headers, and Commands 131
When the client wants to resume a previous session or duplicate an existing session, the client sends a client hello message that includes the Session ID of the session to be resumed. If the server still has the session parameters in its cache and the server is willing to reestablish the connection, the server sends a server hello message with the same Session ID value. At this point, both the client and server send change cipher spec messages and finished messages.
One should not rely on the Handshake Protocol to always negotiate the strongest possible protection for a connection between two peers. Eve, employ- ing a man-in-the-middle attack, may be able to convince two peers to select an insecure set of parameters. For example, Eve might cause the peers to negotiate an unauthenticated connection. To avoid man-in-the-middle attacks, the appli- cation protocol must be cognizant of its security requirements and not transmit on the protected stream unless those requirements are met. Of course, this is in conflict with transparently layering applications on SSL and TLS. To preserve transparency, all of the offered alternatives in the negotiation should meet the application protocol security requirements. The SSL and TLS protocols are secure to the level of the cipher suite that is selected. If an AES-128 symmetric key is transferred using a 2048-bit RSA key from a validated certificate, then one can expect very reasonable cryptographic security.
The certificate and key exchange messages convey the data necessary to establish the premaster secret. When RSA is employed, the client generates the random premaster secret value and encrypts it in the server’s RSA pub- lic key. When Diffie-Hellman is employed, the client and server exchange public keys, then the result of the classic Diffie-Hellman key agreement computation is used as the premaster secret.
In TLS 1.0 and TLS 1.1, a pseudorandom function (PRF) built from SHA-1 [FIPS180] and MD5 [RFC1321] is used to generate the master secret and symmetric keying material. Two different one-way hash functions are used to ensure security even if one of the algorithms is found to have a flaw. The problem is that both of them have been shown to weaker than expected. It is not a catastrophic failure by any mean, and this concern is being addressed by the IETF in the TLS 1.2 specification. The first use of the PRF generates the master secret from the premaster secret and the random values from the client hello message and the server hello message. The second use of the PRF generates two symmetric keys, two initialization vectors (IVs), and two Message Authentication Code (MAC) secret values from the master secret and the random values from the client hello message and the server hello message. In a resumed session, the master secret from the parent session is used, but new random values are employed, resulting in different keying material.
The Record Protocol uses one symmetric key, one IV, and one MAC secret value to protect the traffic flowing from the client to the server. The Record Protocol uses the other symmetric key, the other IV, and the other MAC secret value to protect the traffic flowing from the server to the client. Obviously,
132 Part III ■ Secure Email
both client and server need all six secret values for correct operation of the