On 2/25/2013 4:26 AM, Dave Thompson wrote:
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.
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.
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.)
As I explained above, the new attack fails without the old
countermeasures because the sign of the timing difference is the
opposite of what the attack expects (making a combined attack should
be trivial though, but I refuse to help with that).
- 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.)
Hmm, my general impression from lots of documents (no citations,
sorry) seem to be that RC4 is estimated to be generally weaker
than more modern ciphers such as AES in pure counter mode. I also
think that distinguishing attacks against a stream cipher do
foreshadow or even facilitate full on attacks, though I am no
cryptanalyst and cannot say so with confidence.
- 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.
2007 is recent compared to e.g. AES/Rijndael and 3DES EDE in CBC mode
and RC4.
I have seen recent signs that Windows 7 and Server 2008 R2 support the
GCM modes.
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.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
