22.2 FREAK

FREAK stands for Factoring RSA Export Keys. The attack was discovered in 2017 ([27]) and can be seen as a variant of the cipher suite downgrade attack shown in Figure 20.1 with respect to RSA as a key establishment mechanism. It works if server Alice supports weak, export-grade RSA cipher suites. Interestingly, client Bob may even support only strong RSA cipher suites for the attack to work.

More specifically, in the FREAK attack, Mallory modifies the cipher suite list sent by the client to be

and forwards it to the server.

If the server accepts this cipher suite and sends a corresponding ServerHello back, Mallory modifies it to a stronger, non-export RSA cipher suite, as follows:

The client now ought to use the strong RSA public key contained in the server’s certificate for securely transporting PreMasterSecret to the server. However, along with its certificate, the server also sends a ServerKeyExchange message containing an ephemeral export-grade RSA public key with a 512-bit module. Because of a state machine composition bug in OpenSSL, the client silently accepts this message and the server’s strong public key is replaced with the weak public key in the ServerKeyExchange message. It is because of this bug that FREAK is classified here as an attack on TLS implementations.

The client then uses the weak ephemeral RSA key to encrypt PreMasterSecret. Today, such a 512-bit RSA modulus can be factorized within hours. While this may still be too long for the ongoing handshake, even ephemeral keys are often reused for days.

22.3 Truncation attacks

The TLS record protocol takes each message from the higher layer application protocol (usually HTTP) and protects it with in a single TLS record. TLS may also fragment the message before encrypting it. The TLS security services of integrity and authentication therefore only refer to single messages or their fragments.

In a truncation attack, an attacker acting as man-in-the-middle suppresses complete TLS records or fragments, with the result that client and server become de-synchronized with respect to their current state: For example, a client having sent a logout request to the server assumes that they are logged out. If the logout request is suppressed by Mallory (e.g., by injecting an unencrypted TCP FIN packet), however, the server will continue to assume the client is logged in.

In [167], the authors demonstrate the potential of this kind of attack to take control of Microsoft Live accounts. By using simple traffic analysis, they found out that packets carrying logout requests to account.live.com tended to be between 474 and 506 bytes long, and simply dropped all packets within this range. If client Bob now leaves his terminal, believing he has successfully logged out, Mallory can take over his account if he has the capability to access Bob’s terminal.

In another variant of truncation attacks, in section III of [29], the authors show how cookie-based authentication can be compromised by truncating HTTP headers. When setting an authentication cookie, the server provides the URL of the requested response, the cookie, and a secure flag within its Set-Cookie header. The secure flag makes sure the authentication cookie is sent only via HTTPS. Mallory now triggers a request from the client to a URL that has just the right length so that the first TLS fragment of the server response ends before the secure flag in the Set-Cookie header. Mallory then suppresses the second fragment containing the secure flag. As a consequence, the cookie will be sent by the client in plaintext via HTTP.

While these attacks are quite severe, it seems that security in these cases mainly depends on secure application logic. For example, the described attack against authentication cookies was only possible because some browsers accepted incomplete HTTP responses. Moreover, as is pointed out in [167], clients need to be reliably notified about server-side state changes.