A proposal to countermeasure BEAST attack
I posted the proposal to countermeasure the BEAST attack in Bug 665814 at Bugzilla@Mozilla. For quick reference, I copy it in the blog:
Xuelei Fan 2011-07-20 20:35:42 PDT Comment 59:
Xuelei Fan 2011-07-20 20:35:42 PDT Comment 59:
One significant drawback of the current proposed countermeasure (sending empty application data packets) is that the empty packet might be rejected by the TLS peer (see comments #30/#50/others: MSIE does not accept empty fragments, Oracle application server (non-JSSE) cannot accept empty fragments, etc.) We've been looking at a slightly different countermeasure that should comply with the TLSv1.0/SSLv3.0 specifications, and likely won't break implementations. Would you please review the following proposal? If this is sound, this might avoid the empty packet issue, and the switches necessary to configure it. Looking at the spec of TLS, the block-ciphered structure is defined as: block-ciphered struct { opaque content[TLSCompressed.length]; opaque MAC[CipherSpec.hash_size]; uint8 padding[GenericBlockCipher.padding_length]; uint8 padding_length; } GenericBlockCipher; This implies that if the TLSCompressed.length is less than the cipher block size, the MAC and padding data [1] will be used to construct the first block. The countermeasure: instead of sending a completely empty fragment before the supplied application data, send the first byte of application data in a packet, followed by the remaining data from the write call. I think this should work because the TLS specification requires content followed by the MAC. Like the proposed solution, you're still removing the adaptive guessing mechanism from the IV calculation, but in a different way. Assume here a cipher block size of 8. Since the MAC effectively randomizes the IV for successive SSL/TLS packets, if this first byte is one of the bytes being guessed, that still leaves a search space of 28 (1 byte of data) * 256 (MAC) = 264, which is the same as the cipher itself. If the 1 byte is known plaintext, then the MAC will change the IV for successive packets, and the attacker is not given the chance to adapt the input Pj. Implementations should readily accept 1 byte of application data, so this will likely address the empty fragment issue, while complying with the SSL 3.0 and TLS 1.0 specifications. Looking forward to your comments. Thanks, Xuelei [1] From a quick review of the standard hashes and ciphers of TLS cipher suites, the CipherSpec.hash_size should be always bigger or equal to block size. So the first block of an cipher operation should not contain the padding data.