Solution for SSL/TLS design weakness in sight

A solution to the TLS renegotiation vulnerability discovered in the design of the SSL/TLS protocol early last November is on the horizon. The Internet Engineering Task Force (IETF) has ammended the RFC 5246 specification (Transport Layer Security [TLS] Protocol Version 1.2) and introduced a new renegotiation_info TLS extension which will store a connection's cryptographic information. The problem was caused by a flaw in the TLS protocol design that affects the parameter renegotiation of an existing TLS connection. Previously, the TLS protocol offered no conclusively authenticated associations between the client requests before and client requests after a TLS renegotiation. The new extension stores additional information to describe the state of a TLS connection ("secure_renegotiation", "client_verify_data" and "server_verify_data").

The hole allows attackers to inject arbitrary packets into secure SSL connections and, for instance, compromise web applications. In a simulated attack on Twitter, developers managed to attach the tweets a victim transmitted via SSL to their own tweets, which allowed them to access the cookie's authentication data. However, the vulnerability does not allow attackers to read SSL connections in plain text.

TLS renegotiations become necessary in various circumstances, for example when a client wants to access a protected area on a web server and the server requests an SSL client certificate for authentication.

In this situation, the protocol does not require a conclusive association between the request and the URL to the subsequently submitted client certificate – the server simply assumes it is correct. The developers who discovered the problems therefore talk about an "authentication gap". An illustration of a potential attack scenario can be found on the G-SEC blog.

As a workaround, most vendors simply switched off TLS renegotiation. This doesn't appear to have caused any major disruptions. The approval of the draft "Transport Layer Security (TLS) Renegotiation Indication Extension" now allows vendors to develop a secure patch for re-enabling TLS renegotiation. However, extensive testing will be required before such a patch becomes available, and developers will particularly need to ensure the interoperability and backwards compatibility of various implementations. A vendor status overview is available from the PhoneFactor Resource Center.

See also:

• Password theft via vulnerability in SSL/TLS protocol, a report from The H.
• Vulnerability in SSL/TLS protocol, a report from The H.

(crve)