
Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010 - ge0rg
http://op-co.de/blog/posts/android_ssl_downgrade/
======
tptacek
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.

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

~~~
tptacek
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 without knowing anything
whatsoever about cryptography, so I'm wary of going into more detail.

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

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

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

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

~~~
echohack
As a computer scientist, it's a joy to discover when you're wrong about
things. So I'm enjoying being on the wrong side of the discussion for once,
because I'm learning lots.

Thank you for your replies tptacek, I've learned much from this discussion. If
I could edit my top comment, I would.

~~~
tptacek
:)

------
p4bl0
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-...](http://bristolcrypto.blogspot.fr/2013/08/why-does-web-still-run-on-
rc4.html).

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

------
evmar
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
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...](http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhonorcipherorder)
for apache in another post.

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

------
effhaa
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#sslhon...](http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslhonorcipherorder)

Not sure there, though.

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

------
Finster
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
And you probably shouldn't ascribe to stupidity what can more easily be
explained by "not at all stupid or malicious".

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

~~~
aidenn0
No, the simple explanation is backwards compatibility. There was a client-side
mitigation to the MtE vulnerability, but it broke some tiny fraction of
servers in the wild so it never made it to the stable release of NSS.

------
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/](http://xkcd.com/538/)

~~~
ge0rg
_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...](http://www.nytimes.com/interactive/2013/09/05/us/documents-
reveal-nsa-campaign-against-encryption.html?_r=0)

~~~
eksith
I could have sworn I read that as "that works _with_ Internet companies". Like
I said...

------
meshko
I bet this is stupidity, not NSA.

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

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

~~~
logn
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
That's not the third option he was thinking of.

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

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

------
gmuslera
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
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...](https://blogs.akamai.com/2012/05/what-you-need-to-know-about-
beast.html)

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

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

