20.1 Downgrade attacks

As we have seen in Chapter 18, TLS Cipher Suites, the TLS protocol allows Alice and Bob to negotiate cryptographic settings for the TLS connection they want to establish.

The ability to negotiate cryptographic parameters has a twofold benefit. First, it ensures maximum possible compatibility in the heterogeneous landscape of TLS endpoints. As long as Alice and Bob share a single TLS cipher suite, they both support and a single security setting they are willing to accept – for instance, that server Alice authenticates herself using a certificate and client Bob does not need to authenticate himself – they will be able to establish a TLS connection.

Second, it enables cryptographic agility. Without negotiation, all TLS clients on the internet would have to transition to the new cryptographic algorithm at once, or else parts of the TLS ecosystem would stop working. With negotiation, this transition can happen gradually, allowing a grace period during which older TLS endpoints can be updated and without disrupting operations.

The downside of this flexibility is that negotiation enables so-called downgrade attacks. Downgrade attacks use negotiation mechanisms to weaken the cryptographic protocol by making Alice and Bob choose weak security parameters or weak cryptographic algorithms.

20.1.1 Taxonomy of downgrade attacks

In [2], Alashwali and Rasmussen introduced a taxonomy for downgrade attacks on TLS. Their taxonomy classifies attacks based on the following attributes:

• The protocol element that is targeted (cryptographic algorithm, protocol version, or protocol layer)
• The type of vulnerability that enables the attack (implementation vulnerability, design vulnerability, or trust-model vulnerability)
• The attack method (modification, deletion, or insertion of protocol messages)
• The level of damage that the attack causes (broken or weakened security)

The term design vulnerability denotes a flaw in the protocol design, that is, a security flaw in the protocol specification. In contrast to an implementation vulnerability, Eve and Mallory can exploit a design vulnerability even if the protocol’s implementation is error free.

The term trust-model vulnerability denotes a flaw in the protocol ecosystem’s architectural aspect and the trusted parties involved in this architecture. As a result, Eve and Mallory can exploit a trust-model vulnerability even if both the protocol design and the implementation are secure.

20.1.2 Cipher suite downgrade attacks

In a cipher suite downgrade attack, Mallory forces Alice and Bob to use weaker cryptographic algorithms than they intend to use.

Figure 20.1 shows a simple example of a downgrade attack on TLS 1.2. The example assumes a certificate-based unilateral server authentication using ephemeral Diffie-Hellman key exchange:

Figure 20.1: Example of a downgrade attack on simplified TLS 1.2

The attack works like this:

1. Bob initiates the TLS handshake by sending his nonce nB and a list of cipher suites (A0,A1,…) within his ClientHello message to Alice. We may assume that Bob’s list contains only cryptographically strong cipher suites from which Alice can choose. However, Mallory intercepts Bob’s message and modifies it to contain only a single weak export-grade cipher suite Aw containing, for example, a 512-bit DHE group for key establishment.
2. As a result, if Alice supports export-grade cipher suites – for instance, to ensure backward compatibility with legacy TLS clients – she will select cipher suite Aw, as this is the only option available to her. She then sends her nonce nA and the cipher suite Aw to Bob.
3. To prevent being detected, Mallory modifies Alice’s message by replacing Aw with A1. Bob, in turn, receives nA,A1 and has no way to detect Mallory’s presence.
4. Next, Alice sends her digital certificate certA followed by her (weak) public key parameters pkAw within her ServerKeyExchange message. She also signs the nonces nB,nA and her public key parameters pkAw.
5. Because in TLS 1.2 and below, Alice’s signature does not cover her cipher suite choice – in our example, the cipher suite Aw, Bob cannot tell whether the selected cipher suite is cryptographically strong or not. As a result, Bob will not recognize the public key parameters sent by Alice as weak.
6. In the next step, Bob sends his own public key parameters pkB to Alice so they both can compute the PreMasterSecret PMS, the MasterSecret MS, and the shared client and server session keys.
7. Because of the weak public-key parameters that Alice has sent, Mallory is able to recover the private exponents from Alice’s public key and compute the PreMasterSecret. In particular, Mallory can fake the final finished messages from Bob and Alice so that the initial manipulation of the cipher suites goes unnoticed.

As a result, Mallory is able to compute all secrets and keys established between Alice and Bob for that particular session and, therefore, completely break the TLS session. The attack does not, however, have any impact on earlier or future TLS sessions between Alice and Bob.