Hacker News new | past | comments | ask | show | jobs | submit login

We can stop using RC4

http://dl.dropbox.com/u/24257718/cipher_chart.png

Virtually all server side hardware can do AES-NI instructions in hardware now (unless you are using ATOM cpu for ssl connections?) and most non-mobile hardware clients can do AESNI too for AES-128




The problem with AES isn't performance. Sites have been using AES ciphersuites in TLS for many years.

The problem is that the widely-deployed AES ciphersuite, like the ciphersuites for triple DES and IDEA, uses a construction from the '90s that is itself insecure. It's based on CBC mode (which is fine) in a MAC-then-encrypt configuration (which is not), which lead to the Lucky 13 attack, and which until TLS 1.1 didn't properly set up the IVs for each record, which lead to BEAST.

No major site used RC4 because it was more performant. They used it as a workaround to Lucky 13 and BEAST, because they couldn't count on browsers fixing those problems fast enough.


True, but at least BEAST is probably not that much of a concern[1], not sure about the state of Lucky 13 in the grand scheme of things.

[1] http://security.stackexchange.com/questions/17080/is-there-a...


Adam Langley is more concerned about mitigating the CBC mode attacks in TLS than he is about the RC4 attack. I'm going to take his word for that.


BEAST causes PCI scan failures from the major scanning vendors. Therefore it's a significant practical issue for any site taking credit cards.

Try the https://www.ssllabs.com/ssltest/index.html scan and you'll see what it thinks of your SSL setup. With BEAST vulnerability you get non compliance.


So as a sort-of-amusing counterpoint to this article, I know at least one ASV who insists that the only way to mitigate BEAST is to disable all ciphers but RC4. Still scratching my head on that one.

That tool you posted is great, hugely helpful for anyone who has to deal with this stuff.


This is a pretty good illustration of why professional appsec people don't like PCI.


Yes, I know, but it seems a little bit misguided / misleading, particularly since the BEAST in particular was pretty much mitigated in most browsers (see the link I posted + other links I posted below).


Agreed. Not defending pci. Nevertheless some qsa is going to get their panties in a twist if their scanning tool goes red.


https://community.qualys.com/blogs/securitylabs/2011/10/17/m...

     ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH


https://bugzilla.mozilla.org/show_bug.cgi?id=480514

(The idea behind the config above is to propose TLS 1.2 ciphersuites, which aren't susceptible to BEAST, and leave RC4 as a fallback for older TLS implementations. But TLS 1.2 support in browsers is still problematic.)

Also, ECDHE-RSA-AES128-SHA256 is still decrypt-then-verify CBC mode, isn't it? GCM should be listed first.


A lot of sites are on hardware that's older than two years old (AES-NI didn't show up till Westmere), or an OS that's more than two years old (Ubuntu Lucid, for example, ships with OpenSSL 0.9.8).

Upgrading takes time.


I would love it if Atom gets AES-NI as most consumer/smb NAS devices us that CPU and it would mean that we could finally have essentially wire speed encryption for those devices.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: