18 ms·

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

365 points by ge0rg 13y ago

effhaa 13y ago
Why do you have to fix it in the apps? Iirc you just could specify a different order on the server side and enable "honor cipher order", so the servers preference is used? http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhonorcipherorder http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhon... Not sure there, though.
- xnyhps 13y ago
  Do you want to make the gamble that every server has "honor cipher order" on and configured in a saner way?
  - effhaa 13y ago
    Yes, you might have a point, depending on the application - but I guess most apps do have their own set of "backend servers", so modifying the servers or the client should be pretty much the same effort. Modifying the server doesnt need a client side update, though.
- Eiwatah4 13y ago
  Afaik, as long as a weak cipher is enabled on both client and server, a MITM attacker can force it to be used. It involves manipulating the handshake to tell both parties the other one doesn't support any better cipher.
  - xnyhps 13y ago
    Eh, no. Maybe in SSLv2, but the first thing TLS encrypts is a hash of the entire handshake. Modifying the cipher list would change those hashes into something different. 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.
- driverdan 13y ago
  Weak cyphers should be disabled on the server entirely, not just re-ordered.
  - tptacek 13y ago
    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.
    - maaku 13y ago
      Examples please?
      - tptacek 13y ago
        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.
        maaku 13y ago
        Ok, thank you. I misread - I thought you meant that there were clients which weren't capable of handling block cipher suites (e.g. for performance reasons). You made me look into "Lucky 13" though, so at least I learned something!
albert_holm 13y ago
There are some good advice on how to improve the situation in the appendix section.
- ge0rg 13y ago
  I will be adding advices from the discussion here, so feel free to comment! :)
tptacek 13y ago
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 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.
- interstitial 13y ago
  Thanks for your insightful comments and representing the paradox of the internet: Alarmist tones are required to generate interest in a story, but taking the time to explain the cognitively challenging details is instantly off-putting in an article. The average internet users is becoming so stupid, even the simplified versions are TL;DR. I've come to rely on Hacker News comments in ways I used to rely on Slashdot stories. The SNR at Reddit is overwhelming.
- ge0rg 13y ago
  Thank you for the insight. It is good to get some more details on how broken it is. I will add a clarification regarding MD5 to the article. Sorry about my alarmist tone - from time to time I need to get rid of my conspiracy theories.
  - grinning 13y ago
    You should append tptacek's comment to your post.
p4bl0 13y ago
Close to this subject there was a good invited talk entitled "Why does the web still run on RC4?" by Adam Langley at CRYPTO this year. I can't find a video online however someone from the Bristol crypto group wrote a small report of his talk here: http://bristolcrypto.blogspot.fr/2013/08/why-does-web-still-run-on-rc4.html http://bristolcrypto.blogspot.fr/2013/08/why-does-web-still-....
JosephRedfern 13y ago
Would this flaw be "patchable" using Cydia Substrate for Android? Might be good as a quick fix.
meshko 13y ago
I bet this is stupidity, not NSA.
- joelthelion 13y ago
  I find it hard believing that stupidity explains a deliberate change by Google engineers.
  - mpyne 13y ago
    If only there was some possibility of there been a third option instead of just stupidity or maliciousness....
    - logn 13y ago
      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.
      - tptacek 13y ago
        That's not the third option he was thinking of.
- sneak 13y ago
  How about both? An engineer on the payroll of NSA, and then stupidity on the part of whoever signed off on the commit?
  - tptacek 13y ago
gmuslera 13y ago
Hopely Cyanogenmod devs, if not Google itself, will fix it, now that they are aware. In 2010 it may not be seen as a priority, but since last June it is for everyone.
- dbmnt 13y ago
  CyanogenMod merged a "fix" into the repo earlier today: http://review.cyanogenmod.org/#/c/51771/ http://review.cyanogenmod.org/#/c/51771/ ... only to revert it later: http://review.cyanogenmod.org/#/c/51794/ 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-beast.html https://blogs.akamai.com/2012/05/what-you-need-to-know-about...
evmar 13y ago
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 about them but the config turns them off.) (I'm an SSL newbie, please correct any mistakes I've made in the above.) [1] http://wiki.nginx.org/HttpSslModule#ssl_ciphers http://wiki.nginx.org/HttpSslModule#ssl_ciphers
- ge0rg 13y ago
  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#sslhonorcipherorder http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhon... for apache in another post.
  - mnordhoff_ 13y ago
    Nginx has an equivalent preference, ssl_prefer_server_ciphers on. (Scroll down a bit on evmar's link.)
  - deleted 13y ago
    [deleted]
celerity 13y ago
This beautifully illustrates the power of open source. One guy was worried enough about security to start checking the crypto source, and was able to alert the community. I hope this leads to a more secure platform.
- marshray 13y ago
  Not really. Basically of this info was transmitted in the clear and easily visible in packet captures. 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.
- thrillgore 13y ago
  It was a downgrade during the Android life cycle. I don't want to be "that guy" but someone had to have a good reason to roll back to RC4-MD5 if they were using SHA before. But hey, you can open an issue about it.
Finster 13y ago
I'm usually the first to rail against NSA shenanigans but I also believe you shouldn't ascribe to malice what can more easily be explained by stupidity.
- tptacek 13y ago
  And you probably shouldn't ascribe to stupidity what can more easily be explained by "not at all stupid or malicious".
  - redcap 13y ago
    I'm sorry, but I'm only a passing student of cryptography, and I've known that both RC4 and MD5 have been broken for quite some time now. 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.
    - tptacek 13y ago
      Once again, with feeling: the fact that an algorithm is "broken" does not mean that a cryptosystem reliant on that algorithm is necessarily broken. In this particular case, the MD5 breakage is not currently relevant to TLS, and it might be decades before it ever is. And, while nobody particularly liked RC4, it was deployed to mitigate an even worse vulnerability in the MtE CBC construction in TLS. 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.
      - redcap 13y ago
        I get your point about the security of the system as a whole: my point isn't that the algorithms are on the list, just that they're at the top of the list. 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.
eksith 13y ago
"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/ http://xkcd.com/538/
- ge0rg 13y ago
  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-reveal-nsa-campaign-against-encryption.html?_r=0 http://www.nytimes.com/interactive/2013/09/05/us/documents-r...
  - eksith 13y ago
    I could have sworn I read that as "that works with Internet companies". Like I said...
- thrillgore 13y ago
  Like it or not, "OMG NSA" is now part of the lexicon in a post-Snowden world. It's how every piece of technology developed Stateside is going to be perceived from here on out.
genericacct 13y ago
<alarmism>oh by the way the stock android browser up to version 4.2 and maybe beyond LEAKS ANYTHING YOU TYPE IN THE ADDRESS BOX IN CLEARTEXT OVER THE NET. </alarmism>

365 points by ge0rg 13y ago

Why do you have to fix it in the apps? Iirc you just could specify a different order on the server side and enable "honor cipher order", so the servers preference is used? http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhonorcipherorder http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhon... Not sure there, though.

xnyhps 13y ago
Do you want to make the gamble that every server has "honor cipher order" on and configured in a saner way?
- effhaa 13y ago
  Yes, you might have a point, depending on the application - but I guess most apps do have their own set of "backend servers", so modifying the servers or the client should be pretty much the same effort. Modifying the server doesnt need a client side update, though.
Eiwatah4 13y ago
Afaik, as long as a weak cipher is enabled on both client and server, a MITM attacker can force it to be used. It involves manipulating the handshake to tell both parties the other one doesn't support any better cipher.
- xnyhps 13y ago
  Eh, no. Maybe in SSLv2, but the first thing TLS encrypts is a hash of the entire handshake. Modifying the cipher list would change those hashes into something different. 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.
driverdan 13y ago
Weak cyphers should be disabled on the server entirely, not just re-ordered.
- tptacek 13y ago
  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.
  - maaku 13y ago
    Examples please?
    - tptacek 13y ago
      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.
      - maaku 13y ago
        Ok, thank you. I misread - I thought you meant that there were clients which weren't capable of handling block cipher suites (e.g. for performance reasons). You made me look into "Lucky 13" though, so at least I learned something!

albert_holm 13y ago

There are some good advice on how to improve the situation in the appendix section.

ge0rg 13y ago
I will be adding advices from the discussion here, so feel free to comment! :)

tptacek 13y ago

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

interstitial 13y ago
Thanks for your insightful comments and representing the paradox of the internet: Alarmist tones are required to generate interest in a story, but taking the time to explain the cognitively challenging details is instantly off-putting in an article. The average internet users is becoming so stupid, even the simplified versions are TL;DR. I've come to rely on Hacker News comments in ways I used to rely on Slashdot stories. The SNR at Reddit is overwhelming.
ge0rg 13y ago
Thank you for the insight. It is good to get some more details on how broken it is. I will add a clarification regarding MD5 to the article. Sorry about my alarmist tone - from time to time I need to get rid of my conspiracy theories.
- grinning 13y ago
  You should append tptacek's comment to your post.

p4bl0 13y ago

Close to this subject there was a good invited talk entitled "Why does the web still run on RC4?" by Adam Langley at CRYPTO this year. I can't find a video online however someone from the Bristol crypto group wrote a small report of his talk here: http://bristolcrypto.blogspot.fr/2013/08/why-does-web-still-run-on-rc4.html http://bristolcrypto.blogspot.fr/2013/08/why-does-web-still-....

JosephRedfern 13y ago

Would this flaw be "patchable" using Cydia Substrate for Android? Might be good as a quick fix.

meshko 13y ago

I bet this is stupidity, not NSA.

joelthelion 13y ago
I find it hard believing that stupidity explains a deliberate change by Google engineers.
- mpyne 13y ago
  If only there was some possibility of there been a third option instead of just stupidity or maliciousness....
  - logn 13y ago
    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.
    - tptacek 13y ago
      That's not the third option he was thinking of.
sneak 13y ago
How about both? An engineer on the payroll of NSA, and then stupidity on the part of whoever signed off on the commit?
- tptacek 13y ago

gmuslera 13y ago

Hopely Cyanogenmod devs, if not Google itself, will fix it, now that they are aware. In 2010 it may not be seen as a priority, but since last June it is for everyone.

dbmnt 13y ago
CyanogenMod merged a "fix" into the repo earlier today: http://review.cyanogenmod.org/#/c/51771/ http://review.cyanogenmod.org/#/c/51771/ ... only to revert it later: http://review.cyanogenmod.org/#/c/51794/ 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-beast.html https://blogs.akamai.com/2012/05/what-you-need-to-know-about...

evmar 13y ago

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 about them but the config turns them off.) (I'm an SSL newbie, please correct any mistakes I've made in the above.) [1] http://wiki.nginx.org/HttpSslModule#ssl_ciphers http://wiki.nginx.org/HttpSslModule#ssl_ciphers

ge0rg 13y ago
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#sslhonorcipherorder http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhon... for apache in another post.
- mnordhoff_ 13y ago
  Nginx has an equivalent preference, ssl_prefer_server_ciphers on. (Scroll down a bit on evmar's link.)
- deleted 13y ago
  [deleted]

celerity 13y ago

This beautifully illustrates the power of open source. One guy was worried enough about security to start checking the crypto source, and was able to alert the community. I hope this leads to a more secure platform.

marshray 13y ago
Not really. Basically of this info was transmitted in the clear and easily visible in packet captures. 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.
thrillgore 13y ago
It was a downgrade during the Android life cycle. I don't want to be "that guy" but someone had to have a good reason to roll back to RC4-MD5 if they were using SHA before. But hey, you can open an issue about it.

Finster 13y ago

I'm usually the first to rail against NSA shenanigans but I also believe you shouldn't ascribe to malice what can more easily be explained by stupidity.

tptacek 13y ago
And you probably shouldn't ascribe to stupidity what can more easily be explained by "not at all stupid or malicious".
- redcap 13y ago
  I'm sorry, but I'm only a passing student of cryptography, and I've known that both RC4 and MD5 have been broken for quite some time now. 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.
  - tptacek 13y ago
    Once again, with feeling: the fact that an algorithm is "broken" does not mean that a cryptosystem reliant on that algorithm is necessarily broken. In this particular case, the MD5 breakage is not currently relevant to TLS, and it might be decades before it ever is. And, while nobody particularly liked RC4, it was deployed to mitigate an even worse vulnerability in the MtE CBC construction in TLS. 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.
    - redcap 13y ago
      I get your point about the security of the system as a whole: my point isn't that the algorithms are on the list, just that they're at the top of the list. 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.

eksith 13y ago

"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/ http://xkcd.com/538/

ge0rg 13y ago
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-reveal-nsa-campaign-against-encryption.html?_r=0 http://www.nytimes.com/interactive/2013/09/05/us/documents-r...
- eksith 13y ago
  I could have sworn I read that as "that works with Internet companies". Like I said...
thrillgore 13y ago
Like it or not, "OMG NSA" is now part of the lexicon in a post-Snowden world. It's how every piece of technology developed Stateside is going to be perceived from here on out.

genericacct 13y ago

<alarmism>oh by the way the stock android browser up to version 4.2 and maybe beyond LEAKS ANYTHING YOU TYPE IN THE ADDRESS BOX IN CLEARTEXT OVER THE NET. </alarmism>