Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Java Spec Compatibility Weakened Android's TLS Encryption

Unknown Lamer posted 1 year,5 days | from the all-the-better-to-hear-you dept.

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

cancel ×

82 comments

Sorry! There are no comments related to the filter you selected.

Google == NSA (-1)

Anonymous Coward | 1 year,5 days | (#45127219)

Thank god for Apple and the iPhone. I can think of at least half a dozen people who will be dumping their Androids now.

Re:Google == NSA (2)

Galactic Dominator (944134) | 1 year,5 days | (#45127413)

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.

Re:Google == NSA (1)

dos1 (2950945) | 1 year,5 days | (#45127821)

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.

Re:Google == NSA (1)

davetv (897037) | 1 year,5 days | (#45129291)

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.

Re:Google == NSA (1)

dos1 (2950945) | 1 year,1 day | (#45169539)

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.

Some things are not worth being compatible with (4, Insightful)

Qzukk (229616) | 1 year,5 days | (#45127221)

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

Re:Some things are not worth being compatible with (0)

Anonymous Coward | 1 year,5 days | (#45128333)

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

whoa there's a new security protocol out, everything that currently exists is crap, dump it and convert to the new one! real practical.

Re:Some things are not worth being compatible with (1)

Billly Gates (198444) | 1 year,5 days | (#45128465)

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. It worked just fine before you messed with it! Go fix it NOW! ... really end rant.

I still have IE 8 and java 6 on my home system because I am working on a small business that will cater to these customers. HTML 5 is 2020s technology when Windows 7 goes EOL. Point being is once something is in place it will take an act of God to change anything as it is now stable so do not touch it. The pendulumn has swung and is evident by the last XP is going EOL story on slashdot. People stated "You CAN PRY XP OFF MY DEAD HANDS!" being modded to +5 as 90% of all IT departments have a do not mess iwth this policy compared to 1999 where we upgraded every 3 years as part of the job.

It will sadly take new paradigms or another code red mass infection to change this attitude of IT only being a cost.

Re:Some things are not worth being compatible with (0)

Anonymous Coward | 1 year,5 days | (#45129229)

Simple. 2014 will be the Xtime, as windows xp will be obsolete, and there will be no way in hell to get it to work on any existing consumer or business hardware. All the XP era machines that used standard consumer and business parts will be mostly dead (capacitor bursting and all that).

where I work, we have a bunch of systems that use old code, and we have gotten to the point where we are willing to completely upgrade all of our systems, as the old stuff is becoming a liability instead of an asset. Too many businesses forget that while programs may not degrade with use, they suffer a similar depreciation schedule that a truck does, without the advantage of being able to sell it like a truck.

I think this happens because we techs are capable of performing massive feats of Jerry-rigging, and that rigging isn't visible like it is in a car or some other industrial widget. Explaining that there is limit to how much I can rig this and eventually it will have to be replaced is not something they want to hear, but any company that wants to do more then sit at where they were at in 2001 will have to get with the times or else.

Good old Oracle/Java (0)

Anonymous Coward | 1 year,5 days | (#45127229)

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)

Re:Good old Oracle/Java (2, Interesting)

Rosyna (80334) | 1 year,5 days | (#45127377)

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.

Re:Good old Oracle/Java (0)

cheater512 (783349) | 1 year,5 days | (#45127731)

Erm most Android apps are written in Java in their own JVM.
To improve JVM compatibility they had to copy what Oracle's JVM does.

100% to do with Java and 0% to do with websites.

Re:Good old Oracle/Java (2)

ChunderDownunder (709234) | 1 year,5 days | (#45127805)

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.

Re:Good old Oracle/Java (1)

Rosyna (80334) | 1 year,5 days | (#45127815)

Confused. What does SSL handshaking with a remote server relate to what an app does internally to itself in a virtual machine?

Even more confused (4, Informative)

WaywardGeek (1480513) | 1 year,5 days | (#45128045)

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:Even more confused (0, Redundant)

Anonymous Coward | 1 year,5 days | (#45128771)

I am so fucking confused, fuck everything!!!!

It is broken (0)

Anonymous Coward | 1 year,5 days | (#45129249)

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.

Re:Even more confused (0)

Anonymous Coward | 1 year,5 days | (#45129417)

You need to read up a bit more about how SSL/TLS works. There are known issues with RC4 (not the WEP implementation bug), see: https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what

Re:Even more confused (0)

Anonymous Coward | 1 year,5 days | (#45129469)

Wrong.

BULLRUN is most likely a crack of RC4.

Even civilian academia has taken a huge bite out of it now, with a massive distinguisher.

RC4 is quite definitely broken.

Re:Even more confused (1)

devman (1163205) | 1 year,4 days | (#45131987)

Unfortunately, it does appear that RC4 is broken at this point (see other commenters). The upside is that this will hopefully speed the adoption of TLS1.2 and people can start using AES in GCM mode (basically turns AES in to stream cipher with authenticated encryption as well).

Re:Even more confused (1)

WaywardGeek (1480513) | 1 year,4 days | (#45140865)

Cripes... I take a few years and don't read about the latest RC4 attacks, and someone finally figures out an attack [isecpartners.com] that can make use of the super-low long-term biases found in RC4. I guess I'll have to switch to something else. I've been using message authentication MACs in P2P protocols when messages are not encrypted. The combination seems like a good idea for stream ciphers.

Re:Good old Oracle/Java (0)

Anonymous Coward | 1 year,5 days | (#45127743)

Except it is Google's fault. Not Oracle's.
Google sticks to old software. Blame them.

Almost! (5, Insightful)

mythosaz (572040) | 1 year,5 days | (#45127233)

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

Re:Almost! (1)

Anonymous Coward | 1 year,5 days | (#45127279)

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

Re:Almost! (0)

Joining Yet Again (2992179) | 1 year,5 days | (#45127383)

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

Re:Almost! (0)

Anonymous Coward | 1 year,5 days | (#45127445)

Would the holy grail be proof that the NSA was behind certain tolerance faults in Fukushima's backup systems... in the interests of the banking industry?

Re:Almost! (1)

VortexCortex (1117377) | 1 year,5 days | (#45129961)

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!

Re:Almost! (0)

Anonymous Coward | 1 year,5 days | (#45127677)

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

They spy on almost every message sent. Turnabout is fair play.

Re:Almost! (0)

Anonymous Coward | 1 year,5 days | (#45129613)

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

Great, lets keep it that way until we have worked NSA out of relevance.

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

Anonymous Coward | 1 year,5 days | (#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.

Re:How is this Java's fault (0)

Anonymous Coward | 1 year,5 days | (#45127693)

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

Personally, just having to rip out some java.nio.file.Path references today to make it compatible with a 1.6 JVM, I wish that there was a way to entice more people to upgrade Java. 1.6 had it's last public release in April; but, some places tend to only upgrade when it is absolutely required (aka won't work anymore).

Re:How is this Java's fault (2)

Meditato (1613545) | 1 year,5 days | (#45127717)

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 (5, Informative)

matfud (464184) | 1 year,5 days | (#45128275)

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.

Re:How is this Java's fault (0)

Anonymous Coward | 1 year,4 days | (#45130767)

A man-in-the-middle attacker does not have to honour the victim's priority list, and can choose the weakest cipher suite from it. I.e., just re-ordering the ciphers in the priority list won't improve the security against an active attacker. The only secure thing to do is to remove the weak ciphers completely.

The fact that the CA model is inadequately weak is often brought up here, but the encryption itself also needs attention. The lax attitude of much software towards weak or insecure fall-backs is disturbing. I still find software that doesn't even verify certificate chains!

Re:How is this Java's fault (1)

matfud (464184) | 1 year,3 days | (#45147625)

A man in the middle attack generally does not care either way as they have spoofed the client and pretended to be them to the server That means they have clear text. The strength of encryption is not generally an issue in this situation. The trust chain is the issue.

But I do agree that the list is incorrect as it selects known weak algorithms first. Even if it was reordered (java 1.7 and later) it would, as you said, result in fall back mechanism to algorithms with known problems.

Your best bet is to remove known unsafe implementations from the list.

Re:How is this Java's fault (1)

VortexCortex (1117377) | 1 year,5 days | (#45129971)

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.

Re:How is this Java's fault (1)

Billly Gates (198444) | 1 year,5 days | (#45128483)

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:How is this Java's fault (1)

smash (1351) | 1 year,5 days | (#45129947)

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:How is this Java's fault (1)

tlhIngan (30335) | 1 year,4 days | (#45133549)

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 trying to set up Android - getting JDK6 is now a PITA...

Re:How is this Java's fault (1)

sproketboy (608031) | 1 year,5 days | (#45128871)

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

I fully understand your position. (1)

tlambert (566799) | 1 year,5 days | (#45130235)

> 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:How is this Java's fault (1)

samkass (174571) | 1 year,4 days | (#45131775)

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

Wait a minute... (0)

Anonymous Coward | 1 year,5 days | (#45127407)

Georg Lukas... Droids... I think we all know whats going on here....

Law droid (1)

tepples (727027) | 1 year,5 days | (#45127501)

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?

I think this explains (1)

maroberts (15852) | 1 year,5 days | (#45130035)

How the Rebel Alliance were able to get the plans for the Death Star so easily - they hacked into Darth Vaders mobile phone

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

DavidinAla (639952) | 1 year,5 days | (#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.

Re:The blame is Google's, not Oracle's (1)

jazzis (612421) | 1 year,5 days | (#45128437)

mod up insightful.

Re:The blame is Google's, not Oracle's (1)

Parker Lewis (999165) | 1 year,4 days | (#45130727)

Nobody forced Google to use Oracle old Java implementation compatibility

Sometimes it's worth getting rid of legacy poop (0)

Anonymous Coward | 1 year,5 days | (#45127525)

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.

Instead of a blog note how about some info? (4, Insightful)

Virtucon (127420) | 1 year,5 days | (#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:Instead of a blog note how about some info? (1)

Indy1 (99447) | 1 year,5 days | (#45128557)

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.

Re:Instead of a blog note how about some info? (1)

Virtucon (127420) | 1 year,4 days | (#45131371)

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.

Re:Instead of a blog note how about some info? (1)

kthreadd (1558445) | 1 year,4 days | (#45134213)

And both Safari and Internet Explorer has supported TLS 1.2 for a long time.

Re:Instead of a blog note how about some info? (1)

Virtucon (127420) | 1 year,4 days | (#45135535)

I already said that about IE. I can't find any official statement on Safari, mind pointing a link?

Re:Instead of a blog note how about some info? (0)

Anonymous Coward | 1 year,4 days | (#45137655)

And if you do explicitly enable TLS1.2 in FF, be prepared to run into a number of big-name sites that aren't prepared to deal with it.
Really the whole situation is rotten to the core, and now I think we know why.

Georg Lukas didn't blame Oracle (4, Informative)

Diamonddavej (851495) | 1 year,5 days | (#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.

Eric Schmidt chimes in (1, Interesting)

Swampash (1131503) | 1 year,5 days | (#45127913)

"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]

Re:Eric Schmidt chimes in (-1, Offtopic)

Anonymous Coward | 1 year,5 days | (#45127979)

Eric Schmidt is a stupid moron.
I dislike him very much. he creeps me out.
Not because he is gay (that's perfectly fine), but because he is just creepy and spreads bullshit.

Re:Eric Schmidt chimes in (0)

Anonymous Coward | 1 year,5 days | (#45128345)

No more outlandish than some of the things Steve Jobs would say. There are morons in every company.

Didn't Eric Schmidt... (-1)

Anonymous Coward | 1 year,5 days | (#45128009)

Didn't Eric Schmidt tell us Android was more secure than a straight mans buttox??!

Re:Didn't Eric Schmidt... (1)

Chrisq (894406) | 1 year,5 days | (#45130063)

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

NSA? (4, Insightful)

Darinbob (1142669) | 1 year,5 days | (#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.

Re:NSA? (0)

Anonymous Coward | 1 year,5 days | (#45128639)

The NSA doesn't give a rat's ass if your data is secure from the bad guys. It's neither their job nor their concern.

Re:NSA? (2)

Bite The Pillow (3087109) | 1 year,5 days | (#45129079)

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 your cell tower loses the race and a spook tower gets the first packet in, because NSA.
I always wondered how the major polytheists got started, and now it is obvious. One story at a time, confirming prejudice, without a pause to consider the details.

That, and karma whoring. But mostly the other one.

Hopefully that was a real question. People are funny when they think their insight grants the clarity to see connections which never existed, and the echo chamber of a thousand similarly deluded souls is a great comfort.

Re:NSA? (0)

Anonymous Coward | 1 year,5 days | (#45130019)

Because they're the same people who disabled TLS 1.1 and 1.2 in IE by default, so the majority of internet users are stuck with 5 years old vulnerabilities.

Re:NSA? (1)

AmiMoJo (196126) | 1 year,4 days | (#45130689)

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 they can get from it compared to the harm that having others know about it will cause.

Re:NSA? (1)

jbolden (176878) | 1 year,4 days | (#45132523)

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.

Is this why Android ships an ancient BouncyCastle (0)

Anonymous Coward | 1 year,5 days | (#45128647)

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.

Who trusts him? (3, Insightful)

OhANameWhatName (2688401) | 1 year,5 days | (#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.

Re:Who trusts him? (0)

Anonymous Coward | 1 year,4 days | (#45137423)

No, the blame goes to Han Solo. He shot first.

Not Everything is a conspiracy (2, Informative)

Anonymous Coward | 1 year,5 days | (#45128855)

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.

uh.. .duh. (0)

Anonymous Coward | 1 year,5 days | (#45129321)

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.

They copied the behaviour of old software (1)

peppepz (1311345) | 1 year,5 days | (#45129617)

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:They copied the behaviour of old software (2)

smash (1351) | 1 year,5 days | (#45129967)

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

Re:They copied the behaviour of old software (0)

Anonymous Coward | 1 year,4 days | (#45130367)

There's so much that's wrong with your post I don't know where to start.

"Google prefer to roll their own (inferior) virtual machine because they do not like GPL"

Really? and there was me thinking it was precisely so they could win a case brought against them by Oracle which they did.

The reason they went their own way has nothing to do with the GPL (only OpenJDK is GPL'd and at risk of patent suits because Oracle refuse to grant it protection) and everything to do with ensure their project couldn't have terms dictated by Oracle. This is well documented in court filings of the relevant Oracle vs. Google case.

"By the way, so much for âoeAndroid does not use Java and does not care about Java compatibilityâ."

Android doesn't use the JVM, it uses the Java language however. They've also never said they don't care about Java compatibility. You just made that bit up, because you're trolling, or stupid.

Re:They copied the behaviour of old software (1)

peppepz (1311345) | 1 year,3 days | (#45141347)

Really? and there was me thinking it was precisely so they could win a case brought against them by Oracle which they did.

You're not informed about that case, which was precisely about Oracle thinking that Google didn't have permission to make their own implementation of the Java APIs without giving them money.

The reason they went their own way has nothing to do with the GPL (only OpenJDK is GPL'd and at risk of patent suits because Oracle refuse to grant it protection) and everything to do with ensure their project couldn't have terms dictated by Oracle.

A GPL project enjoys patent protection and can have no field of use restrictions by virtue of the GPL itself. As for the fact that Google dislike the GPL, hear it from themselves [android.com] .

Android doesn't use the JVM, it uses the Java language however. They've also never said they don't care about Java compatibility. You just made that bit up, because you're trolling, or stupid.

It's not them who said that. Google have always said clearly that Android development is based on the Java language. When the Oracle vs Google case was going on, it was a lot of people here on Slashdot who were saying that Android makes no use of Java the language, and that Google didn't need to copy the Sun APIs because they didn't care about compatibility with a language that they did not use, and whose ecosystem they did not take any advantage from. Not that I support Oracle's crazy stance that APIs can be copyrighted, it's just that I can't stand knee-jerk reactions to defend a company.

Why? (1)

luis_a_espinal (1810296) | 1 year,4 days | (#45130445)

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.

Implementation issue (1)

multimediavt (965608) | 1 year,4 days | (#45132093)

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.

So are dumbdroid going to continue ... (0)

Anonymous Coward | 1 year,4 days | (#45139893)

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

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?