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

11–20 of 91 posts

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

#11

Post by echohack »

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

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

#12

Post by tptacek »

nxn wrote: post #10
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…

I'm sort of confused, because TLS 1.1/1.2 support across browsers looks to be quite poor at the moment. Especially when given a large number of IE visitors that will likely upgrade to IE11 (first version that will have TLS 1.1/1.2 enabled by default) sometime around the year 2016. With that said, I was under the impression that sites will need to support TLS 1.0 for a good long while, and if that is indeed the case,…

It's not that simple.

Yes, the installed base is going to keep TLS 1.0 and the legacy SSL block cipher construction in deployment for a long time.

Yes, smart people (among them AGL) have said that the RC4 attack is less practical than the M-t-E timing attack on the SSL CBC ciphers. (By the way, it would be great if we could start putting the blame on M-t-E instead of CBC; the vulnerability isn't in CBC per se. CBC is fine; M-t-E is proven not to be.)

But:

* The timing attack also has remediations (see AGL's famous NSS patch) which don't change the protocol.

* The timing attack is fundamentally unlikely to get more powerful; it's exploiting a very simple, well-understood problem.

* Work on exploiting the RC4 attack is in its infancy, and there are multiple ways the attack could get both fundamentally more powerful and more efficiently implemented.

* There are no software-only fixes to the RC4 problem that don't break the protocol; RC4 is fundamentally and irrevocably broken.

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

#13

Post by xnyhps »

effhaa wrote: post #8

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... Not sure there, though.

Do you want to make the gamble that every server has "honor cipher order" on and configured in a saner way?

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

#14

Post by tptacek »

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…

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.

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

#15

Post by [deleted] »

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…

[deleted]

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

#16

Post by StavrosK »

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…

> This is the same kind of thinking I hear daily when people say things like, "Just use bcrypt" without thinking about the consequences

I'll say what everyone's thinking: What are the consequences?

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

#18

Post by effhaa »

xnyhps wrote: post #13
effhaa wrote: post #8

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... Not sure there, though.

Do you want to make the gamble that every server has "honor cipher order" on and configured in a saner way?

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.

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

#19

Post by makomk »

nxn wrote: post #10
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…

I'm sort of confused, because TLS 1.1/1.2 support across browsers looks to be quite poor at the moment. Especially when given a large number of IE visitors that will likely upgrade to IE11 (first version that will have TLS 1.1/1.2 enabled by default) sometime around the year 2016. With that said, I was under the impression that sites will need to support TLS 1.0 for a good long while, and if that is indeed the case,…

Interestingly, Google Chrome for Android is one of the few browsers I've seen that supports TLS 1.2 with AES-GCM

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

#20

Post by Xylakant »

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…

> This is the same kind of thinking I hear daily when people say things like, "Just use bcrypt" without thinking about the consequences.

Sorry to say, but "just use bcrypt" is currently the right three word statement that you can use if anybody is asking "I'd like to hash a password, and I don't want to learn all of crypto before I do." Bcrypt is currently among the algorithms that are hard to break if used correctly, deployed widely, has wide support in deployed languages and frameworks and it's fairly simple to use. There's little room for major fuckups here.

There are algorithms that are harder to break (scrypt) or an official standard (PBKDF2), but seriously, bcrypt is currently good enough. Sure, it's always better to read and learn, but sometimes people just have to get things done and I'd rather see them use bcrypt than sha1 or unsalted md5.

Post reply on HN