Feeds

back to article Android security relies on ZOMBIE CRYPTO, argues infosec pundit

A German researcher is asking why Google is using the “horribly broken” RC4 and MD5 cipher as its first-default for SSL. The change, he notes in this blog post, has gone unnoticed since December 2010, when the Android 2.3 release swapped from a default preference for the AES256-SHA1 cipher (followed by 3DES and AES128), instead …

COMMENTS

This topic is closed for new posts.
Bronze badge
Big Brother

Isn't it obvious?

"A German researcher is asking why Google is using the “horribly broken” RC4 and MD5 cipher as its first-default for SSL"

Because the NSA told them to.

11
2
Anonymous Coward

Re: Isn't it obvious?

But, but, but .. they SAID they would't do evil

/sarcasm

3
0
Silver badge
Thumb Down

So how has this anything to do with Java?

A decisions to follow an outdated spec for no good reason (definitely not for reasons of "compatibility") is just stupidreeks of nudge-nudge-wink-wink. It has nothing to do with Java. It has even less to do with Java as Android is not running a JVM in the first place.

4
1
Silver badge
Black Helicopters

This isn't the excuse you're looking for

Why would Google want to improve compatibility with a different platform yet worsen compatibility with the same platform (Android 2.2 downwards)?

There should be any compatibility problems anyway as that is why CypherSuiteList exists, so it can be iterated by apps and can change between OS releases without having to rewrite the apps themselves.

Nope, it's something else.

4
0
Bronze badge

George Lukas eh?

I assume he looked at the encryption, remembered the PRISM mess and shouted "It's a trap!"

1
0
Silver badge

Quoting Wikipedia "....cipher suites based on RC4 in SSL and TLS were considered secure because of how the cipher was used in these protocols. In 2011 RC4 suite was actually recommended as a work around for the BEAST attack."

Wikipedia goes on to suggest that only in 2013 did RC4 become vulnerable in TLS/SSL.

2
0
Anonymous Coward

rc4 vulnerable?

Are you kidding? For PCI, we have to prevent CBC ciphers from being used, and now you're saying that RC4 are verbotten as well? I guess we'll have to drop back to 3DES.

If I'm wrong, someone please correct me.

0
0
Anonymous Coward

Re: rc4 vulnerable?

I think the idea is to move up to GCM, rather than down to 3DES. The problem is that not everyone can keep up with the pace at the moment. Cipher and protocol support tends to get upgraded with major releases of software, and they don't happen very often - yearly is probably average, rather less frequently if your name starts with Deb and ends with ian. GCM was regarded as rather avant garde this time last year and now it's seen as a must have ASAP ... go figure.

1
0

Re: rc4 vulnerable?

BEAST attacks are targeted at TLS 1.0 and the older SSLversions and back in 2006-ish RC4 was the recommneded method for short term mititgation (though it still has its problems). TLS 1.1 and 1.2 are considered not vulnerabile as they have CBC protections . OpenSSL has settings which could screw you up if you're using it. Most major browsers support TLS 1.1 and 1.2 but moblie browsers don't really yet and most major borwsers don't default to the more secure TLS 1.1/1.2..

I know what you mean about PCI (and its frusturating) you can move on to using TLS 1.1 or if you can 1.2, but most people are still supporting TLS 1.0 for compatiiabilty with borwsers and mobile. I would say you'd enable the better security for clients that will use it, than prioritize mitigating BEAST attacks over RC4 attacks.

0
0
Bronze badge

Re: rc4 vulnerable?

AC is correct - the preferred approach is to use one of the strong GCM suites, such as ECDHE-RSA-AES128-GCM-SHA256. (That's Elliptic-Curve Diffie-Hellman for key exchange, RSA for asymmetric cipher, AES with 128-bit key for symmetric cipher, GCM for operating mode, and SHA-256 for message digest.)

GCM, the Galois/Counter Mode, is an operating mode for a block cipher. Basically, instead of encrypting the plaintext directly with the block symmetric cipher, you encrypt a counter: 0, 1, 2, etc.1 You XOR the result of encrypting each counter block with the corresponding block of the plaintext, giving you the ciphertext that you transmit.2 That's the "counter" part. The "Galois" part comes from also running each ciphertext block through a hash function in a Galois field, which gives you a verifier - a message authentication code - you can use to ensure the message wasn't altered.

The advantage of GCM is that, like other counter modes, it's immune to attacks like BEAST; and as a counter mode it has the special performance advantage of computing its MAC in parallel with encryption, rather than having to do another pass.

The problem with it is that it's only available in TLS 1.2, which is not widely deployed.

1Yes, I'm simplifying a bit. Generally the counter block includes an IV and so forth.

2In other words, you use the block cipher to create a stream cipher.

1
0

There's evidence against this criticism too...

Two issues here:

1) Exactly which encrypted activities on Android are we talking about? The blogger seems to say that _every_ encrypted connection on Android is affected. But that isn't true. Recent versions of Chrome for Android have all negotiated TLS v1.2 connections with AES_256_GCM using DHE_RSA as the key exchange mechanism to websites that support that level of encryption (most don't). So clearly it is not "all SSL connections" on Android that the blogger is talking about. Which ones does he mean exactly?

2) The problem with WEP was not so much the ciphers chosen, but rather the way the encryption was implemented. The WEP algorithm was to blame, not the RC4 cipher itself. Up until earlier this year RC4 was still regarded as pretty secure when implemented properly, and indeed many sysadmins still prefer it over AES or other alternatives with larger key sizes (RC4 is limited to 128 bits) because, as a stream cipher, it is not vulnerable to attacks such as BEAST, which target flaws in AES and other block ciphers. Admittedly the tide is turning and RC4 does now appear to be increasingly vulnerable, but that is only becoming apparent right now. The decision on RC4 in Android was taken years ago.

6
0
Bronze badge

Perhaps a bit too much simplicity...

For the sake of simplicity, the author didn't digress to present a full cryptography primer.

Well, yes. But:

- MD5 is not a "cipher", as the article claims. It's a message digest or cryptographic hash.

- RC4-MD5 is not a cipher. It's a cipher suite.

- As other commentators have already pointed out, RC4 was, until this year, recommended by various knowledgeable sources as a defense against BEAST and related attacks. Feasible attacks against RC4 weren't publicly unveiled until July and August of this year. Perhaps we can forgive Android devs for not knowing about them in 2010.

- Collisions in MD5 are a problem for its use in various contexts, but I'm not aware of a practical attack against SSL/TLS using them. Even Lukas has updated his blog post to note that there are no known attacks against MD5 in TLS (though see a followup comment in the blog, with a correct explanation of why it's safe).

Also, there's another obvious reason for moving RC4-MD5 to the top of the cipher-suite list offered by the client: it's fast. I imagine Google is well aware that most Android users don't understand security and aren't terribly worried about the security of their SSL/TLS connections - and they shouldn't be. Very few of them will ever be at risk from an attacker with the resources to break SSL/TLS security, even if they're using RC4-MD5. What those users do care about is "why does this web page take so long to load?".

Hell, I do understand the issues, and if I had an Android device I wouldn't be worried about this one bit. There are much simpler ways for someone to breach my device's security.

1
0
This topic is closed for new posts.