SSL/TLS (part 3)

Published: 2011-09-25
Last Updated: 2011-09-25 02:08:01 UTC
by Mark Hofman (Version: 1)
5 comment(s)

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

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 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. 


This key and subkeys control how the ciphers are used.

This article 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.


Mark - Shearwater

5 comment(s)


For those of us who can't control the client side - what's the consensus? Switch to RC4 on the server side? From what I've seen so far, BEAST doesn't seem to introduce a substantial incremental threat. If it's a MITM attack that requires XSS, there are already plenty of other attacks that you would already be vulnerable to. Is there something blatantly obvious that I'm missing?

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).

From what I understand from the document (in Beast-SSL.rar), two attacks are involved:

(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!
I realized that my posting seemed to ignore Mark's comment regarding RC4. Sorry, I got distracted and got away from that thought - my question was more along the lines of which was a lower threat, since there are issues with both.

When you say "RC4 has its own weakness" I'm guessing you are referring to that if the same key is re-used to encrypt with a stream cipher, you get zero security (the encryption can be cancelled out). However, that is not possible in SSL/TLS.
Microsoft Security Advisory (2588513) released yesterday 9-26-2011, a security update is in development. My guess is that XP/2003/Vista/2008 will not be given an update to add support for TLS 1.1/1.2 but I hope I am wrong.

Diary Archives