I thought the vulnerability that BEAST uses is already fixed on "Microsoft" side, no? Can someone please clarify this?:


The TLS support for browsers right now is:

  • IE9 TLS 1.0, 1.1, 1.2 all supported via Schannel
  • IE8 TLS 1.0 supported by default, 1.1 and 1.2 can be configured
  • Opera - 10.x supports TLS 1.0, 1.1, 1.2

I don't count older versions of any of these browsers, since people really should have auto-update on. if they don't they've probably got bigger problems ( http://isc.sans.edu/diary.html?storyid=11527 )

  • Mozilla/Firefox - TLS 1.0 only
  • Chrome - TLS 1.0 only (though an update is rumoured)
  • Safari - TLS 1.0
  • Cell phones - various support levels (webkit has tls 1.2 since Nov 2010, but for individual phone browser implementations your mileage may vary)

2 Answers 2


Without knowing the internal workings on the patch I can only guess, but...

Both IE and IIS support versions of TLS that are not vulnerable to BEAST, e.g. TLS 1.1 and 1.2, but these versions are not on by default. Also, it's dependent on the cipher suite used in the connection for 1.0. The patch could do a number of things like turn the versions on by default, or disable the particular cipher suite that is vulnerable to BEAST.


Since the patch has been released some time ago, we can now have more information. The security bulletin is quite devoid of technical information, but some clues can be gathered from reading the KB article about known issues. The patch does, basically, two things:

  1. The patch activates TLS 1.1 support. This support was already included in Internet Explorer, but not enabled by default, because there were some buggy servers which did not tolerate it (in a SSL/TLS handshake, the client announces his maximum supported version, but some server implementations refuse to talk to clients who announce anything else than SSL 3.0 or TLS 1.0). Microsoft seems to have decided that fixing BEAST was more important than supporting faulty SSL servers.

  2. The patch implements record splitting. In SSL/TLS, data is encoded as records, each record being encrypted by itself. The BEAST-related flaw is about records in SSL 3.0 and TLS 1.0 with CBC encryption, where the IV is extracted from the end of the previous record, thus predictable by an attacker eavesdropping on the line. Record splitting is about automatically splitting an n-byte records into two records, the first one being very small; this has mostly the same net effect as choosing a random IV for each record (which is what TLS 1.1+ does), and this fixes BEAST, with a small size overhead (not much). A 0/n split would be ideal (i.e. prefixing each data record with an empty record) but tends to break too many existing implementations, in particular the one in Internet Explorer 6.0; hence, a 1/n-1 split is often employed, and almost as good. This is probably what the Microsoft patch applies.

Record splitting is used when the server chooses SSL 3.0 or TLS 1.0, and a CBC-based cipher suite.

Note that practical application of BEAST also requires a rather flexible way to do cross-site requests, something which the BEAST designers (Duong and Rizzo) could achieve only by exploiting one of two weaknesses, which were in Javascript WebSockets (draft version) and in Java (Sun/Oracle implementation), respectively; both weaknesses were also fixed. The Microsoft patch we are discussing here addresses the underlying vulnerability of CBC encryption with predictable IV.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .