Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010
op-co.de
op-co.de
The MD5 hash function is broken, that is true. However, TLS doesn't use MD5 in its raw form; it uses variants of HMAC-MD5, which applies the hash function twice, with two different padding constants with high Hamming distances (put differently, it tries to synthesize two distinct hash functions, MD5-IPAD and MD5-OPAD, and apply them both). Nobody would recommend HMAC-MD5 for use in a new system, but it has not been broken.
RC4 is horribly broken, and is horribly broken in ways that are meaningful to TLS. But the magnitude of RC4's brokenness wasn't appreciated until last year, and up until then, RC4 was a common recommendation for resolving both the SSL3/TLS1.0 BEAST attack and the TLS "Lucky 13" M-t-E attack. That's because RC4 is the only widely-supported stream cipher in TLS. Moreover, RC4 was considered the most computationally efficient way to get TLS deployed, which 5-6 years ago might have been make-or-break for some TLS deployments.
You should worry about RC4 in TLS --- but not that much: the attack is noisy and extremely time consuming. You should not be alarmed by MD5 in TLS, although getting rid of it is one of many good reasons to drive adoption of TLS 1.2.
Sorry about my alarmist tone - from time to time I need to get rid of my conspiracy theories.
With that said, I was under the impression that sites will need to support TLS 1.0 for a good long while, and if that is indeed the case, would they not be better off using RC4? From my understanding, the RC4 attacks seemed less practical than attacks against the implementation of CBC mode in SSL 3.0 / TLS 1.0?
Yes, the installed base is going to keep TLS 1.0 and the legacy SSL block cipher construction in deployment for a long time.
Yes, smart people (among them AGL) have said that the RC4 attack is less practical than the M-t-E timing attack on the SSL CBC ciphers. (By the way, it would be great if we could start putting the blame on M-t-E instead of CBC; the vulnerability isn't in CBC per se. CBC is fine; M-t-E is proven not to be.)
But:
* The timing attack also has remediations (see AGL's famous NSS patch) which don't change the protocol.
* The timing attack is fundamentally unlikely to get more powerful; it's exploiting a very simple, well-understood problem.
* Work on exploiting the RC4 attack is in its infancy, and there are multiple ways the attack could get both fundamentally more powerful and more efficiently implemented.
* There are no software-only fixes to the RC4 problem that don't break the protocol; RC4 is fundamentally and irrevocably broken.
If the security of an algorithm is weakened, then it's important to evaluate the use of the algorithm and make efforts to implement stronger security now. You should feel fortunate that you even get the time to move to something better before all hell breaks loose.
This is the same kind of thinking I hear daily when people say things like, "Just use bcrypt" without thinking about the consequences.
The tendency for programmers to think of security in a nihilistic way continues to boggle my mind. I don't think the article suffers from an alarmist tone. I think it's correct to look at something shitty and call it shit.
Yours is the kind of comment anyone can write without knowing anything whatsoever about cryptography, so I'm wary of going into more detail.
When people try to implement security without actually thinking about what the system is doing, it creates weaknesses in the security, not due to algorithmic weaknesses, but because the organization and the engineering discipline for the future is compromised. Thus, while "just use bcrypt" or "just use HMAC-MD5" might work today, the organization doesn't have the mind to update it when it finally does break.
This is exactly what happened (and is still happening) today after MD5 was broken.
Bcrypt isn't broken or even weakened.
HMAC-MD5 isn't broken.
HMAC-MD5 and bcrypt are unrelated.
Nobody is ignoring the problem of MD5; in fact, suspicion about MD5 animates the very first secure SSL specification we have, from almost 20 years ago. Nobody is saying "just use HMAC-MD5".
They instead should learn that Y is also potentially broken in a given circumstance - and maybe that doesn't apply to my current situation but I need a review process to check that it still doesn't apply to me at a given time in the future.
For someone designing a cryptography application, this understanding should be very deep. I don't think it needs to be as deep for someone who is configuring their Apache server and just needs to know what ciphers to enable and which ones to prefer. In this case it is best to follow an industry best practice based on the type of data being sent over the wire and the compatibility/performance required by the clients/users. Then schedule an annual or quarterly review of those choices to make sure they don't go out of date and keep an eye on security bulletins in case one of them is severely broken.
The author took the opposite lesson from TLS than the one that it actually demonstrates, and the commenter above is harping on that broken lesson.
Thank you for your replies tptacek, I've learned much from this discussion. If I could edit my top comment, I would.
One particular case I remember was use of md5(md5(md5(unix_timestamp()))) to generate "secure" session tokens.
I'll say what everyone's thinking: What are the consequences?
An odd point for the GP to make.
Sorry to say, but "just use bcrypt" is currently the right three word statement that you can use if anybody is asking "I'd like to hash a password, and I don't want to learn all of crypto before I do." Bcrypt is currently among the algorithms that are hard to break if used correctly, deployed widely, has wide support in deployed languages and frameworks and it's fairly simple to use. There's little room for major fuckups here.
There are algorithms that are harder to break (scrypt) or an official standard (PBKDF2), but seriously, bcrypt is currently good enough. Sure, it's always better to read and learn, but sometimes people just have to get things done and I'd rather see them use bcrypt than sha1 or unsalted md5.
tptacek is appears to be too modest to say it himself, so I'll go ahead and point it out: He's not "just a programmer", he's a well-respected computer security and vulnerability researcher.
This isn't to say that you should ever simply take his word for stuff, but rather that you are on one hand preaching to the choir, and on the other that you are probably not considering practical effects on security design that he has to wrangle with all the time.
For instance, it's probably a bad idea to hop immediately from one weakened (not even broken) cryptosystem to The New Hotness just because flaws are uncovered, especially for those doing this without thinking of the consequences. For every theoretical security bug you may fix while doing the conversion, you may very well introduce two much practical security bugs.
Cargo cults are bad wherever they are encountered, even when the cult involves something as seemingly as innocuous as "Cryptosystem $FOO has been weakened, time to jump ship".
Many RC4 deprecation efforts have faced rollback in the face of issues like this; especially on hard to fix embedded devices (think TVs, Cars and phones) with comparatively weak CPUs.
Unfortunately, neither solution is easy: only the very latest chips have AES-NI instructions, and not many clients support Salsa20 yet (OpenSSL does not, for example, and it powers a lot of SSL stuff).
https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-0...
Either way, I don't think Salsa20 is a realistic suggestion for improving TLS performance.
Anyway, TLS is in a tough spot. It's such a widely adopted standard, with so many implementations, that making radical changes is exceptionally difficult. AES-NI leaves the standard mostly alone but requires new(ish) hardware, but on the other hand, implementing newer, faster primitives (like Salsa20) requires essentially turning the massive boat that is TLS.
There are no easy solutions, at least as far as I can see.
The problem is getting the installed base up to TLS 1.2.
But even TLS 1.2 won't help because 1.2 doesn't include ciphers that are screaming-fast without hardware-acceleration. AES-GCM is faster than AES-128-CBC/HMAC-SHA1, but Salsa20-256/HMAC-SHA1 is still twice as fast on my machine. Now if the AES-NI instruction set is available, then AES-GCM handily beats everything by a large margin. (Of course, using hardware acceleration, AES-128-CBC/HMAC-SHA1 is marginally faster than Salsa20-256/HMAC-SHA1, again on my machine.)
The ultimate point is that, without the AES-NI instruction set, new ciphers are just about the only way to get really good TLS performance.
I don't know the answer offhand, but I would suspect that hardware-accelerated AES-GCM would win. It certainly does in single-threaded, "one-session"-esque tests, and the margin of its victory makes me think that hardware-accelerated GCM would be hard to beat by anything.
On my machine, a single thread/core running nothing but AES-GCM can encrypt/decrypt 8192 byte blocks of data at 1.32 GiB/s (this is using OpenSSL's benchmarking feature). Yes, that's gigabytes, not gigabits. It's literally faster than IO for my SSD. (Salsa20, without a MAC, can do the same at about 0.64 GiB/s.)
When I told OpenSSL to use four threads in parallel, it ranked at 5.01 GiB/s, which is absolutely crazy.
That said, beyond a general leaning towards AES-GCM (simply because it is so fast with hardware acceleration), I don't have any hard data on which would be the victor. But I may just construct some benchmarks to test that out, because it's an interesting question.
Note that the suggestion of using Salsa20 is to replace RC4 not only to get better performance, but because RC4 is broken (as you know).
Salsa20 (and ChaCha) can be implemented on constrained devices and reach RC4 like performance. On modern architectures the algorithms word based functionality better utilise the HW than RC4 and can reach better performance.
Yes, AES with HW-support such as AES-NI can provide really good performance too. But then we _only_ have AES (and DES/3DES). Do we want to reduce SSL, TLS to a single symmetric encryption primitive? And no stream ciphers?
Disclosure: I work for Microsoft.
Rather, the increased collision resistance comes from the fact that the 64-byte keyed padding puts the MD5 context in a state unknown to the attacker before any of the attacker's data touches the MD5 state. As long as the HMAC key has at least 128 bits of entropy, all possible values of the 128-bit MD5 internal state are nearly equally likely. This makes it much more difficult for an attacker to produce collisions.
If we want to move away from MD5 and RC4 we first must start deprecating their usage wherever we can. Removing suites in SSL/TLS that uses them is a pretty simple step. Moving _from_ good suites _to_ these suites is the totally wrong way to go.
Admittedly it is quite a bit more convenient to look back in source code history rather than dig up and test old versions of the compiled code directly.
But hey, you can open an issue about it.
For example, nginx by default[1] specifies an OpenSSL cipher list of HIGH:!aNULL:!MD5, which you can examine by running
$ openssl ciphers 'HIGH:!aNULL:!MD5'
You'll see neither RC4 nor MD5 in that list. (You will if you run a plain "openssl ciphers", so you can see openssl knows about them but the config turns them off.)
(I'm an SSL newbie, please correct any mistakes I've made in the above.)
Edit: effhaa mentioned http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhon... for apache in another post.
Not sure there, though.
Unless you have a client which will happily disable a cipher and try again when encountering an error. But if you do that, you don't deserve any security.
I don't remember the timeline, but if you're implementing code for algorithms and you decide to use the defaults "just because", you're being negligent - that is to say being pretty damn stupid.
Cryptosystems exist in strata: environments, algorithms, constructions, protocols, applications. A careful cryptosystem is designed so that a flaw in one stratum doesn't immediately destroy the entire cryptosystem. Not only did TLS largely succeed in that goal, but it succeeded in part due to the availability of RC4.
So: no. No, no, no.
RC4 may have helped TLS to succeed, but it's 2013 - surely there's something that is robust enough to be used instead by now?
Of course the simple explanation could just be for performance reasons.
"The change from the strong OpenSSL cipher list to a hardcoded one starting
with weak ciphers is either a sign of horrible ignorance, security incompetence
or a clever disguise for an NSA-influenced manipulation - you decide!"
It's far more economical, considering the scales of this vacuum, to simply rely on service providers freely handing over data on their customers rather than breaking crypto.
Side note: The "OMG NSA!!" hyperbole is starting to fray at my nerves. Not everything is a conspiracy. It doesn't need to be when willing participants are holding the keys to the castle in the first place.
Relevant: http://xkcd.com/538/
From http://www.nytimes.com/interactive/2013/09/05/us/documents-r...
Code reviews happen every day in the industry, and often times it's amazing how many flaws and defects are found, but often internally and not exposed for the world to see and speculate on. The nature of open source is that this is all out in the open, and that's fine. It's also good that Google is actively paying bounties on discovering/fixing these types of bugs in a variety of major open source projects.
An engineer on the payroll of NSA, and then stupidity on the part of whoever signed off on the commit?
I know where you're coming from (YOU JUST HATE AMERICA) but this just isn't a politically volatile issue.
(It's a little hard these days to know what's a "paranoid fantasy", what's an "interesting cypherpunk plot", and what's "a realistic and/or confirmed NSA threat" - at least for me…)
I'd expect them to go so far as to attempt to stop publication of comparably-performant ciphers that could conceivably take its place. You'll recall the 1974 precedent involving IBM's independent discovery of differential cryptanalysis.
If there's one thing I'm even more vigilant about than distrusting the US government/military, it's not underestimating the lengths to which they will go to achieve their ends.
PS: This has nothing to do with md5.
http://review.cyanogenmod.org/#/c/51771/
... only to revert it later:
http://review.cyanogenmod.org/#/c/51794/
The revert noted "TLS v1.0 + AES is a bad combo, and entirely possible to happen with these priority lists".
In other words, the proposed "quick fix" was dangerous. There's some reading material on BEAST attacks here:
https://blogs.akamai.com/2012/05/what-you-need-to-know-about...