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

51–60 of 91 posts

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

#51

Post by ge0rg »

eksith wrote: post #45

"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…

The N.S.A.'s Sigint Enabling Project is a $250 million-a-year program that works with Internet companies to weaken privacy by inserting back doors into encryption products.

From http://www.nytimes.com/interactive/2013/09/05/us/documents-r...

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

#52

Post by tptacek »

ReidZB wrote: post #49
tptacek wrote: post #46

Earlier quoted context omitted.

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…

Does AES-GCM with AES-NI and PCLMULQDQ beat Salsa20+Poly1305 with lots of sessions? I know it's got excellent cycles/byte for a single session, but TLS implementations also need agility.

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

#53

Post by devx »

colmmacc wrote: post #29
tptacek wrote: post #4

There's interesting technical content here, but it suffers from its alarmist tone. 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 bo…

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…

Google's Adam Langley has just proposed ChaCha20 with Poly1305 for TLS, and says the performance is pretty good (~5x faster than AES-GCM in software).

https://www.imperialviolet.org/2013/10/07/chacha20.html

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

#54

Post by harshreality »

mpyne wrote: post #40
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…

There is at least an RFC out for a TLS stream cipher using Salsa20, if I'm remembering current events correctly. Of course publication of a spec will precede implementation in hardware and software by some years, I would imagine.

There's one that's expired for salsa20, and one by AGL for chacha20 + poly1305.

https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-0...

https://tools.ietf.org/html/draft-josefsson-salsa20-tls-02

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

#55

Post by [deleted] »

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…

[deleted]

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

#56

Post by maaku »

tptacek wrote: post #30
driverdan wrote: post #25

Earlier quoted context omitted.

Weak cyphers should be disabled on the server entirely, not just re-ordered.

Knee-jerk disabling of RC4 because it's "weak" would almost certainly reduce the security of the Internet, because you can't simply evaluate TLS ciphersuites based on the strength of their core cipher; there are lots of deployed TLS clients that can't do block cipher crypto securely right now.

Examples please?

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

#58

Post by tptacek »

maaku wrote: post #56
tptacek wrote: post #30

Earlier quoted context omitted.

Knee-jerk disabling of RC4 because it's "weak" would almost certainly reduce the security of the Internet, because you can't simply evaluate TLS ciphersuites based on the strength of their core cipher; there are lots of deployed TLS clients that can't do block cipher crypto securely right now.

Examples please?

RC4 was first used as a mitigation for the BEAST blockwise-adaptive attack on CBC-with-chained-IVs from SSL 3.0 and TLS 1.0, and then again as a mitigation for the "Lucky 13" timing-based CBC padding oracle that remains a problem in TLS 1.2 when block ciphersuites are used.

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

#59

Post by tptacek »

sneak wrote: post #57
meshko wrote: post #17

I bet this is stupidity, not NSA.

How about both? An engineer on the payroll of NSA, and then stupidity on the part of whoever signed off on the commit?

How about neither? The designers of the SSL3-era ciphersuites knew that MD5 was shady but had few better alternatives because those ciphersuites predate even the SSL3 standard itself and thus readily available SHA1, so they used constructions that remain secure 20 years later even with broken hash cores. And subsequent designers and implementors have swapped RC4 in and out of TLS as needed to mitigate performance problems that would have ruled out TLS entirely, and then later to mitigate attacks on TLS ciphersuites that are in fact worse (currently) than the RC4 vulnerability.

I know where you're coming from (YOU JUST HATE AMERICA) but this just isn't a politically volatile issue.

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

#60

Post by tptacek »

logn wrote: post #48
mpyne wrote: post #38

Earlier quoted context omitted.

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 internal…

That's not the third option he was thinking of.
Post reply on HN