You can relax about the SSL break, mostly.

Posted by Tom Cross on November 06, 2009 at 2:48 PM EST.

Please also read my follow on post.

The security industry has been a buzz for the past couple days over a publicly disclosed break in SSL which allows a man in the middle to prepend data onto an HTTPS transaction. The vulnerability has caused quite a stir because everyone who makes a product that involves SSL or runs an SSL server will ultimately have to do something to address it, and no patches are yet available.

I have some good news for all of you. You can relax. Mostly...

As Moxie Marlinspike has pointed out in a couple of news media interviews, the impact of the attack scenarios that have been described so far is equivalent to a well understood vulnerability - Cross Site Request Forgery. Most major web applications already have protections against CSRF. So this SSL vulnerability is not a big deal, right?

For the most part, yes, but there are some corner cases that could still be a concern.

Let me describe the two attacks so that you can see how they are similar. I'll start with CSRF. Imagine an online bank that will perform a funds transfer when a logged in user performs a GET request to a particular URL. An attacker could craft a link to that URL with variables setup so that the attacker's account is credited whenever the link is accessed. The link could be embedded in an image tag on a web page, for example, so that whenever someone accessed that web page, the GET request would be performed automatically.

All the attacker would have to do is entice a currently logged in bank customer to view that web page. The user's browser would automatically perform the GET request to the bank when attempting to load the image. Their browser would include their bank login cookie along with that GET request, authenticating it, and the bank would happily transfer money into the attacker's account. That's Cross Site Request Forgery. It is a means of getting the victim to access a URL of the attackers choosing with the victim's cookies or other credentials.

Thats exactly what this new SSL man in the middle vulnerability allows. For example, the attacker intercepts his victim's https connection to the bank, sets up his own connection over which he requests the funds transfer URL, and then forces a ciphersuite renegotiation, which he passes through to the victim. The victim completes the ciphersuite renegotiation and submits his HTTP request, including his cookie. The web server accesses the URL specificed by the attacker using the cookie specified by the victim. Different attack but similar result.

Most, if not all, major web applications have implementation level protections against CSRF, such as random nonces in web forms that must be submitted along with any request. Those protection measures are effective against this new SSL man in the middle attack. Therefore, this vulnerability has minimal security impact for most websites and Internet users.

Its important to note that although the security implications of these attacks are similar, they are not the same attacks. Network level protections against CSRF such as IPS signatures or WAF rules will not prevent this new SSL MITM attack from working. Only implementation level anti-CSRF features will work.

Also, there is another important caveat. Imagine a case where the SSL attacker has intercepted a POST request from the victim to the funds transfer URL. The victim's request includes the correct random nonce values that the web application is using to protect itself from CSRF. The attacker injects the same URL that the victim was accessing, but also injects different POST variables before handing control over to the victim, perhaps specifying a different destination account number for the funds transfer.

The web application gets the correct nonce values, but also some POST variables that came from the attacker. In some cases the application might get multiple copies of particular POST variables with different values, some from the attacker and some from the victim. Which ones will the application trust? It depends on how the application was implemented.  

This sort of attack scenario is much more esoteric than the ones that have been described so far in conjunction with this vulnerability. Its highly dependent upon the application implementation and the attacker's ability to predict when the victim will access the specific form the attacker seeks to manipulate. I don't expect that you'll see the neighborhood kids running it down at the airport lounge this weekend. But ultimately, SSL implementations are going to have to be patched.