SSL/TLS (part 3)
I was hoping for a more official release of the document, but you will be able to find the document and the sample decrypt java code here http://www.insecure.cl/Beast-SSL.rar .
The paper is an interesting read. To me it outlined the weakness in using CBC very nicely and the attack is well described. Certainly one of the more readable crypto papers I've come across. I will suggest you read it whilst well fed, and rested.
So is SSL/TLS dead?
The attack essentially implements a mini MITM attack using javascript delivered initially through a Cross Site Scripting (XSS) flaw. In a more traditional SSL MITM attack the application will terminate the SSL connection, present a new certificate and then establish a SSL connection to the originally requested site. Because the certificate is selfsigned, it would typically throw up an error, allowing the user to notice that there is something going on. This attack works at a lower level. The SSL connection isn't interrupted. The weakness in using Cypher Block Chaining (CBC) is exploited to get access to the desired information. Whereas in the traditional MITM attack the user has a chance of noticing, with this attack they are unlikely to. As is outlined in the imperialviolet blog there are easier ways to attack. We do however need to keep this one in our minds.
How to fix it?
Well the easiest would be for web sites and browsers to stop using TLS v1.0, but as Rob points out in a previous diary http://isc.sans.edu/diary.html?storyid=11629 That may not be as easy as we think. The only other choice we have is to start disabling those ciphers that utilise CBC, but that may not work either as there are precious few cypher suites available that do not use CBC. Using stream ciphers will address the issue, but may introduce new ones (RC4 has its own weakness).
Chrome has already addressed the issue and the fix on the browser side is quite simple and elegant. We'll see the other browsers implement something similar over the next few weeks. That doesn't fix the protocol, but it will help address the immediate issue of clients being attacked in this manner.
If you do want to change the cipher defaults, in Windows world, you will need to make some registry changes.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
This key and subkeys control how the ciphers are used.
This article http://support.microsoft.com/kb/245030 explains how to change protocols and weak cyphers (make sure you test in a test bed first).
As things develop, we will keep you posted.
Regards
Mark - Shearwater
Comments
It's an interesting find from a crypto perspective, and I'm sure it will be built upon - in its current state though, it doesn't seem like something that we need to be burning the midnight oil to patch for (even if a patch were available on the server side).
Terry
TerryM
Sep 26th 2011
1 decade ago
(1) Proof of (and possibly enhancements of) the known plain-text weakness in CBC;
(2) Demonstration of that weakness by making use of vulnerabilities in web browser and/or plugins that violate the "same-origin policy". Although this is an achievement and enables spectacular demonstrations, IMO it is not the most important issue at hand (this can and should be fixed anyway).
I think that web servers that provide mixed content (both http and https) put users at maximum risk - if those users communicate via a network an attacker has access to (open Wifi access points, compromised company network).
In such a case the attacker will be able to inject https requests with known plaintext in http data from the web server to the client, and subsequently crack the https data exchanged between client and server.
Please correct me if I'm wrong on this!
Erik van Straten
Sep 26th 2011
1 decade ago
Terry
TerryM
Sep 26th 2011
1 decade ago
Dave O
Sep 26th 2011
1 decade ago
baillard
Sep 27th 2011
1 decade ago