Fatally flawed RC4 should just die, shout angry securobods Security researchers have banged another nail into the coffin of the ageing RC4 encryption algorithm. The latest password recovery attacks against RC4 in TLS by Christina Garman of Johns Hopkins University, Prof. Kenny Paterson and research student Thyla van der Merwe (both of Royal Holloway, University of London) show that …
RC4 is the last widely known stream cipher. It stood up to the BEAST attack when all block cipher methods were vulnerable. In losing RC4 we put all our cryptographic eggs in one methodological basket.
It's also fast, and therefore easier on servers that are having to encrypt/decrypt lots of traffic.
It's not quite true that all block cipher methods were vulnerable to BEAST. All block ciphers in CBC mode were, but people who were relatively up to date and had GCM available (and preferred in the negotiation) were ok. The problem there is that both the client and the server have to be up to date.
And that is often a problem Vincent, many web servers are set up and left running and nobody gives a damn about security or what cyphers are in use - in fact I would guess a majority of those configuring web sites don't have a clue about crypto suites and which protocols are good or bad.
It is a very complex subject and one that most admins have never bothered to inform themselves about.
"SSL is on," is about all I can get out of most. Start asking about which ciphers are enabled and how they are ordered and you often get a blank stare, as if you are talking gibberish...
As you say it's a very complex subject and IMHO one in which the sys admin should not ordinarily be involved in. We implement and in some cases advise but it's really a policy issue for the security team if you have one.
Still in my experience getting change on something which is perceived as a possible threat compared to something which is actually happening is damn impossible.
Still draft - https://datatracker.ietf.org/doc/draft-irtf-cfrg-chacha20-poly1305/
Not yet supported by Mozilla, in part because of that - https://bugzilla.mozilla.org/show_bug.cgi?id=917571#c19
It's got a very long way to go before being as common as RC4.
It's also fast, and therefore easier on servers that are having to encrypt/decrypt lots of traffic.
And of course, all modern Corporatists would value this way above protecting the customer's traffic.
Try not to be an idiot. All security is about increasing the attacker's cost more than the defender's cost. The cost of handling many encrypted conversations is not insignificant and spending more on servers could divert resources from another, more pressing area.
You're breaking the standard if you still offer RC4 in your client, or use RC4 on your server.
All sites should achieve at least an A grade with https://www.ssllabs.com, an A+ grade is the goal. If you get less than an A you're doing something wrong.
>>You're breaking the standard if you still offer RC4 in your client, or use RC4 on your server.
It's not a standard (yet) ITEF haven't adopted it as a standard as yet, it's still at proposed status.
>>All sites should achieve at least an A grade with https://www.ssllabs.com, an A+ grade is the goal. If you get less than an A you're doing something wrong.
While it's obviously nice to get an A+ there's many reasons that may prevent you getting an A, for example if your sever only supports TLS1.1 (regardless of whether it is vulnerable to POODLE v2) or if your server cert has an SHA-1 signature (despite PRF has no known vulnerability with SHA-1).
Rather than just getting a "tick in the box" it's better to understand what the impacts of perceived issues are, and what A really means, there's plenty of sites with A that are less secure than those with B, because of the nature of their sign-on, and the fact that there are no practical exploits for some of the issues that end up capping you with a B.
In other words, properly implemented servers that get B ratings can be more secure than badly implemented A rated servers.
TLS 1.2 support has been available for a few years now.
Responsible certificate authorities offer free upgrades to SHA-2 signed certificates.
While it's true that a top TLS grading says nothing about the overall security of the server - whether that's http server vulnerabilities, web application or just poorly implemented authentication, it's still a valid indication of the strength of the TLS configuration. Sites should be targeting an A grade irrespective of whether they are otherwise locked down tight. Let's not forget that this is a rapidly changing landscape, SSL 3 (1996), RC4 (1987), CBC ciphers (1976) were all considered secure a year ago - admins should endeavour to stay current with their TLS configurations so that they won't get caught out as ancient protocols, key exchange methods and ciphers are broken.
TLS is not just about security of login credentials but security and privacy of data, which is at least as important as protecting against intrusion/exploitation of the server. One without the other is like securely locking the doors on a house made of glass, no-one can get in but they can see everything that you do.
This post has been deleted by its author
1) CVE-2013-2566 has only just had its CVSS v2 Base Score raised to 4.3 with a revised exploitability Subscore of 8.6: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-2566
This means that PCI compliant organisations cannot use the cipher as approved scan vendors will fail you if you have any vulnerabilities with a CVSS score >= 4.0
2) As others have said, the RFC now has a number, 7465 and it's in the final stages before standardisation: https://tools.ietf.org/html/rfc7465
3) The reason that we have such a problem today with RC4 is because many organisations enabled-and-prioritised cipher suites that use the cipher because of the BEAST attack.
BEAST was a client vulnerability that affected CBC with TLS 1.0 but not RC4, a stream cipher. By making RC4-based cipher suites prioritised at the server end, you could cajole most clients in to using it mitigating BEAST.
However, all major Web browsers have implemented 1/n-1 record splitting that resolves BEAST.
Some security scanners/auditors erroneously continue to flag this as an issue therefore.
4) We’re still also waiting for the details of:
https://www.blackhat.com/asia-15/briefings.html#bar-mitzva-attack-breaking-ssl-with-13-year-old-rc4-weakness
This is likely to be a bigger break than the one mentioned in the article.
Well I can sort of see how it might be possible to con a browser into sending the password 67 million times (though I expect it would take a while) but CipherSaber is probably still safe.
I admit I have a soft spot for the algorithm because it's so amazingly simple. But for heavy duty uses like browsers it does make sense to move on.
Another way to look at a reduction from a 236 to a 224 work factor is that the attacker now only has to do 1/256 the work. Or that the new attack eliminates 99.6% of the effort you'd have to spend on the old attack.
Of course that doesn't mean it's now feasible, just that in the modern environment of cheap cores (whether we're talking GPUs or elastic clouds or bot armies or whatever) a 28 reduction could shift the balance from "not worth it" to "yeah, OK" for some targets. Particularly when there are multiple attackers with different motives, and thus different value calculations.
That said, it's also true that RC4 remains perfectly suitable for some uses, and always will be. Just like polyalphabetic substitution and even Caesar ciphers are still suitable for some applications. Rot13 was never "secure", but it still has uses - possibly even for hiding information from an attacker with limited knowledge and resources. If a non-cryptanalyst gets a couple of minutes to browse through files on an unattended computer, and one of them happens to be scrambled with a Caesar cipher, very likely they'll assume it's a binary or something and move on.
The sort of thing that used to be called "kid-sister cryptography" (before we discovered kid sisters might be interested in cryptanalysis too) will always have a place in the continuum from "I don't care if anyone sees this" to "OMG most secretest secret ever". And RC4 will always place somewhere in that spectrum.
For anybody concerned about potential compatibility impacts of disabling RC4, CloudFlare's article should lay most fears to rest as they've already got rid of it:
https://blog.cloudflare.com/end-of-the-road-for-rc4/
3DES is the legacy alternative that should be used for any Windows XP stragglers for SCHANNEL consumers such as Internet Explorer.
(AES cipher suites didn't get added until Windows Vista and it's available as a hotfix for Windows Server 2003.)
Chrome and Firefox run with their own TLS library so won't use this legacy cipher suite.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
