Vulnerability in SSL/TLS protocol

According to reports, vulnerabilities in the SSL/TLS protocol can be exploited by attackers to insert content into secure connections.

If this is correct, it would affect HTTPS and all other protocols which use TLS for security, including IMAP.

The precise effects of the problem are not discussed in the reports. It would, however, appear to be possible to manipulate HTML content from websites during data transfer and, for example, inject malicious code.

The crux of the problem is, rather than a flawed implementation, a design flaw in the TLS protocol when renegotiating parameters for an existing TLS connection.

This occurs when, for example, a client wants to access a secure area on a web server which requires the requesting client certificates.

When the server establishes that is the case, it begins a renegotiation to obtain the appropriate client certificate.

The original request gets replayed during this renegotiation as if it had been authenticated by the client certificate, but it has not. The discoverer of the problem describes this as an "authentication gap".

According to the report, an attack could unfold as follows:
An attacker cuts into the connection between the client and server and establishes an HTTPS connection with the server.

He starts out by temporarily holding the connection to the client in an incomplete state. He sends the server an HTTPS request for a secure area – the server then renegotiates a completely new connection and requests the client certificate.

The attacker forwards all subsequent packets between the client and server unchanged. Finally, the attacker's HTTP request – e.g. a POST request for a protected form – is executed as if it came from the client.

The problem has been shown to exist in the latest versions of the Microsoft IIS and Apache Foundation httpd web servers, and OpenSSL are also affected.

A patch has been developed by Ben Laurie, but it merely stops renegotiation and does not resolve the actual problem. A long-term solution is under discussion.

One possibility would be to issue client certificates earlier, before a specific URL is requested. The IETF's TLS Channel Bindings Working Group is also reported to be working on a draft, which may already contain a solution.


See also:

• Authentication Gap in TLS Renegotiation, a report by Marsh Ray.
• Another Protocol Bites The Dust, a report by Ben Laurie.
• MITM attack on delayed TLS-client auth through renegotiation, a report by Martin Rex.