Hoylen's Weblog

Thu, 11 Mar 2010

TLS renegotiation security vulnerability

In November 2009, a security vulnerability in TLS was announced. This affects nearly all implementatations of TLS, but the IETF is working quickly at revising the TLS specification to address the problem. A lot of the articles about the problem characterise the problem as a flaw in the TLS protocol, but actually the problem is not with TLS but how it is (incorrectly) used.

I have been reading the original paper Authentication Gap in TLS Renegotiation and the vulnerability results from a number of things. If you know something about the technical details of TLS, I recommend reading the article for yourself.

The main problem comes from a connection consisting of an insecure session being renegotiated into a secure session. During the insecure session, a man-in-the-middle can inject some malicious data into the request sent to the server. This is fine according to the TLS protocol. TLS knows that the data sent over the first session is not to be trusted.

The problem comes about because the application incorrectly treats the all the data as having the same security as the second session, after the renegotiation with the legitimate client. That is, it incorrectly treats the data received over the insecure session, before the renegotiation, as secure when it should not. So the vulnerability comes about because the application protocol was incorrectly using TLS. This is an example of where important information has been abstracted away--a common problem in system design: the presence of different sessions should not have been abstracted into a single connection with one level of security.

Einstein said, "everything should be made as simple as possible, but no simpler." Unfortunately, in this case they did make it simpler!

Before you panic: the vulnerability only allows the man-in-the-middle to inject its data into the beginning of the request. Although they could use that to inject their own requests, they can't see the real request or the response--those are still encrypted for the legitimate client.

So I would not be too hasty in blaming TLS itself for the vulnerability. Except, that SSL/TLS was originally designed to secure HTTP and introducing sessions with different security (a concept which HTTP does not support), so it could be argued that it didn't completely meet the requirements properly. Unfortuntely, this is also a common problem in system design.

It is desirable to design components as separate pieces, but when they come together there can be unintended problems.