Java Spec Compatibility Weakened Android's TLS Encryption 82
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.
Georg Lukas didn't blame Oracle (Score:5, Informative)
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.
Even more confused (Score:5, Informative)
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?
Re:How is this Java's fault (Score:5, Informative)
There has always been a solution. This is just the ordering that will be obtained if you do not specify a particular algorithm. If you don't specify the algorithm you get the first implemented in the list.
Not good if you are not sure which algorithms are implemented on your platform as you will have to sort them your self but not dire unless you just ask and hope.
Not Everything is a conspiracy (Score:2, Informative)
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.