> From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm > Sent: Friday, 22 February, 2013 05:06
> On 2/21/2013 11:12 AM, Mozes, Rachel wrote: [other reports say issue] > > affects just "The TLS protocol *_1.1 and 1.2_ *and the DTLS > protocol 1.0 > > and 1.2", but in the OpenSSL announcements it's described that this > > effects also SSL and TLS 1.0: "**They also apply to > implementations of > > SSL 3.0 and *_TLS 1.0_* that incorporate countermeasures to previous > > padding oracle attacks". > > > The OpenSSL security advisory links directly to the original > vulnerability report from a serious University. This report > explains in great detail that the security issue is in the > countermeasures against the old padding attacks. It's not "in" the countermeasure. As you say below, the new attack applies whether or not you have the old countermeasure. > Those countermeasures are mandatory in TLS 1.1 > and 1.2 implementations but are also necessary in any > implementations of > older SSL versions (whose specifications were printed before the > countermeasures could be mentioned in their text). > > So yes, this applies to all SSL and TLS versions (with the possible > exception of the insecure SSL 2), except for the following cases: > > - If an SSL/TLS library is vulnerable to the much more serious old > padding attack, the new attack cannot make it worse than using the > old attack. > Exactly. The new attack is not affected by the old countermeasure, but without the old countermeasure the old attack dominates. (And this case isn't actually an "except" from your statement.) > - If you use the (mostly insecure) RC4 algorithm, the issue > does not occur. > I've seen no convincing report of RC4 being broken or weakened as used in SSL/TLS implemented correctly. Over the years there have been serious problems with other applications and poor implementations which have given RC4 a bad reputation, but AFAIK none have touched the algorithm itself except for distinguishing it, which isn't important for SSL/TLS since the algorithm negotiation is almost always clear anyway. (And the new attack doesn't apply to RC4 because it's stream.) > - If you use the brand new AES-GCM mode (officially supported > only under > TLS 1.2), this is safe from the attack and is believed to be > secure against all known attacks, but unlike the other algorithm > options, AES-GCM stands and falls on the strength of a single key > and a single cryptographic primitive, which increases the risk if > an attack is ever found against that one key/primitive. > TLS1.2 and GCM are supported in OpenSSL only since 1.0.1, but were standardized (RFCs) in 2008 and the mode itself was adopted by NIST in Dec. 2007 (and proposed well before that). OTOH the other TLS/SSL implementations I regularly encounter haven't implemented it yet. > The report explains new improved countermeasures that combat both > the old and the new attack, and specifically praises the OpenSSL > fix for being even better than their own demonstration code for > the countermeasures. > Where is that? I don't see specific praise for the OpenSSL fix either in the paper or on http://www.isg.rhul.ac.uk/tls/ . ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
