TLS renegotiation attack. More bad news for SSL

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.
 

So what does this new attack do?

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.

What can be done against this attack?

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.

Conclusion

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.

6 Comments

Marsh Ray
Nice writeup! I like your diagram!

"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."

Actually, M doesn't have to use an exact copy of the client's hello, it just has to be reasonably similar. Some servers are stricter than others, but even if they were all perfectly strict, M could make his match perfectly if he wanted to. Actual clients show some variation in client hellos even over the same connection.

The "Reply to evil request" in your diagram is specifically a TLS "Hello Request", indicating the server wants to renegotiate. Actually, even this is optional on some servers, some allow the client (i.e., mitm) to conduct an unsolicited renegotiation!

Also, M needn't allow the server's "Finished" message to make it all the way back to the client. In these cases, M can forward C's credentials to another server and C (if it's a browser) never even shows the scary page.
Frank Breedijk
Thanks for your comment, I have two questions.

I understood from your paper that client and server can initiate a renegoiation at any time, however all your examples revolve around a server initiated reneg. Why is this? Does eliminating server renegotiation elemitate the problem?

When you say that M can forward C's cerdentials to another server this seems to indicate the the attack can compromise the confidentiality of C's request. If I understand correctly in order for C to send the request it has to have receive a valid server key exchange, which includes the server certificate and a server hello done, thus placing the request in the C-S cipher context.

Thanks for your reaction.
Marsh Ray
<blockquote cite="#commentbody-1365">
<strong><a href="#comment-1365" rel="nofollow">Frank Breedijk</a> :</strong>
Thanks for your comment, I have two questions.

I understood from your paper that client and server can initiate a renegoiation at any time, however all your examples revolve around a server initiated reneg. Why is this?
</blockquote>
Because that's the first case I got working. I agree, it is unfortunate that our document spends a bit too much time on the client cert case, but we had very little time to update it before going public.

It is a very important case, however.

<blockquote cite="#commentbody-1365">
<strong><a href="#comment-1365" rel="nofollow">Frank Breedijk</a> :</strong>
Does eliminating server renegotiation elemitate the problem?
</blockquote>

Eliminating all renegotiation does solve the problem, some sites may be able to turn it off entirely (OpenSSL has patches for that already).

Very little client-initiated renegotiation is needed, probably none for https, so that will be relatively easy to patch.

Many https servers will be able disable server-initiated renegotiation.
A minority, but significant, number of https apps depend on it.

Really, the best solution is for everyone to patch with the new TLS protocol extension header as soon as it becomes available. This patch will drop in the missing bit of crypto needed to make renegotiation safe.

<blockquote cite="#commentbody-1365">
<strong><a href="#comment-1365" rel="nofollow">Frank Breedijk</a> :</strong>
When you say that M can forward C's cerdentials to another server this seems to indicate the the attack can compromise the confidentiality of C's request. If I understand correctly in order for C to send the request it has to have receive a valid server key exchange, which includes the server certificate and a server hello done, thus placing the request in the C-S cipher context.
</blockquote>

Good question. You're right, C will only send the http request after he checks the server certificate. However, due to an artifact of the design of TLS, client cert and smart card credentials have to be presented _before_ he has a chance to fully check the server's credentials.
Servers will execute M's evil request as soon as they receive the client cert/smart card credentials.

<blockquote cite="#commentbody-1365">
<strong><a href="#comment-1365" rel="nofollow">Frank Breedijk</a> :</strong>
Thanks for your reaction.
</blockquote>

Any time. I need all the help I can get to get the word out that everyone needs to update as soon as patches are available. People should also expect their browsers to inform them when they are connecting to an unpatched server.

- Marsh
Sylvain Maret
Thanks for this nice article.

A have a question: Does this attacks works if we use mutual SSL Client Authentication with a cert in the Browser ?

Sylvain
Frank Breedijk
The attack works with client site certificates if the server allows renegotiation. Since the certificate is sent in the replayed client hello message and subsequent handshake an attacker would be able to execute a reuest of his liking and still authenticate with the client certificate.
A TLS MitM attack where the attacker can inject arbitraty data before the clients original request is very feasable. Client site certificates do not change this, on fact, the first demonstrated attacks where against webservers that requested client side certs.
MitM Plaintext Injection Vulnerability in TLS (openssl) &laquo; waffle
[...] TLS renegotiation attack. More bad news for SSL | Cupfighter.net [...]

Not Published

0/1000 characters
Go Top