20.8 Triple Handshake attack

In the Triple Handshake attack [29], an attacker posing as a man-in-the-middle causes two separate TLS connections, namely one from client Bob to attacker Mallory and another from attacker Mallory to server Alice, to share the same PreMasterSecret (PMS) and the same sessionID. In two subsequent handshakes, client authentication is broken by Mallory because application layer data sent by Mallory is accepted as authentic messages coming from Bob by Alice. In this respect, the Triple Handshake attack is similar to insecure renegotiation. In this case, however, the client authentication (via signatures and certificates) within TLS is attacked, while insecure renegotiation targets higher-layer authentication mechanisms such as username/password.

20.8.1 The attack

In the first handshake (shown in Figure 20.6), the TLS 1.2 client Bob deliberately connects to a server run by Mallory, not knowing that Mallory is malicious. Having received Bob’s clientHello message, Mallory turns around and connects, as a client, to server Alice using the same clientRandom (CR).

Next, Mallory forwards Alice’s serverRandom (SR) and sessionID (SID) to Bob. Moreover, as we have seen, Mallory can force Bob and Alice to use RSA for key establishment by offering the corresponding cipher suites as the only option. This means Bob sends EPKMallory(PMS) as his key exchange message to Mallory, where PMS is the PreMasterSecret chosen by Bob.

Now Mallory can decrypt PMS, re-encrypt it, and send it to Alice. Basically, the result of the first handshake are two sessions sharing the same key materials and session parameters (SID,MS,CR,SR), but having different server certificates and finished messages. The latter is caused by the fact that Mallory had to manipulate the cipher suites offered by Bob. Note that at this point authentication is not yet broken because Bob is aware he is connected to Mallory, while Alice is connected to some anonymous client.

Figure 20.6: The first handshake in the Triple Handshake attack. Afterwards, the two sessions on the left and on the right have the same MasterSecret and SessionID

In the second handshake (see Figure 20.6), client Bob reconnects to Mallory and asks to resume their previous session [29] (see Section 6.5.3 in Chapter 6, Transport Layer Security at a Glance). Mallory, in turn, reconnects to server Alice and asks to resume their previous session as well. Since all the relevant parameters on the two resumed sessions are the same, Mallory can in fact simply forward the abbreviated handshake messages to Bob and Alice unchanged. On completion of the abbreviated handshake, the two connections again have the same keys, but now they also have the same Finished messages. Mallory knows the new connection keys, so he can continue to send encrypted data on either connection towards Bob or Alice, as is shown at the bottom of Figure 20.7.

At this point of the attack Bob still (rightly) believes he has established a connection with Mallory, and Alice still believes that she has a connection with some anonymous client, so neither of them has been impersonated yet. This happens in the third and final handshake of the attack.

Figure 20.7: The second handshake in the Triple Handshake attack. Both sessions now also have the same Finished messages. CV D and SV D stand for Client Verfication Data and Server Verfication Data, respectively