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

31–40 of 91 posts

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

#31

Post by echohack »

tptacek wrote: post #14
echohack wrote: post #11

Earlier quoted context omitted.

On the contrary, "It has not been broken" is exactly what I would expect a programmer to say. 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…

I have no idea what this comment is even trying to say. I have no idea what MD5 has to do with bcrypt, and I have no idea what "nihilism" has to do with the fact that HMAC-MD5 isn't broken. We didn't just "discover" that MD5 was weak; Paul Kocher knew it was weak when SSL 3.0 was standardized back in 1996 , which is why the SSL 3.0 handshake PRF uses both SHA-1 and MD5. Yours is the kind of comment anyone can write w…

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, 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.

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

#32

Post by tptacek »

echohack wrote: post #31
tptacek wrote: post #14

Earlier quoted context omitted.

I have no idea what this comment is even trying to say. I have no idea what MD5 has to do with bcrypt, and I have no idea what "nihilism" has to do with the fact that HMAC-MD5 isn't broken. We didn't just "discover" that MD5 was weak; Paul Kocher knew it was weak when SSL 3.0 was standardized back in 1996 , which is why the SSL 3.0 handshake PRF uses both SHA-1 and MD5. Yours is the kind of comment anyone can write w…

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

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

#34

Post by mnordhoff_ »

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.

Nginx has an equivalent preference, ssl_prefer_server_ciphers on. (Scroll down a bit on evmar's link.)

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

#36

Post by mpyne »

echohack wrote: post #11
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…

On the contrary, "It has not been broken" is exactly what I would expect a programmer to say. 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…

> The tendency for programmers to think of security in a nihilistic way continues to boggle my mind.

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

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

#37

Post by ReidZB »

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…

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 it powers a lot of SSL stuff).

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

#38

Post by mpyne »

joelthelion wrote: post #33
meshko wrote: post #17

I bet this is stupidity, not NSA.

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....

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

#39

Post by singlow »

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

I think what he is saying is that many individuals and organizations will not learn the fundamentals behind why X is broken, they only learn "X is broken use Y instead."

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.

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

#40

Post by mpyne »

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…

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.
Post reply on HN