Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Android Communications Encryption Java

Java Spec Compatibility Weakened Android's TLS Encryption 82

Posted by Unknown Lamer from the all-the-better-to-hear-you dept.
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.
This discussion has been archived. No new comments can be posted.

Java Spec Compatibility Weakened Android's TLS Encryption More

Java Spec Compatibility Weakened Android's TLS Encryption

Comments Filter:

  • Some things are not worth being compatible with (Score:5, Insightful)

    by Qzukk ( 229616 ) on Monday October 14, 2013 @07:24PM (#45127221) Journal

    Shitty security protocols are one of them, if your obsolete software can't cope with modern encryption, it is crap and should be replaced.

    • Shitty security protocols are one of them, if your obsolete software can't cope with modern encryption, it is crap and should be replaced.

      Yeah try telling that to a boss who gets a bonus by keeping IE 6 and keeping you putting out fires all day instead of adaquite resources to do anything but putting out fires with viruses from IE 6 and java 5 infections. After all upgrading would take away his bonus and would not raise the share price next quarter. ... end rant.

      Stuff that breaks IE 6/8 is considered broken, and broken is considered working with this same crowd too. If you talk about open standards he says, Tim why does this not work anymore.

  • Almost! (Score:5, Insightful)

    by mythosaz ( 572040 ) on Monday October 14, 2013 @07:25PM (#45127233)

    Well, we almost worked the NSA into every article headline today. ...there's always tomorrow.

    • Re: (Score:1)

      by Anonymous Coward

      Don't sound so bitter. Nice to see some competition to Fukushima articles, even if they cater to the same crowd.

      • Ah yes, that universally hated crowd OL and IRL: "The set of people who disagree with me on anything."

      • Don't sound so bitter. Nice to see some competition to Fukushima articles, even if they cater to the same crowd.

        Fukushima was an outside job!

        The IT Crowd was an inside job!

        The NSA was a Snow-job!

  • How is this Java's fault (Score:5, Insightful)

    by Anonymous Coward on Monday October 14, 2013 @07:46PM (#45127401)

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

    • How is that Oracle's fault? Next we will be blaming vendors for vulnerabilities that were patched years ago.

      Exactly. As much as I love hating on Oracle, the blame lies on the Android Java team for not merging in those updates.

      Speaking of that, has anyone presented a solution? I'm an app developer among other things, and I don't want my apps using old ciphers over important network infrastructure.

      • Re:How is this Java's fault (Score:5, Informative)

        by matfud ( 464184 ) <matfud@yahoo.com> on Monday October 14, 2013 @09:44PM (#45128275) Homepage

        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.

      • Speaking of that, has anyone presented a solution?

        Uh, remove the weak ciphers from the server's supported list of ciphers. Done. Users will negotiate to a better cipher.

    • Because Java 7 is a buggy piece of crap. Java 6 has less bugs patched and works better. I do not want to upgrade and will stay with Java 6 because it works just fine for my needs thank you very much. I have disabled Java in my browsers I may add.

      But if Oracle rushed Java 7 and craeted many bugs and a new rushed verison from a diferent set of developers than java 6. It really shows.

      • Re: (Score:2)

        by smash ( 1351 )
        Err.... Java 6 is unsupported now, which is probably why it has less bugs patched. They're both buggy piles of crap, but lets compare apples with apples here. One is still being updated.

        • Re: (Score:2)

          by tlhIngan ( 30335 )

          Err.... Java 6 is unsupported now, which is probably why it has less bugs patched. They're both buggy piles of crap, but lets compare apples with apples here. One is still being updated.

          And apparently Oracle is so fed up with Android that they've put the JDK6 behind a registraiion-wall, something I found out when trying to set up a machine to build Android. Used to be easy to get, now that Oracle's completely deprecated it, they're making ti hard to get the last version available.

          It's something to note when

    • It's because Oracle is "Evil" and Google is "Good". Dude get your facts straight.

    • > 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?

    • Re: (Score:2)

      by samkass ( 174571 )

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

      It can't possibly be Google's fault; this is Slashdot. It must be Oracle's fault that Google copied badly from Java.

  • The blame is Google's, not Oracle's (Score:4, Insightful)

    by DavidinAla ( 639952 ) on Monday October 14, 2013 @07:59PM (#45127517)
    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.

  • Instead of a blog note how about some info? (Score:5, Insightful)

    by Virtucon ( 127420 ) on Monday October 14, 2013 @08:07PM (#45127593)

    Qualys published a list in August of this year for Java 6 Update 45 that lists the default Cipher Suites in order of preference. [ssllabs.com] 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 [wikipedia.org]

    • Re: (Score:2)

      by Indy1 ( 99447 )

      The current stable version of Chrome supports TLS 1.2 out of the box.

      Firefox 24 has support for TLS 1.2, but you have to explicitly enable it.

      • The current stable version of Chrome supports TLS 1.2 out of the box.

        Chrome is a fun beast..

        The current version for Android has TLS 1.2 Support.
        You'll need at least the following versions for Windows, OSX:
        Windows - 31.0.1625.2
        OSX 10.8 - 31.0.1625.0

        For Linux, you'll need 1625.2 and NSS 3.15.1

        AFAIK Latest stable is 30 for OSX and Windows but I'll check.

        Firefox 24 has support for TLS 1.2, but you have to explicitly enable it.

        I hadn't seen the update on that. I'll have to test it.

  • Georg Lukas didn't blame Oracle (Score:5, Informative)

    by Diamonddavej ( 851495 ) on Monday October 14, 2013 @08:12PM (#45127639)

    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.

  • "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 [in.com]

  • NSA? (Score:5, Insightful)

    by Darinbob ( 1142669 ) on Monday October 14, 2013 @09:07PM (#45128067)

    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.

    • Reading too much into it. The snarky and cynical have to constantly bring everything back to the story that confirms their pessimism.
      Why let it be Oracles fault and blame incompetence when you can say Oracle was forced, and have malice to rail against?
      Every news story suffers from confirmation bias as the unknown details filled in now point to the suspected source.
      Fluoride fingerprints your teeth so the fluoroscope at the airport knows what city you visited, because NSA. Contrails disrupt communication so y

    • Re: (Score:2)

      by AmiMoJo ( 196126 ) *

      The NSA are fools if they think that the Russian and Chinese and French and Israeli intelligence agencies are not at least as good as they are. If the NSA has found a weakness in something it's fairly safe to assume that at least one other agency has, and then maybe shared it with their partners in the same way that the NSA shares stuff with the British.

      When they put weaknesses and backdoors in they are taking a calculated risk. Someone will find it, it's just a question of how long and how much benefit the

      • Re: (Score:2)

        by jbolden ( 176878 )

        The NSA spends a great deal more than the Russians, Chinese, French and Israelis. The NSA hires a huge number of number theorists those other agencies few. Yes they are better. Money matters and the USA spends.

  • Who trusts him? (Score:4, Insightful)

    by OhANameWhatName ( 2688401 ) on Monday October 14, 2013 @10:52PM (#45128685)

    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.

  • Not Everything is a conspiracy (Score:2, Informative)

    by Anonymous Coward

    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

  • Oracle provide a state-of-the-art, GPL-licensed, 3 years old Java implementation that works and is secure. Google prefer to roll their own (inferior) virtual machine because they do not like GPL, and while doing so they copied in 2010 [googlesource.com] the behaviour of a 2006 implementation to be included into a 2011 product — and the fault is Oracle's?

    (By the way, so much for “Android does not use Java and does not care about Java compatibility”.)

    • Re: (Score:3)

      by smash ( 1351 )
      Pretty much. But this is slashdot, where google can do no evil, and Oracle are the bad guys. No matter what.

  • 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 submissi

  • 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 t

Slashdot Top Deals

E = MC ** 2 +- 3db

Close