Earlier I had posted a blog explaining the BEAST vulnerability observed in TLS 1.0 & SSL 3.0. Here is the blog link: http://blogs.msdn.com/b/kaushal/archive/2011/10/03/taming-the-beast-browser-exploit-against-ssl-tls.aspx

Microsoft released MS12-006 patch last week to address BEAST. As usual, after this updateSmile, we were bombarded with cases.

After applying this update, supposedly many applications were in a broken state (mostly 3rd party). Everyone was blaming MS (as usual) for the problem. I don’t think most of them understood what this patch was all about. Reading further you would realize what broke the applications.

The security patch implemented a solution which was present in the RFC documentation and is as per the RFC 2246. Below is a snippet from the rfc:

6.2.1. Fragmentation

The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType may be coalesced into a single TLSPlaintext record, or a single message may be fragmented across several records).

struct {
uint8 major, minor;
} ProtocolVersion;

Dierks & Allen            Standards Track                      [Page 16]

RFC 2246           The TLS Protocol Version 1.0             January 1999

enum {
change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255)
} ContentType;

struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;

 

Now, I need not explain what the BEAST vulnerability is all about. You can refer my blog for this.

MS12-006 FIX for BEAST

  1. The security patch mainly addresses the vulnerability in protocols TLS 1.0 & SSL 3.0.
  2. The BEAST vulnerability is addressed by splitting (or fragmenting) the application data in to SSL records in the fashion 1/(n-1). This is explained in RFC2246 (section 6.2.1 Fragmentation).

This is where the problem arises, most of the applications haven’t implemented the RFC correctly. They assume that the application data will be packed into a single packet. Whenever the data is split into records, they don’t understand the response and leads to incompatibility between them.


Please refer this link for supported protocols on Windows OS: http://blogs.msdn.com/b/kaushal/archive/2011/10/02/support-for-ssl-tls-protocols-on-windows.aspx


Addressing the compatibility issues

KB2643584 was introduced to address the compatibility issues caused by the MS12-006 security patch.

  1. It contains fixit links to enable TLS 1.1 protocol for IE (Client) and Windows based Servers.
    NOTE: This is applicable to Windows 7 and Windows Server 2008 R2 only.


  2. Disable the fragmentation/splitting of records which causes the in-compatibility. This is done via a editing the registry. Below are the steps to change the registry:
    • Click Start, click Run, type regedit in the Open box, and then click OK.
    • Locate and then click the following subkey in the registry:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL

    • On the Edit menu, point to New, and then click DWORD Value.
    • Type SendExtraRecord for the name of the DWORD, and then press ENTER.
    • Right-click SendExtraRecord, and then click Modify.
    • In the Value data box, type 2 to disable the split record in schannel, and then click OK.
    • Exit Registry Editor.

NOTE: The above registry key disables the patch applied on the server and the server is exposed to the vulnerability again. In this case you will have to disable all CBC based ciphers and prioritize RC4 based  ciphers.

Splitting of records is the only real solution available for the following OS’s as they don’t support TLS 1.1 & TLS 1.2:

  • Windows XP
  • Windows Vista
  • Windows Server 2003
  • Windows Server 2008

On Vista and Windows Server 2008, one can prioritize the RC4 based ciphers over CBC based ciphers. This cannot be done in XP or 2003 though.

Till then Ciao! Smile