Before the third handshake, server Alice has to require a session renegotiation, including client authentication, on its connection with Mallory, possibly in response to Mallory’s request for some restricted resource. Mallory forwards the renegotiation request to client Bob.

Provided Bob agrees to authenticate with his client certificate at Mallory, both connections engage in a full renegotiation handshake with client authentication. This handshake is transported via the Record Layer of the previous session, that is, the session established in the second handshake.

According to RFC 5746, which defines the TLS Renegotiation Indication Extension ([148]), the Finished messages from the previous handshake must be present within the ClientHello and ServerHello messages of the new session. This is done to create a cryptographic binding between the new and the original session.

However, in the third handshake within the attack scenario described here, Mallory simply forwards all messages from Bob to Alice and back again (see Figure 20.8). The handshake completes successfully since the expected Finished values on both connections are the same.

Figure 20.8: The third handshake in the Triple Handshake attack. Mallory stays completely passive and does not know the key agreed between Alice and Bob. Regardless, Alice accepts earlier messages from Mallory after the second handshake, assuming they are coming from Bob

At the end of the third handshake, Mallory no longer knows the connection keys or the master secret; they are known only to Bob and Alice. Consequently, Mallory is not able to read or send messages on these connections any more.

However, because the new session is authenticated and cryptographically bound to the earlier session, Alice will regard the AppData1 sent after the second handshake as authentic data coming from Bob.

20.8.2 Countermeasures in TLS 1.3

While the attack did not have a large impact in practice, it showed that client authentication in TLS 1.2 was insufficiently implemented. In doing so, it had a profound influence on TLS 1.3 protocol design:

• RSA-based key establishment was removed from the available cipher suites in favour of Diffie-Hellman-based protocols. Moreover, the groups used for Diffie-Hellman (multiplicative group of a finite field or elliptic curve point group) must be chosen from a pre-configured list (see Section 7.10 Public-Key Cryptography in TLS 1.3, in Chapter 7, Public-Key Cryptography and Section 8.5, Elliptic Curves in TLS 1.3, in Chapter 8, Elliptic Curves).
• As we saw in Chapter 12, Secrets and Keys in TLS 1.3, the transcript-hash of all handshake messages prior to the establishment of the PreMasterSecret PMS affects the derivation of the MasterSecret (MS). This way, the MasterSecret is bound to the connection it was established within.

20.9 Summary

In this chapter, we covered attacks on TLS Handshake protocol. Since Alice and Bob use the handshake to establish the shared MasterSecret for their current TLS session, any successful attack on the handshake completely breaks the security of that TLS session.

While we looked into the attacks’ details, there are also some general lessons to be learned from these attacks. Downgrade attacks provide a practical example on how the presence of insecure configuration options and, on a more general level, legacy options kept for backward compatibility, can easily undermine security.

SLOTH illustrates that outdated cryptographic primitives are dangerous not only in theory, but also in practice. Intuitively, one might be tempted to think that theoretical weaknesses are difficult – or even impossible – to exploit in practice. SLOTH shows that a clever attacker is able to get around these difficulties.

Padding oracle attacks such as Bleichenbacher and its numerous improvements show how even solid cryptography can be broken if Mallory learns something about intermediate results of a cryptographic computation. Unfortunately, implementing cryptography in a way that exhibits no discernible variances when processing different inputs is surprisingly hard [92].

Insecure renegotiation is an excellent example of why it is important that both communication parties have the same view of the cryptographic protocol they execute. Insecure renegotiation happens due to the fact that when Mallory passes Bob’s TLS handshake request, Bob interprets the situation differently from Alice.

Finally, in the Triple Handshake attack, Mallory manages to break message authentication because an earlier unauthenticated message from Mallory is treated by Alice as if it belongs to some later, authenticated session between Alice and Bob. This shows that all keying material Alice and Bob agree upon in a specific session must be bound to that session.

In the next chapter, we will study attacks on the TLS Record protocol. In contrast to attacks described in this chapter, attacks on TLS records aim to extract data transmitted in the encrypted records.