SSL and TLS Renegotiation Vulnerability Discovered
Details of a new vulnerability involving SSL and TLS has been discovered. The vulnerability involves a flaw in renegotiation and allows man-in-the-middle attackers to surreptitiously introduce text at the beginning of an SSL session.
Ivan Ristic explained some of the details of the SSL Renegotiation attack:
The problem is with the renegotiation feature, which allows one part of an encrypted connection (the one taking place before renegotiation) to be controlled by one party with the other part (the one taking place after renegotiation) to be controlled by another. A MITM attacker can open a connection to an SSL server, send some data, request renegotiation and, from that point on, continue to forward to the SSL server the data coming from a genuine user. One could argue that this is not a fault in the protocols, but it is certainly a severe usability issue. The protocols do not ensure continuity before and after negotiation.
To make things worse, web servers will combine the data they receive prior to renegotiation (which is coming from an attacker) with the data they receive after renegotiation (which is coming from a victim). This issue is the one affecting the majority of SSL users.
The following example demonstrates how the flaw can be exploited by an attacker to send an arbitrary request using the authentication credentials of a victim. The red parts are sent by the attacker and the blue parts are sent by the victim.
GET /path/to/resource.jsp HTTP/1.0
Dummy-Header: GET /index.jsp HTTP/1.0
Cookie: sessionCookie=Token
Attacks have been demonstrated to be effective against Apache and Microsoft IIS webservers. A group of some of the world's biggest technology companies have been meeting for over a month to discuss a new industry standard to fix the flaw, but it will take some time to roll out because it affects nearly all types of servers, browers, and other devices.
Dan Goodin noted the difficulty in using the attack:
Ray and Dispensa were quick to note that the vulnerability would most likely have to be exploited in concert with some other security weakness, say a flaw in a home router or the recent DNS bugs discovered by researcher Dan Kaminsky. And even then, an attacker would be unable to read encrypted data that flowed between a server and a client.
Indeed, Moxie Marlinspike a security researcher who has repeatedly exposed serious shortcomings in SSL, said the attacks were hard to pull off in the real world, in large part because they appeared to target a rarely used technology known as client certificate authentication.
"It's clever, but to my knowledge the common cases in which the majority of people use SSL (webmail, online banking, etc.) are currently unaffected," he wrote in an email. "I haven't found these attacks to be very useful in practice."
...Already, developers from OpenSSL and GNU TLS have developed patches and are in the process of testing them. Other providers of hardware and software that implement SSL are in various stages of patching as well. Dispensa and Ray presented their findings under a non-disclosure agreement to a large number of company representatives on September 29 in Mountain View, California, at a company they declined to name.
The parties had planned to continue working on a fix in secret throughout the rest of the year. Coincidentally, a separate researcher recently documented the basics of the protocol defect and made some of the findings public, prompting Ray to disclose his research. The flaw has existed in TLS since the specification was published in the mid 1990s.
Ivan Ristic suggested some ways to mitigate problems caused by this vulnerability:
- If you can, disable renegotiation. There isn't normally a configuration option to do this, but patches are being developed and will be available soon. The majority of web sites do not use renegotiation so disabling it won't be a problem. Those that do will need to make changes to their sites to make them work without it.
- Use a web application firewall to monitor the contents of all request headers to spot what seems like an embedded HTTP request line. The good news is that the embedded request line will not be obfuscated, making it easier to detect. I do not believe that this advice can help the bypass of the client certificate authentication, though.
- If you can, monitor all connections that make use of the renegotiation feature. That won't help you if renegotiation is an integral feature of your web site, but it may do if it is rarely used.
More information:
- Extended Subset - Authentication Gap in TLS Renegotiation
- Links - Another Protocol Bites The Dust
- The post by Martin Rex to the TLS mailing list that prompted public disclosure.
- Slashdot discussion of the vulnerability
- Tim Callan - New SSL attack makes headlines
Originally posted on Thu Nov 5, 2009
Comments