Le 15/03/2013 11:34, Huzaifa Sidhpurwala a écrit :
On Fri, Mar 15, 2013 at 3:39 PM, Erwann Abalea
<[email protected]> wrote:
Bonjour,
In my understanding, after a fast read of RFC5246, this won't work.
If RC4 is finally considered weak (at last), just don't use it anymore. Do
you use DES on your server? I guess no.
Thanks for a quick reply.
Perhaps i was not clear. I am not worried about _my_ server.
I just noticed some work being done in other SSL/TLS
open source library about this issue, and hence the question.
There is also some discussion at:
https://news.ycombinator.com/item?id=5364807
What I'm reading there is only a proposition to apply the 1/n-1 trick on
RC4 ciphersuites also (an AGL proposition).
Because TLS is MAC-then-encrypt, that will consume 1+MAC_length bytes of
the RC4 keystream. Either 21 or 17 bytes, depending on the MAC used
(SHA1 or MD5). The other 235/239 bytes will still be predictable. Repeat
the process until you have consumed the first 256 bytes of the RC4
keystream. For small sized requests (as are most requests), this has a
non negligible cost (20 bytes of MAC for 1 byte of payload, +TLS
encapsulation, repeated 13 times).
I guess the OpenSSL solution is to not use RC4 then?
OpenSSL has to be compatible with TLS specs, *and* other TLS stacks.
The 0/n or 1/n-1 tricks are valid according to TLS specs, but broke
compatibility with other stacks.
Modifying how RC4 is used isn't compatible with TLS specs, so it'll
break compatibility even more.
An openssl-based application could remove RC4 as the list of advertised
ciphersuites (that's easy on Apache, for example). But that's more a
server solution.
Since this attack is targetted toward clients, a client detecting that
RC4 is in use could add <something> before sensible data so that this
sensible data is beyond the 256 bytes predictibility horizon. Of course,
this <something> has to be compatible with the underlying protocol and
shouldn't change the semantics of the message. With HTTP, adding
proprietary junk header is possible.
This isn't an OpenSSL question, in fact. RC4 has known flaws, its use in
TLS has been enforced recently because it was an easy solution to the
BEAST attack.
A better solution (to BEAST) is to move on to TLS1.1+. A good solution
to CRIME is to disable compression. A good solution to LUCKY13 is to
avoid CBC.
Drop RC4 when possible, add AES-GCM with TLS1.1+ wherever you can,
upgrade software ASAP.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
