> From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm > Sent: Monday, 25 February, 2013 03:07
> On 2/25/2013 4:26 AM, Dave Thompson wrote: <snip my mistake> > The attack is against the specific timing differences that occur when > directly implementing the RFC suggested countermeasure against the > much larger (but different) timing side channel that would appear > without the countermeasure. > > Specifically, with no countermeasure against the old attack, wrong > padding would cause a much faster error response (because the MAC > was not done), the old countermeasure causes a slightly slower > response to wrong padding due to MAC-ing more bytes than with proper > padding. > Right. Sorry, I don't know what I was thinking. <snip same again> <snip RC4> > >> - If you use the brand new AES-GCM mode (officially supported > >> only under TLS 1.2), this is safe from the attack <snip> > > 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. > > 2007 is recent compared to e.g. AES/Rijndael and 3DES EDE in CBC mode > and RC4. More recent certainly, but not "brand new". > I have seen recent signs that Windows 7 and Server 2008 R2 support the > GCM modes. > On my newest convenient test case, IE9 on Server2008R2 SP1, it doesn't. As I understand the Windows design (not too well) SSL/TLS features need support in schannel and also in the app (IE or other) so this could be a problem on the IE side. But if and when MS does support it, good. > > > >> 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/ . > > > In section 7 in a graph on page 16 and text on page 17, column 1 they > describe how they tested their own proposed countermeasure as a patch > against OpenSSL 1.0.1 > > In the last paragraph of section 7, on page 17, column 7, they describe > that a larger patch against OpenSSL (which I presume is the one you > applied) goes above and beyond to give away even less timing information. > Aha! I re-checked, and they updated the paper without my noticing. The version I had downloaded was dated 4 Feb., now it's 27 Feb. On a fairly cursory comparison I see: - they changed 1.2 to update status of implementation fixes - they added 5.6 about the non-LAN case (briefly) - at the beginning of 6.1 "Experimental results for GnuTLS" (col 1 on pg 13) they inserted a paragraph about random padding - and they added to that last para in 7, which formerly had only the first sentence "To achieve further reductions ... would require ... 'constant time' programming approach." (Nit: I didn't apply any patch, I just use releases when they come out.) ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
