Slashdot Mirror
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.
the only billion dollar company that cares less about your security than Microsoft, perhaps they should spend some of that malware money from IAC (ask.com)
Well, we almost worked the NSA into every article headline today. ...there's always tomorrow.
> 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.
Georg Lukas... Droids... I think we all know whats going on here....
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
But when you're up against the lawyers of Lucasfilm's parent Disney, how easy will it be to convince the judge that these aren't the Droids he's looking for?
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.
It's very common in that customers often ask for some old PoS browser compatible web design. I usually tell them straight up to consider updating their company browser policy or look for someone else to proceed with their project.
Somewhat same could apply here; either make software compatible with modern platforms or get out of business.
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.
Thank god for Openmoko and still living community it has spawned. I can think of OpenPhoenux platforms as proper alternative when dumping Android for some security reasons like that.
"Android is more secure than iPhone."
The proclamation was made during a question-and-answer session at the Gartner Symposium/ITxpo, where it drew laughter from the attending audience.
http://tech2.in.com/news/smartphones/eric-schmidt-calls-android-more-secure-than-iphone/917208
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.
I have disclosed security vulnerabilities to Google before. Some related to flaws even a novice cryptographer shouldn't make. Some they have fixed, some they have called 'theoretical vulnerabilities' and not fixed. I haven't gotten any money or even an atta boy, which didn't bother me until they started paying other people money. The least I could get is a thank you. Now I don't bother. Android's security and crypto are both weak, and ...it sounds like - This is probably by design.
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.
There exists distinguishing attack for it. Read the question and comments in crypto.SE: http://crypto.stackexchange.com/questions/10564/how-much-does-a-successful-linear-distinguishing-attack-break-the-attacked-str.
The distinguishing attack indeed currently needs more than megabyte, but then again many of TLS connections carry more than megabyte.
Rule of thumb is cipher is broken from academic point of view when it is possible to distinguish its output from random.
After this happens nobody should any more attempt to use the cipher in practice.
I own a GTA02 and it was hardly useful as a full time phone. Sometimes it would fail to come out of suspend when called, sometimes lock up and need rebooting and other faults. It's power management wasn't that good either - 24 hours per charge if that. It lives in a drawer now, I bought a Galaxy S3 to replace it.
The GTA04 OpenPhoenix replacement board is a joke. 666 Euros ($AU 1000). It does not have a fully working kernel yet, there are various kernel versions with varying degrees of functionality. Even battery charging is broken. Not many people on the mailing list use it as a day to day phone near as I can tell.
While the idea was good, how did Golden Delicious (who sell the GTA04) think they were going to make this work without a kernel developer?
These phones are so secure that you are lucky if you can make or receive a call on them.
What do you mean "discovered"? Everyone who does Android development has known this for.. ever.
You don't use Java 7's encryption with Android, it just doesn't work.
(By the way, so much for “Android does not use Java and does not care about Java compatibility”.)
How the Rebel Alliance were able to get the plans for the Death Star so easily - they hacked into Darth Vaders mobile phone
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
Didn't Eric Schmidt tell us Android was more secure than a straight mans buttox??!
I'm not sure that the Apple users will understand that analogy
> 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.
I fully understand your position. You're from the universe where Spock has a beard, right?
But after digging the code Georg Lukas concluded that the blame goes to Oracle.
Why is it Oracle's fault? I'm not a fan of Oracle, but I fail to see why blame of this situation goes to it? It would seem that Google, given the plenty of implementation latitude it already has on Android, that it could have side-stepped compatibility to provide stronger cyphers.
So why is this Oracle's fault and why no mention of Google's fault exist in this one-sided article? As Colbert once said "I can't prove it, but I can say it.". That seems to be what governs the writing of this particular submission.
Ok, I read the articles and most of the comments above. This seems more like an implementation issue on Google's part than a licensing or compatibility issue with Java. Compatibility with older TLS implementations may have been the reason for the use of RC4 and MD5, but that certainly falls back to a Google decision, not having anything to do with Oracle. I think everyone is a little overly paranoid given the current security--or lack thereof--climate, but I don't see this as any kind of capitulation to a three-letter government agency. Certainly, not a good decision, but also not a government coerced one. I am a bit surprised that this is just coming up now given the configuration has been in Android source since version 2.3.4! Isn't 4.3 on its way? At least Schmidt now knows why there were chuckles to his Android security statement(s) recently.
... to deny that Android is Java??
Sure ... it is a "clean room" implementation ... which even includes old Java bugs.
Google is nothing but a rapist stealing from everybody.
I'm using my Neo Freerunner as my daily phone. Sure, it had those problems you mentioned, but those are fixable. My GTA02 lasts few days on battery now (which is quite weared off after those 5 years) and works pretty stable. The only thing that annoys me is really poor GPRS speed and graphics performance, which is better than it was at the launch, but is still quite unacceptable. Luckily, those issues aren't really important in light of freedom gains one gets from such device. I can live with them and I wouldn't replace this lovely device with anything less open.