Java Spec Compatibility Weakened Android's TLS Encryption
sfcrazy writes "It has been discovered that Google downgraded the SSL encryption of Android after version 2.3.4 and defaulted to RC4 and MD5 ciphers. It may appear that NSA is at play here as both are broken and can be easily compromised. But after digging the code Georg Lukas concluded that the blame goes to Oracle. 'The cipher order on the vast majority of Android devices was defined by Sun in 2002 and taken over into the Android project in 2010 as an attempt to improve compatibility.'"
The Java spec from 2002 specified RC4 and MD5 as the first two ciphers for TLS; Android, however, used DHE-RSA-AES256-SHA by default. The default cipher list for Java 7 was updated, but Android is stuck using JDK 6 and a default cipher list over a decade old.
Shitty security protocols are one of them, if your obsolete software can't cope with modern encryption, it is crap and should be replaced.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Well, we almost worked the NSA into every article headline today. ...there's always tomorrow.
I don't see what this has to do with Oracle/Java politics.
Google had/has absolutely no idea what the "correct" list of cipher order was/is. Google copied the order from OpenSSL. Google removed dependency on OpenSSL. Google copied from another source, which happened to be Java.
The ultimate choice may have been done for compatibility with websites not supporting TLS 1.2 but it was not done for compatibility with Java.
> The default cipher list for Java 7 was updated, but Android is stuck using JDK 6 and a default cipher list over a decade old.
The Android platform did not upgrade. How is that Oracle's fault? Next we will be blaming vendors for vulnerabilities that were patched years ago.
You know all of the 6 Android users who will dump their platform due to this? Your uber vigilante security circle didn't check this before? It seems your circle has bigger problems than just using potentially compromisable settings.
brandelf -t FreeBSD
Nobody forced Google to use Java. Google made its own decision what to use and how to use it. Quit trying to give most geeks' favorite company a pass when it makes lousy decisions that come back to hurt users.
Qualys published a list in August of this year for Java 6 Update 45 that lists the default Cipher Suites in order of preference. On that list there are 4 that are insecure but there 7 that are weak. What needs to start happening to fix this is
1) App vendors need to become aware of the situation.
2) Disable use of the weak and vulnerable ciphers. This can be done on the web server for example as a start.
Remember it takes two to tango in an SSL/TLS handshake and if one side says No to a weak or vulnerable Cipher then one of the stronger Ciphers (if available) can be used. If you're using weak or vulnerable ciphers at all, fix your app. We also have to push to get rid of any of the older than TLS 1.1 and keep pushing on the Browsers to support TLS 1.2 which oddly enough only MSFT has supported since IE8 and Opera since version 10. http://en.wikipedia.org/wiki/Transport_Layer_Security
Harrison's Postulate - "For every action there is an equal and opposite criticism"
No, Georg Lukas didn't blame Oracle, in his own words...
"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!
Java 1.4 uses RFC 2246, which came out in 1999 and uses weak older ciphers that were approved for export during a time when the US restricted the export of strong encryption. It is about the weakest standard that anyone at Oracle or Google could find.
Well the issue is Android targetted Java 6 at inception, which is no excuse for not updating Android to match whatever security Oracle now supports in Java 7 and the forthcoming Java 8.
RC4 (aka ARC4) is not "broken". Unknown Lamer is confused. WEP is broken because it had a flawed implementation of ARC4. Just hash the key, drop the first 1K bytes of output, and no known program can even differentiate ARC4 output from truly random numbers with less than a megabyte of data. If the NSA can crack ARC4, then they've beaten a huge collective effort of the world's cryptography community.
But... md5? Surely that's just for non-secure CRC, right? Android wouldn't do anything as dumb a signing document MD5 hashes, would they?
Celebrate failure, and then learn from it - Nolan Bushnell
Why does everyone blame NSA here? NSA does not want ciphers that everyone can decrypt more easily. They'd be much happier with ciphers that only the NSA could decrypt but which stumped the Chinese and Russians and mafia and terrorists and foreign hackers, etc.
There's the attitude I see that seems to be getting more popular, which implies that the NSA wishes that no one used encryption at all. But that's patently false. They absolutely want encryption within the government (so that we can't spy on the government), they want encryption in the business sector (secure communications is good business), and the absolutely don't want the US to be painfully backwards with respect to cryptography compared to every other country in the world.
Georg Lukas concluded that the blame goes to Oracle
No matter what, you have to take responsibility. You've destroyed the hopes of leagues of loyal fans.
RC4 was the preferred cipher of choice and recommended by multiple security firms until recently with their guidelines for ssl/tls security. Most recently Qualys in their 1.3 revision called for disabling rc4 (updated in September of this year) it was the recommended cipher over AES-CBC in the 1.2 guide. The reason for this is that many in the security community believed that at the time CRIME and BEAST attacks were more serious and exploitable. That was until really BlackHat 2013 when BEAST was shown to be practical and exploitable meaning RC4 is the riskier cipher to use. So up until a few months ago preferring RC4 was the more "secure" best practice against the known vulnerabilities in the various widely supported ciphers in SSLv3 and TLSv1.0 (which are the most widely used of the protocols). I dont see this as a conspiracy at all, its just a changing of the security climate over the past 5 years against the known attack vectors.
Pretty much. But this is slashdot, where google can do no evil, and Oracle are the bad guys. No matter what.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.