TLS renegotiation attack. More bad news for SSL

Frank Breedijk on 2017-10-12

Three days ago on the 3rd of November Marsh Ray and Steven Dispensa of PhoneFactor released a whitepaper that describes a man in the middle attack against TLS and SSL v3 by using the “renegotiation” feature of the protocol.

Let there be no mistake, this is a limited, but still serious attack. This new attack adds to the issues published by Moxie Marlinspike, Dan Kaminski and Mike Zusman I blogged about earlier.

The attack described by Marsh Ray et al. exploits a feature of the TLS protocol called renegotiation. Renegotiation allows the TLS client or server to initiate a renegotiation of the encryption of the connection in order to refresh keys, increase authentication, increase the strength of the cipher suite or any other reason. This renegotiation can be performed by the server or the client by sending a server or client hello message.

The man in the middle attack works by intercepting and forwarding the first client hello message sent by the client (C) to the server (S) and then negotiating the cipher between the Man in the Middle (M) and the server only. At this point there is an encrypted session between M and S and M can insert his own data into the connection and even read the reply for the period that the underlying protocol (e.g. HTTP for HTTPS) allows for a reply to arrive. M then replays the original client hello message received from C which will start a renegotiation of the cipher between C and S. Depending on the timing of the replay of the client hello message C will either append its request to M’s request, receive the answer to M’s request or will not be aware of M’s request and S’ reply to M’s request.

TLS handshake with MitM renegotiation attack

Using techniques similar to request smuggling M can even insert his own request into a session that requires client certificate authentication. In fact the original whitepaper’s first example deals with TLS renegotiation in case of client certificate authentication. Like Cross Site Request Forgerythis attack allows an attacker to send requests to resource within the, possibly authenticated, context of the client. Because this attack requires the attacker to manipulate the traffic stream between client and server and is thus classified as a man in the middle (MitM) attack, it does not allow the attacker to decrypt any traffic sent between client and server.

What are the consequences of this attack?

While this attack does not completely break TLS, it does break on of its fundamental functions, in that it does not fully guarantee the integrity of the first request from the client to the server. This means e.g. that the attacker could insert a transaction into an online banking application without the user being aware. This attack does NOT affect the integrity of the reply from the server to the client (other than maybe not sending the reply to the client), so it does not allow the attacker to rewrite the reply from the server to the client. This means that if, e.g. an online bank publishes an overview of the transactions before and after the transaction is authorised, the user can spot the inserted transaction. The attack also does not affect the confidentiality of either the original request or the reply from the server, however as with cross site request forgery, it may allow an attacker to use the clients credentials (e.g. a client certificate, cookie, or password) without knowing them. While the attack only works for the first request sent over a TLS session (subsequent renegotiation requests are sent in the encryption context and can thus not be inserted) M could force the session to reset after x seconds of inactivity by sending a reset packet to both C and S, thus forcing a new TCP and TLS session to be re-established and thus gaining a new window of opportunity. Currently there are no fixes available. In their whitepaper Marsh Ray et al describe several possible solutions, which unfortunately all more or less break backwards compatibility. In response to this attack OpenSSL today released OpenSSL 0.9.8l which does not fix the vulnerability, but disables renegotiation completely. This change to OpenSSL may break certain applications so it should be carefully tested before it is implemented. From an HTTPS perspective the problem has similarities with cross site request forgery and can be defended against in a similar manner. If a program requires a unique session ID with sufficient entropy as part of the URL this session ID cannot be read or reused by the attacker. The problem currently has the full attention of Internet Engineering Task Force (IETF) TLS workgroupso hopefully they will come up with a fix soon. In the mean time you could disable renegotiation for OpenSSL based products if this does not break the application stack. While the attack does not break the confidentiality of the communication between client and server it does allow an attacker to insert text into the first request of the client, thus breaking its integrity. This issue is a fundamental protocol level issue that cannot be fixed without breaking backward compatibility. If the application using TLS (e.g. HTTPS) does not need renegotiation, turning renegotiation off may be a possibility, however there are numerous situations where renegotiation is needed (e.g. certain scenarios where client certificate authentication is used for https). I do not agree with Moxie Marlinspike who was quoted to say “It doesn’t affect your webmail, online banking or online shopping experience.” However the attack is hard to use and the attacker will need to have detailed knowledge of the application he is attacking. This attack will first appear in highly targeted scenarios. Since the attack is a man in the middle attack the attack will have to have control over all the traffic between client and server and vice versa in order to fully exploit the attack. With this attack TLS does not fully protect the integrity of the communication between client and server.

Originally published at