Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

op-co.de

Post reply on HN
Print view View original

41–50 of 91 posts

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#41

Post by tptacek »

ReidZB wrote: post #37
colmmacc wrote: post #29

Earlier quoted context omitted.

There is another technical angle; RC4 is usually quite a lot less CPU intensive than the alternatives available. Not using RC4 can easily mean stuttering video playback, greatly diminished battery life, and even lock ups. Very few users are open to accepting that issues like that are "better" for them. Many RC4 deprecation efforts have faced rollback in the face of issues like this; especially on hard to fix embedded…

There are two solutions: use hardware with the AES-NI instruction set, which makes AES blazing fast, or alternatively use a better stream cipher like Salsa20. On my machine, which has an Intel i5-3570k, Salsa20 is about 25% faster (edit: than RC4) 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 i…

Does any TLS stack support Salsa20? I know Adam Langley has a draft for ChaCha+Poly1305, but that's not Salsa20.

Either way, I don't think Salsa20 is a realistic suggestion for improving TLS performance.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#42

Post by [deleted] »

ge0rg wrote: post #28
evmar wrote: post #24

I asked my local SSL expert, and he mentioned: the list the client sends is just a preference list; the server can choose what it wants. 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 abou…

You are right, the final choice of the algorithm is with the server. I am not sure though if it is possible to give other ciphers a higher priority on the server without completely disabling RC4 (which is still better than no encryption / no connection). Edit: effhaa mentioned http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhon... for apache in another post.

[deleted]

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#43

Post by ReidZB »

tptacek wrote: post #41
ReidZB wrote: post #37

Earlier quoted context omitted.

There are two solutions: use hardware with the AES-NI instruction set, which makes AES blazing fast, or alternatively use a better stream cipher like Salsa20. On my machine, which has an Intel i5-3570k, Salsa20 is about 25% faster (edit: than RC4) 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 i…

Does any TLS stack support Salsa20? I know Adam Langley has a draft for ChaCha+Poly1305, but that's not Salsa20. Either way, I don't think Salsa20 is a realistic suggestion for improving TLS performance.

Yes. GnuTLS does: http://www.gnutls.org/manual/gnutls.html#Encryption-algorith...

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.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#44

Post by hackinthebochs »

tptacek wrote: post #32
echohack wrote: post #31

Earlier quoted context omitted.

Apologies. Perhaps I'm being a master of the obvious here, so I'll restate more simply: 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,…

This is the same comment with fewer words, and while I appreciate the concision, it doesn't make any more sense to me. 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".

What he's saying is these blanket statements "just use X" is what is broken. Sometime ago it was "just use md5" and we're still suffering through the fallout of that long after md5 has been shown to be broken. Now we're pointing everyone in another direction and at some point that will be broken too. His point is that we need to educate people on the reasons why one algorithm is better than another for certain security concerns rather than relying on blanket catch-all declarations.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#45

Post by eksith » 

  "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!"
Survey says: Short-sightedness. Not really ignorance or incompetence (although that may be arguable), but it's certainly not "NSA-influenced manipulation". That's the sort of thing they reserve for countries, not consumers. For consumers, they rely on undisclosed 0-days with the severe ones reserved for high priority targets.

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/

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#46

Post by tptacek »

ReidZB wrote: post #43
tptacek wrote: post #41

Earlier quoted context omitted.

Does any TLS stack support Salsa20? I know Adam Langley has a draft for ChaCha+Poly1305, but that's not Salsa20. Either way, I don't think Salsa20 is a realistic suggestion for improving TLS performance.

Yes. GnuTLS does: http://www.gnutls.org/manual/gnutls.html#Encryption-algorith... 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 ma…

That's true of all new ciphersuite proposals, isn't it? The Salsa20+Poly1305 proposal just replaces AES, CTR, and GHASH with Salsa20 and Poly1305.

The problem is getting the installed base up to TLS 1.2.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#47

Post by tptacek »

hackinthebochs wrote: post #44
tptacek wrote: post #32

Earlier quoted context omitted.

This is the same comment with fewer words, and while I appreciate the concision, it doesn't make any more sense to me. 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".

What he's saying is these blanket statements "just use X" is what is broken. Sometime ago it was "just use md5" and we're still suffering through the fallout of that long after md5 has been shown to be broken. Now we're pointing everyone in another direction and at some point that will be broken too. His point is that we need to educate people on the reasons why one algorithm is better than another for certain securi…

And now I'd like to say for the third time that no, there was no "just use MD5" meme in cryptography or in software development, and if TLS is an illustration of anything, it's of not simply leaning on MD5. Once again: the TLS protocol itself is not vulnerable because of MD5, and it's not vulnerable because its designers and implementors both knew about and accounted for the weaknesses of MD5.

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.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#48

Post by logn »

mpyne wrote: post #38
joelthelion wrote: post #33

Earlier quoted context omitted.

I find it hard believing that stupidity explains a deliberate change by Google engineers.

If only there was some possibility of there been a third option instead of just stupidity or maliciousness....

And I'll just finish that thought since there are real engineers involved who probably had good intentions and skills: (as the article stated) the Google engineers were trying to improve compatibility and also seemed to follow the path of what other platforms (Java) had done in he past.

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.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#49

Post by ReidZB »

tptacek wrote: post #46
ReidZB wrote: post #43

Earlier quoted context omitted.

Yes. GnuTLS does: http://www.gnutls.org/manual/gnutls.html#Encryption-algorith... 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 ma…

That's true of all new ciphersuite proposals, isn't it? The Salsa20+Poly1305 proposal just replaces AES, CTR, and GHASH with Salsa20 and Poly1305. The problem is getting the installed base up to TLS 1.2.

Oh, yes - definitely. I just picked Salsa20 as an example because I already had benchmark data for my machine, and I am familiar with it.

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.

Re: Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

#50

Post by tedunangst »

hackinthebochs wrote: post #44
tptacek wrote: post #32

Earlier quoted context omitted.

This is the same comment with fewer words, and while I appreciate the concision, it doesn't make any more sense to me. 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".

What he's saying is these blanket statements "just use X" is what is broken. Sometime ago it was "just use md5" and we're still suffering through the fallout of that long after md5 has been shown to be broken. Now we're pointing everyone in another direction and at some point that will be broken too. His point is that we need to educate people on the reasons why one algorithm is better than another for certain securi…

Has anyone said "just use MD5" to someone who wasn't about to use CRC32 instead?
Post reply on HN