> From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm > Sent: Wednesday, 29 February, 2012 15:51
> I do not know why MS KB2643584 does not mention changing TLS 1.1 > and/or TLS 1.2 behavior, maybe someone familiar with the attack > described in CVE2011-3389 knows a reason. > Well, at least with the description. AFAICS they didn't release some of the details needed for the actual attack. (Which probably was wise.) TLS1.1 changes CBC mode to randomize the IV per record instead of chaining as SSL/TLS1.0 did, and thus is immune (if correctly implemented, as always). (And TLS1.2 keeps this improvement.) > My general guess at this time is that the MS workaround of > artificially splitting certain unspecified SSL records is not the > only way to fix CVE2011-3389 and that this particular workaround > has not been tested by the OpenSSL core team. > The fix simply sends two appdata records, first with length=1 and second with length=N-1. OpenSSL returns them separately, which applications might not handle (choice #3 in your list). SSL/TLS always promised "stream not guaranteeing boundaries" service like TCP which it was/is intended to substitute for. TCP apps do encounter splitting and joining in the real net and have had to cope with it or be limited to backwaters. But SSL/TLS implementations mostly *did* preserve boundaries before this fix (they have to do record-level processing anyway, while TCP does segments directly on IP) and apps/programmers have tended to rely on it by mistake or laziness. OpenSSL some years back tried sending a record with length=0 and then the real one (length=N), which also defeats the attack but is more debatable and certainly counterintuitive and was found to cause problems with other implementations. It might work better now; I haven't heard that an effort has been made to re-check -- it would probably need many volunteers to cover the gamut. See SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS . > I hope that now that we have apparently tracked this to a general > MS implementation change which is unrelated to the restricted CAC > hardware, that figuring out the OpenSSL compatibility issue will > be a lot easier than when only USG employees and contractors with > a CAC card could do the testing. > As Dr. Henson's replies indicate, there must be some other factor here. Yes if it can be reproduced openly that should help. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
