RFC 7465 has been published, and in a perfect world it would spell doom for the use of RC4 in TLS. But, spoiler alert, the theme of this blog is that there are tons of problems with TLS that your browser either cannot or willfully will not protect you against — major browser vendors love nothing more than sacrificing your security in the name of compatibility with lousy servers — so it’s too soon for optimism.
This guy who sounds like he knows what he’s talking about and who I’ve blindly decided to trust says that PCI-compliant sites must disable CBC-based block ciphers so that they’re not vulnerable to the BEAST attack against TLS 1.0. But CBC is the only mode for block ciphers that provides a reasonable level of security in TLS 1.0, so these servers are limited to negotiating only stream ciphers. And RC4 is the only stream cipher in TLS, so that’s the only thing these poor servers are left with. But nobody is actually vulnerable to BEAST anymore — web browsers have been able to prevent the BEAST attack for several years — so this makes no sense.
So what it a PCI-compliant site? In theory, it’s any site that processes credit card data. For instance, check out the SSL Labs report for www.bankofamerica.com. (In case you’re not yet thoroughly convinced of the truth of the second sentence in this post, take note of the eight bold WEAK warnings and also the bold DANGER. Even major banks don’t care.) Scroll down to the handshake simulations and note how AES is only sometimes used with TLS 1.2, and RC4 is always picked with TLS 1.0. In practice, I’ve checked SSL Labs results for sites that do use AES with TLS 1.0, like www.amazon.com, that do take credit card data, so I’m not sure if guy-who-sounds-like-he-knows-what-he’s-talking-about has the full story, but maybe audits come less frequently than I would expect.
Hopefully browser vendors will push forward and disable RC4 anyway, but that doesn’t seem sufficiently probable, and these poor sites are hardly going to disable RC4 if it means they will fail their next security audit. So what better way to spend a Friday afternoon than write a letter to NIST?
The CVSS score for CVE-2011-3389 (BEAST)  relative to the score for CVE-2013-2566  may discourage efforts to implement RFC 7465 , which prohibits use of RC4-based ciphersuites with TLS. Delays in the implementation of this RFC will harm the overall security of the TLS ecosystem.
The issue is described succinctly at : PCI-compliant servers may not enable CBC-based ciphersuites because CVE-2011-3389 has a base score of 4.3, leaving RC4-based ciphersuites as the only possible options for the server to use with TLS 1.0. CVE-2013-2566, the RC4 vulnerability, has a lower CVSS score. However, CVE-2013-2566 is a much more serious issue in practice. CVE-2011-3389 has been long-since mitigated on the client side in major browsers using the 1/n-1 split technique , allowing CBC-based ciphersuites to be used safely. In contrast, no client-side mitigation for CVE-2013-2566 is available short of disabling RC4. Note also that a more serious attack against RC4 will be published next month .
In summary, a properly-configured TLS server *should not* attempt to mitigate CVE-2011-3389, as this discourages clients from mitigating CVE-2013-2566, and clients already mitigate CVE-2011-3389. Please reconsider the relative ratings for these vulnerabilities to allow PCI-compliant servers to re-enable CBC-based ciphersuites, so that browser vendors can more comfortably disable support for RC4 as required by RFC 7465   .
Thank you for your consideration,
Now, will this actually work? Will I even get a response? I have no clue. Let’s find out!
3 Replies to “RC4 vs. BEAST: which is worse?”
My read is that current practice has been moving pretty solidly away from the ‘allow RC4 to mitigate BEAST’ approach for a couple of years now. None of the commonly used references that I’m aware of recommends this any more. I don’t know about the certification stuff, but you can see stuff like:
which is from when SSL Labs stopped penalizing sites for not allowing/enforcing RC4 on TLS 1.0…back in September 2013.
Yes, that was pretty much exactly the right time to stop penalizing, because it was right after attacks against RC4 became almost practical.
Bureaucrazy at its finest.
Comments are closed.