×

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!

Poor SSL Implementations Leave Many Android Apps Vulnerable

timothy posted about a year and a half ago | from the that's-why-they-buy-guns dept.

Android 141

Trailrunner7 writes "There are thousands of apps in the Google Play mobile market that contain serious mistakes in the way that SSL/TLS is implemented, leaving them vulnerable to man-in-the-middle attacks that could compromise sensitive user data such as banking credentials, credit card numbers and other information. Researchers from a pair of German universities conducted a detailed analysis of thousands of Android apps and found that better than 15 percent of those apps had weak or bad SSL implementations. The researchers conducted a detailed study of 13,500 of the more popular free apps on Google Play, the official Android app store, looking at the SSL/TLS implementations in them and trying to determine how complete and effective those implementations are. What they found is that more than 1,000 of the apps have serious problems with their SSL implementations that make them vulnerable to MITM attacks, a common technique used by attackers to intercept wireless data traffic. In its research, the team was able to intercept sensitive user data from these apps, including credit card numbers, bank account information, PayPal credentials and social network credentials."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

141 comments

Android continues to be security disaster (0, Troll)

PieThrow (2756989) | about a year and a half ago | (#41713995)

Android is this century's most fatal security disaster. No other OS has had so many problems in the current years, and that includes the Windows OS's too. All on OS based on Linux.

Re:Android continues to be security disaster (4, Insightful)

Anonymous Coward | about a year and a half ago | (#41714069)

This is not a platform problem, this is a matter of the choices made by application developers. I can guarantee this same sort of analysis would fail a similar number of apps across the board for Windows, OSX, or *any* platform with a sufficient number of applications making use of SSL sockets. I know the sort of developers that do this and they'll do it *everywhere*, because of some mix of not quite understanding the point of the CA and the hassle they perceive in trying to find a way to do it right (admittedly, the logistics of doing it right in certain scenarios is daunting and necessarily puts work on the enduser if you want to be truly secure).

Re:Android continues to be security disaster (1)

Lord Ender (156273) | about a year and a half ago | (#41716811)

This is not correct. Some platforms are secure by default. Others are not. For .NET languages, as an example, you have to try hard to get SSL wrong. The Android dev kit, however, makes it easy to fuck this up.

Re:Android continues to be security disaster (0, Flamebait)

tqk (413719) | about a year and a half ago | (#41714359)

Come on, mods. Flamebait? He's wrong, I'll give you that, but he's expressing his opinion is all. The Android app market has looked pretty dodgy from where I sit ever since it began. Linux is cool, Android is cool, and shitty implementation is shitty implementation no matter how you cut it.

Re:Android continues to be security disaster (0)

Anonymous Coward | about a year and a half ago | (#41714463)

Go and check how many of Google and MS related stories lately have first post taken by some fresh account with nick of Pie... form, like PieDude or PieMaster. It's the same old troll, so no, it is a flamebait.

Re:Android continues to be security disaster (1)

tqk (413719) | about a year and a half ago | (#41714557)

It's the same old troll, so no, it is a flamebait.

It's trolling, not flamebait, as you just admitted. Maybe I'm just feeling pedantic this morning (this morning?!?).

Re:Android continues to be security disaster (0)

Anonymous Coward | about a year and a half ago | (#41714599)

Android is this century's most fatal security disaster. No other OS has had so many problems in the current years, and that includes the Windows OS's too. All on OS based on Linux.

No, that would be the piece of shit known as Windows and Windows Phone.

A question (5, Interesting)

Chrisq (894406) | about a year and a half ago | (#41714011)

The article says:

Researchers from a pair of German universities conducted a detailed analysis of thousands of Android apps and found that better than 15 percent of those apps had weak or bad SSL implementations.

I would have thought that an SSL implementation, complete with certificate chain validation would be provided by the OS, and that apps would use that. Only apps that had special requirements should have to implement SSL. Does anyone know if android does provide a TLS interface, and if so are the apps ignoring the platform service?

A lot of apps use SSL (5, Insightful)

Kagetsuki (1620613) | about a year and a half ago | (#41714049)

I myself have implemented them for shopping apps (SSL for anything dealing with user details, payment, etc.). When you're communicating with an external service that requires (or where you want to use) encrypted connections and that service only offers SSL (this is probably 90% of the time) you need to use it. Now the catch here is that the standard SSL handlers available to you in Android provide an "ideal" setup, where servers and certs are exactly as they "should" be. The problem is unless you are paying rediculous ammounts for dedicated SSL services and high quality certs your setup will not be the "ideal", and you'll have to make exceptions by overriding code.

As an example, in the shopping system I set up there were two sets of certs, one set was signed [payment gateway] the other wasn't [user control pannel]. I had to jump through a few hoops, and the app would be open for man-in-the-middle if set up right - but luckilly all they'd get would be user login details, address and phone number - billing is all external and requires a separate authorization.

Re:A lot of apps use SSL (4, Insightful)

Anonymous Coward | about a year and a half ago | (#41714063)

If one can't afford a certificate for from a typically trusted CA (and it's not much for one for ordinary e-commerce use cases) then one probably shouldn't be handling PII.

Re:A lot of apps use SSL (3, Interesting)

dbIII (701233) | about a year and a half ago | (#41714163)

Tell that to what seems like 9/10 of the sites on the net, expired certs seem to be more common than current ones.

Re:A lot of apps use SSL (2, Insightful)

Anonymous Coward | about a year and a half ago | (#41714373)

expired certs seem to be more common than current ones.

That's because cert expiry is a money-making scam by the CAs.

There is no reason a cert should expire. It should be revoked if compromised, but there is no reason for it to "expire" other than generating annual subscriptions.

Certificate expiry is a heuristic (2, Interesting)

tepples (727027) | about a year and a half ago | (#41714779)

There is no reason a cert should expire. It should be revoked if compromised

As with most perceived fallacies, certificate expiry and password expiry arise from a heuristic. An older certificate or password is more likely to have been silently compromised than a newer certificate or password.

Re:A lot of apps use SSL (1)

Anonymous Coward | about a year and a half ago | (#41714285)

You are correct on common use cases. But what if you need a cert from an atypical CA (EG government approved CA within your own country - this is an actual issue), or what if you need a special cert like: wildcards, shared-cert, multi-domain, special schemes, certs certified by external bodies or specific organizations.

And f* if I WANT to be handling security, I wish I could just set some flag on the server and on the client to true and it would magically be secure. I don't want to mess with certificates. I don't want to have to figure out why auth works on one client but not another. I don't want to have to think about if the connection is proxied or if it's an intranet app or if the client uses some weird one-off system on an outdated apache setup using proprietary plug-in modules. The truth of it all is I think most developers don't give a s*it about CAs and 46 way super double ultra handshakes. I think most devs hate both Alice and Bob and hope they die.

Re:A lot of apps use SSL (0)

Anonymous Coward | about a year and a half ago | (#41714495)

I don't see how any of that is relevant for an app on Android, especially regarding why you would use a third party SSL implementation over platform native. I don't want to work at all and want to live in a private island but guess what, we live in reality and security is an issue that has been be dealt with in these environments. Get over it if you want to work in e-commerce without being in some security bulletin as yet another data breach.

A lot of apps use shared hosting (2)

tepples (727027) | about a year and a half ago | (#41714839)

I don't see how any of that is relevant for an app on Android, especially regarding why you would use a third party SSL implementation over platform native.

If multiple SSL sites are hosted on port 443 of a single IP address, Android 2's platform native SSL implementation can't see the certificate for any site other than the first. Firefox and Chrome for Windows use their own SSL implementation specifically to work around a similar missing feature in Windows XP's platform native SSL implementation.

The certificate is not the problem; IPv4 is (4, Informative)

tepples (727027) | about a year and a half ago | (#41714813)

The problem does not always lie in the certificate. It also lies in the fact that the SSL clients built into Windows NT 5.1 (XP) Android 2.3 (Gingerbread) does not support Server Name Indication (SNI), which allows multiple certificates on one IP address. This lack of support for SNI was not corrected until Windows NT 6 (Vista) on PCs, Android 3.0 (Honeycomb) on tablets, or Android 4.0 (ICS) on phones and pocket tablets. Without SNI and without DNSSEC, each site using SSL needs its own IP address.

Re:A lot of apps use SSL (1)

Anonymous Coward | about a year and a half ago | (#41714073)

And note that this isn't an Android vulnerability. Those MITM attacks are possible because of poor coding! Developers can use own-signed certificates and that's fine, the problem is that when they override code to make SSL checks more permissive they allow ANY self signed certificates and not only the one they are using!

Re:A lot of apps use SSL (-1)

Anonymous Coward | about a year and a half ago | (#41714155)

I'm sure that's a comfort to anyone who gets p0wn3d by this.
 
SMH. Geeks really don't understand.

Re:A lot of apps use SSL (2, Interesting)

Anonymous Coward | about a year and a half ago | (#41714183)

Geeks really don't understand.

Blame goes where blame is due, or nothing gets better. Geeks understand that, everyone else might as well go back to sacrificing goats to their local deity in hope that he fixes it.

If you don't get it, why don't you go down to your local NASCAR office and scream at them about the football referee union, see if that gets you anywhere.

Re:A lot of apps use SSL (3, Insightful)

dgatwood (11270) | about a year and a half ago | (#41715539)

Yes, it is a common mistake. That's why Apple has told people not to do what you're describing at pretty much every WWDC networking talk for as far back as I can remember, and devoted an entire chapter [apple.com] in their networking documentation to that subject.

I'm not seeing anything like the above in the Android documentation, which may explain why this is a much more common problem on that platform. And pretty much all the sample code I see on places like Stack Overflow and GitHub are wrong, which further compounds the problem. Want this problem to go away? Go to all those Stack Overflow pages and GitHub pages and flag them as inappropriate. Then convince someone to document how to do it the *right* way.

Re:A lot of apps use SSL (0)

Anonymous Coward | about a year and a half ago | (#41715557)

But... but... but... Apple is teh evilzz!!!!111!!!

Re:A lot of apps use SSL (1, Insightful)

Anonymous Coward | about a year and a half ago | (#41714103)

Is it me or does that post make it sound like parent poster shouldn't be allowed to use secure communications, much less code them?

I wish there was a "scary as fuck" mod but I don't know if it should count +1 or -1.

Re:A lot of apps use SSL (1)

Xugumad (39311) | about a year and a half ago | (#41714199)

It scares me, anyway.

At the same time, I'm aware from a practical point of view very few people understand these tools, and that very very few companies using SSL have done so through anyone who understands how to ensure it's done correctly (understanding entropy sources, ensuring keys are created with the correct access permissions where applicable, etc.), so it's not really a new scary thing.

Re:A lot of apps use SSL (1)

Kagetsuki (1620613) | about a year and a half ago | (#41714249)

Well put, and in my own defense at least I knew the setup was not how it should be and I made that clear, and that in the future if the app was to be worked on that is one thing that should be focused on. Particularly when it comes to testing I'd bet the vast majority of developers [to be honest, myself included] really know how to test for all common threat scenarios.

Re:A lot of apps use SSL (1)

cratermoon (765155) | about a year and a half ago | (#41714863)

Let me tell you the story about the guy who wanted to use oauth2 bearer tokens over an unsecured connection.

Re:A lot of apps use SSL (2)

Kagetsuki (1620613) | about a year and a half ago | (#41714231)

Hey I'm totally aware it's "wrong" and I would have loved to have done it properly, but this was a little shop with few users, limited cash (including to pay for implementation of the app) and an irregular setup. I just wanted to be done, the owner didn't care, so I kludged it and went on my way. The thing is a lot of setups end up like this and the fact that so many setups aren't the "ideal" and SSL is in a way complex by design (though setup now on things like nginx is cake!) I think a lot of things just end up being kludged and will remain broken untill something bad happens.

Re:A lot of apps use SSL (1)

tqk (413719) | about a year and a half ago | (#41714509)

I just wanted to be done, the owner didn't care, so I kludged it and went on my way. The thing is a lot of setups end up like this and the fact that so many setups aren't the "ideal" and SSL is in a way complex by design ... I think a lot of things just end up being kludged and will remain broken [until] something bad happens.

That methodology is giving the rest of us a bad name. That sort of execution is why I left Windows. It would be better not to do it if the only way you can get it done is to kludge it. Your employer/client is not the only one whose dick will be hanging out in the wind if you get it wrong. His customers' will be too.

Thanks a lot.

Re:A lot of apps use SSL (1)

cratermoon (765155) | about a year and a half ago | (#41714891)

Translation: I just wanted to take the money and run. Making money, that was the important thing. Yeah, money. Did I mention I needed the money?

Re:A lot of apps use SSL (1)

sithlord2 (261932) | about a year and a half ago | (#41715251)


And I don't see the problem with that if the developer needs the money to feed his family.

Re:A lot of apps use SSL (1)

cratermoon (765155) | about a year and a half ago | (#41715825)

Defrauding unsuspecting third parties and exposing them to identity theft is still a crime, or at least a civil liability, even if you have a family. Participating in that kind of thing is unethical at best.

Re:A lot of apps use SSL (1)

shiftless (410350) | about a year and a half ago | (#41716053)

If you can't create quality products, you don't deserve a family. Leave more space for the rest of us who actually give a fuck about doing the right thing.

Re:A lot of apps use SSL (5, Insightful)

sithlord2 (261932) | about a year and a half ago | (#41714109)

What do you define as rediculous amount of money? I pay 50 USD/year for a signed ssl certificate. My SSL setup scores an "A" on the SSLLab test.

With those prices today, I cannot find one argument in favor of a self-signed certificate. Especially not if you are using it in a commercial product. Get a cheap signed certificate and use the SSL framework on your platform in the way it is intended.

I do hope the example you mentioned occured somewhere in the nineties or so, when ssl certs were indeed still expensive.

Re:A lot of apps use SSL (3, Informative)

Kagetsuki (1620613) | about a year and a half ago | (#41714187)

Cert price all depends on the type of cert. You're talking about a standard SSL cert, which in the case I outlined would have actually been OK but it would have required some extra setup (dynamic subdomains) and the client just didn't want to deal with it. Justa heads up in certain situations (eg: corporate certs + internationalized domains + multiple sub domains + weird proprietary auth crap for odd protocols + a badge that says the cert passes some standards body tests....) the cheapest possible cert will run well over $1,000.

BTW I really recommend StartSSL https://www.startssl.com/ [startssl.com] if you are using standard certs. The prices (free for personal certs/low end schemes, unlimited plans for more robust and corporate certs). Service and support is also pretty good.

Re:A lot of apps use SSL (1)

Anonymous Coward | about a year and a half ago | (#41714323)

Cert price all depends on the type of cert. You're talking about a standard SSL cert, which in the case I outlined would have actually been OK but it would have required some extra setup (dynamic subdomains) and the client just didn't want to deal with it. Justa heads up in certain situations (eg: corporate certs + internationalized domains + multiple sub domains + weird proprietary auth crap for odd protocols + a badge that says the cert passes some standards body tests....) the cheapest possible cert will run well over $1,000.

BTW I really recommend StartSSL https://www.startssl.com/ [startssl.com] if you are using standard certs. The prices (free for personal certs/low end schemes, unlimited plans for more robust and corporate certs). Service and support is also pretty good.

$1000?

That's what? Somewhere between 5 and 10 hours of developer time in the US and Europe - counting all overhead costs? And 10 hours is a CHEAP and presumably not very good developer, FWIW....

What the fuck is it with companies not willing to spend a few thousand dollars on buying an industry-standard solution that works, but are willing to throw hundreds of man-hours that cost a helluva lot more money at creating their own crappy solution?

Micro-ISVs (1)

tepples (727027) | about a year and a half ago | (#41714875)

What the fuck is it with companies not willing to spend a few thousand dollars on buying an industry-standard solution that works

Might some of these companies be micro-ISVs, built with sweat equity and run out of a residence until they grow large enough to become able to afford a dedicated office, employees, and all the other overheads of a "proper company"?

Re:Micro-ISVs (1)

cratermoon (765155) | about a year and a half ago | (#41714971)

They might be, but then who in their right mind would trust that kind of party with their money and PII? In choosing how to spend their limited cash, they forgo proper security precautions, and they want users to trust them not to misuse or misplace sensitive information?

Re:Micro-ISVs (1)

tepples (727027) | about a year and a half ago | (#41715267)

Without customers who provide money, how else is a micro-ISV supposed to grow into a proper established business? I need the answer for my own business plan.

Re:Micro-ISVs (1)

sithlord2 (261932) | about a year and a half ago | (#41715443)

By making sure you already have enough money to start your own business. Create a business-plan, and take all those costs into account already. Make sure you have enough cash for your initial investments + cover your costs for the first year at least. Let an accountant check that business-plan too, to make sure it's actually feasable.

Most ISV's don't do this...

Most ISV's fail because they don't do this...!!

Re:Micro-ISVs (2)

cratermoon (765155) | about a year and a half ago | (#41715797)

Well said. If the company doesn't start out with enough money to purchase the things necessary, it's not doing it right. To attempt a real-world analogy, would you put your money in a bank that delayed purchasing a vault until it had enough of the customer's money to afford one?

Re:Micro-ISVs (2)

shiftless (410350) | about a year and a half ago | (#41716083)

No, but I'd forgive them if got the vault and door locks but couldn't yet afford computer systems or free jars of candy.

A signed SSL certificate guarantees absolutely nothing. What makes you think the U.S. government doesn't have access to or backdoors into every single one of those signing "authorities"?

Re:A lot of apps use SSL (3, Insightful)

DarkOx (621550) | about a year and a half ago | (#41714233)

I am not sure I agree. There is nothing stronger than self signed certificates, with the public certificate distributed out of band.

For b2b sites, corporate client vpns, personal remote access and such this is ideal, it does not delegate trust to some 3rd party that might screw up and cause things to have be changed, or risk compromise. If A wants an encrypted channel with B, if A and B can swap usb keys with each other containing their self signed certs; and they then go back and put those certs in their trust stores there is no way anyone can impersonate B to A or A to B without A or B being responsible for leaking a private key.

Obviously this only works for entities with long lived relationships, and enough value in what is being secured to make the effort worth while. Still its actually a much more secure route than a third party CA for any situation where its reasonable.

Re:A lot of apps use SSL (0)

Anonymous Coward | about a year and a half ago | (#41714365)

Indeed.

And for really good security, you don't even want to use public-key crypto at all.

Just distribute (physically) a chunk of randomly-generated (with a hardware RNG of course) AES keys for data transfer and OTP keys for command transfer :)

Use a sound card as a cheap hardware RNG (1)

tepples (727027) | about a year and a half ago | (#41714897)

Just distribute (physically) a chunk of randomly-generated (with a hardware RNG of course) AES keys

Does hashing the output of an open microphone down to 1 bit per sample count as a hardware random number generator? If so, that might just work for long-term business relationships.

Re:A lot of apps use SSL (1)

cratermoon (765155) | about a year and a half ago | (#41714947)

it does not delegate trust to some 3rd party that might screw up and cause things to have be changed, or risk compromise

Instead, the company that issues the self-signed certificate is to be trusted not to screw up? "Just take our certificate, it's fine, trust us".

If Alice and Bob trust each other, this is OK, but what if Bob is bumbling idiot? What about when Alice and Bob, who trust each other, tell Mallory to trust them to trust each other, and Carol mistakenly trusts Mallory?

Re:A lot of apps use SSL (1)

Pieroxy (222434) | about a year and a half ago | (#41715727)

it does not delegate trust to some 3rd party that might screw up and cause things to have be changed, or risk compromise

Instead, the company that issues the self-signed certificate is to be trusted not to screw up? "Just take our certificate, it's fine, trust us".

If Alice and Bob trust each other, this is OK, but what if Bob is bumbling idiot? What about when Alice and Bob, who trust each other, tell Mallory to trust them to trust each other, and Carol mistakenly trusts Mallory?

I don't know about that, but can you tell me if Bob makes out with Carol in the end?

Re:A lot of apps use SSL (1)

shiftless (410350) | about a year and a half ago | (#41716119)

Fortunately Carol already heard through the grapevine that Mallory is a sleazy whore, and refused to accept her certificate.

Wait, I think we were discussing the merits of self-signed certificates.

What the fuck difference does it make if my certificate is self signed or signed by an "authority"? What makes you think an "authority's" signature can't be faked, or backdoored?

Re:A lot of apps use SSL (1)

multi io (640409) | about a year and a half ago | (#41714523)

What do you define as rediculous amount of money? I pay 50 USD/year for a signed ssl certificate.

...and the great thing is: Someone else probably wouldn't pay much more for a signed SSL certificate that says it's yours. :-P

Re:A lot of apps use SSL (1)

sithlord2 (261932) | about a year and a half ago | (#41715177)


Really? I had to verify by e-mail, sms, and phone for my cheap cert. If you can get a valid signed certificate for my domain at that price without my approval, please contact me. I'm eager to test this. But somehow I doubt that any cheap ssl registrar will issue a signed certificate without at least an email verification of the domain-holder himself. But feel free to prove me wrong.

Nevertheless a signed certificate protects you against 95% of all MTM attacks.

In the 1990s, certs were expensive and IPs cheap (1)

tepples (727027) | about a year and a half ago | (#41714911)

I pay 50 USD/year for a signed ssl certificate.

How much on top of this do you pay for the dedicated IPv4 address to host the site on which you use the certificate? Or is your Android application exclusive to Android 3 and 4, whose native SSL stack supports Server Name Indication, as opposed to Android 2.x, whose native SSL stack does not?

I do hope the example you mentioned occured somewhere in the nineties or so, when ssl certs were indeed still expensive.

In the 1990s, SSL certificates were expensive and IPv4 addresses cheap. In the 2010s, it's the other way around.

Re:In the 1990s, certs were expensive and IPs chea (1)

sithlord2 (261932) | about a year and a half ago | (#41715221)

I run it on my own VPS, which has a dedicated fixed IP address. I'm not saying my set-up is perfect. But a signed certificate + validation of the entire CA chain already solves a lot of issues.
And I don't SNI because I only have one hostname.

Look, we can discuss this as much as you want, but it doesn't change the fact that self-signed certs are simply "not-done" in a production-environment. As soon as I encounter an unsigned or expired certificate in a product, I just don't trust that product anymore. And I'm sure I'm not the only one...

Re:In the 1990s, certs were expensive and IPs chea (1)

sithlord2 (261932) | about a year and a half ago | (#41715235)


Also, you can buy wildcard certificates for your domain if you use multiple subdomains. Still safer than self-signed certs

Re:A lot of apps use SSL (1)

DarkOx (621550) | about a year and a half ago | (#41714219)

To me it still sounds like you are doing it wrong. I assume the control panel is something that only a limited number of people need? Why can't those folks just add the self signed certificate to the trust store?

Re:A lot of apps use SSL (1)

Kagetsuki (1620613) | about a year and a half ago | (#41714299)

It was a control panel for customer managment and the root of the problem was the server setup which I wasn't responsible for. Their in-house dev was an idiot who wasted his time writing an overly complex system and the client was a disagreeable cheepskate with a stupid shop that sold crap. I only took the job as a favor, it ate more time then I could bill hours, and I made it clear it was broken and they should do something about it.

Re:A lot of apps use SSL (0)

Anonymous Coward | about a year and a half ago | (#41714227)

I think you missed the point. It's not a question of *using* SSL, it's a question of writing your own implementation of the SSL protocol and underlying cryptographic algorithms. These apps should be using OpenSSL or a library provided by the OS vendor for communicating over SSL rather than attempting to write their own SSL code.

Re:A lot of apps use SSL (1)

WaffleMonster (969671) | about a year and a half ago | (#41715457)

The problem is unless you are paying rediculous ammounts for dedicated SSL services and high quality certs your setup will not be the "ideal", and you'll have to make exceptions by overriding code.

Oh bullshit you are just trying to justify your own laziness.

If you don't want to pay for an SSL cert there is nothing stopping you from using a self signed cert and embedding the public key in your application..also see RFC 2817 for virtual hosts.

I will say overall it does sound like more of a case of giving developers copious amounts of rope to hang themselves in much the same way PHP encouraged certain behaviors leading to rampant SQL injection vulnerabilities.

I know technically it may not be the platforms fault but the platform rises or falls on the success of its users.

My guess what is really needed are some much higher level API calls with easy configuration and cert chain validation schemes for common usage scenarios.

Besides all of this talk about small time APP developers with little security clue making a common mistake and no talk about virtually all mobile OS developers who should be extremely clueful doing the exact same shit with WPA2-Enterprise is quite amusing.

  No cert validation, no name validation just some hokey leap of faith if even that. Heck the ultra secure windows phone does not even bother to check the cert at all. What a joke.

Re:A question (0)

Anonymous Coward | about a year and a half ago | (#41714055)

accepted any certificate; allowing all hostnames; trusting a huge number of certificate authorities by default; and apps using mixed-mode or no SSL

So the short answer is, they are using a sound SSL implementation, but using options that are unsafe. This isn't some indictment of Android versus another platform, it's probably true of MS, OSX, IOS, or really any set of arbitrary applications that run SSL sockets behind the scenes.

Probably the top offender is not bothering to check the server certificate. Particularly apps acquired from the market but intended to run against private servers may be strongly tempted to skip server validation because those private servers frequently use a CA the copy from Android store has no way of knowing The app might take measures like remembering the certificate or acquiring CA certificate on first connect (analagous to the way ssh keys work, but without the nagging to give user a hint of the risk) but the first connect would be susceptible to MITM. In browser world, this is exceedingly common too (just think how often you https to some site and it spews fourth a giant certificate warning), it's just more blatant when it occurs.

I have now read the article and it is apps misuse (4, Informative)

Chrisq (894406) | about a year and a half ago | (#41714083)

I have now read the article and it is apps misuse the APIS. They search for apps that either don't use the TLS APIs but have ssl addresses encoded, or which use a non-default trust manager. When you establish an SSL connection via the normal Java APIs the default trust manager does check the validity of the certificates (i.e. that tey are signed by a trusted CA) and that the URL requested matches the hostname in the certificate's subject DN. There can be valid reasons for overriding this, including using your own specific certificate rather than any signed by a CA, or for development to allow self-signed certificates - though this should be put in production.

They found that a lot of apps had overridden the rust manager in a dangerous way, allowing self-signed certificates in production or allowing any certificate even if id didn't match the host.

Though this is a problem it is not an "android issue". You can write apps that use self-signed certificates, bypass host checking etc. on Windows and any platform that allows you to customise certificate trust checking.

Re:I have now read the article and it is apps misu (1)

cratermoon (765155) | about a year and a half ago | (#41714749)

Presumably you can write them for iOS, and I have no doubt that there are plenty of apps on the AppStore that are playing fast and loose with SSL trust managers.

True fact: I have written Java code to allow for self-signed or any old cert over SSL, or even none. It's not hard to find plenty of sample code [stackoverflow.com]. In the course of my employment the code was used for testing only and either not part of a production build or disabled by default in production, but I cannot say what other developers or teams may have done in with my code in their systems.

Why the authors focused on Android and why they felt the need to blame the OS rather than alerting people to cruddy apps, one can only speculate.

Re:I have now read the article and it is apps misu (1)

sithlord2 (261932) | about a year and a half ago | (#41715547)


Simple: The Apple Store rejects applications that disable proper CA checking. It can only be disabled by private iOS API's if I'm not mistaken. Apps that use private API's are automatically rejected.

Re:I have now read the article and it is apps misu (1)

cratermoon (765155) | about a year and a half ago | (#41715779)

Do they actually check or are you saying they could or should?

Re:A question (1)

cfriedt (1189527) | about a year and a half ago | (#41714101)

The OpenSSL libraries in Android are in the /system partition, and hence, can be patched via OTA update. So yes, they are provided by the OS. And unless the API has changed for OpenSSL (likely not), all Android apps require no modification to be considered secure after said OTA update. Rather than attempting to discourage Android app developers, the linked article really should just be putting pressure on Google, OHA members, and carriers to release OTA updates that include a patch to OpenSSL.

Re:A question (0)

Anonymous Coward | about a year and a half ago | (#41714137)

The honest fact is, the OpenSSL API is shit for n00b developers. There ought to be one function: "encryptedConnectionTo(ip,port[,minimum_security=HIGH,trustedCAs=INSTALLED_CA_LIST])" that returns an encrypted socket that has done everything right or fails with a useful error message. Instead, developers have to learn the arcane SSL song and dance, and if you get the steps wrong, the result sometimes "works" but is actually insecure.

Re:A question (1)

PPH (736903) | about a year and a half ago | (#41714899)

Or someone needs to write a wrapper around the existing SSL API. Put it (and other simplification stuff) in libn00b.

Re:A question (1)

Anonymous Coward | about a year and a half ago | (#41714497)

You should read the following paper. It covers exactly your question and is from the same ACM CCS conference that just ended in Raleigh, NC. Personally, having listened to both talks, this was in my opinion more alarming:

http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html

Exactly, SSL should already be provided (0)

Anonymous Coward | about a year and a half ago | (#41715759)

SSL is a lower level service that should be provided by the OS or Android development framework, or at least by a third-party library. App developers should only need to worry about the actual application logic and not things like SSL.

Re:A question (1)

ajo_arctus (1215290) | about a year and a half ago | (#41716589)

While I'm no expert on Android, I am a developer and I have worked on a pretty major Android app. We found that Android 2.2 and earlier had some bugs in the version of HTTPClient that Android uses, and this bug caused certs from one particular root authority (Verisign, IIRC) to fail. It was a major problem. It was a while ago now, but I think the work-around we went for was to effectively enable untrusted CAs on 2.2 clients. I can happily believe that the apps being talked about here, those with weak SSL, were all modified in this way to work around the Android bug -- the authors probably just made the 'weak-ssl-is-better-than-no-ssl' trade-off and shipped their apps. What else are you realistically going to do?

As it becomes less important to target Android pre-2.3, this particular bug will hopefully become a thing of the past. According to Google, 2.2 is now on 13% of devices, so we're almost at that point. 13% is still a lot though...

User Confidence (0)

BoRegardless (721219) | about a year and a half ago | (#41714079)

Do Android users have confidence in their security? Do they even think about it?

Re:User Confidence (1, Insightful)

amiga3D (567632) | about a year and a half ago | (#41714251)

I would never consider using an Android phone for any banking access. Never.

Re:User Confidence (0, Insightful)

Anonymous Coward | about a year and a half ago | (#41714295)

I would never consider using an Android phone for any access. Never.

FTFY

Re:User Confidence (1)

cratermoon (765155) | about a year and a half ago | (#41714781)

I would not use $RANDOM_SHOPPING_BANKING_APP, but I would visit a bank website using chrome, firefox, or the built-in android browsers. Those three programs, while undoubtedly not flawless, at least have enough respectability and history for me to trust them as well as anything on the internet. Admittedly, that's not much trust, but it's something.

Re:User Confidence (1)

tepples (727027) | about a year and a half ago | (#41714919)

Do you consider paying for paid applications through Google Play Store or Amazon Appstore to constitute "banking access"?

cue the snarky applehead comments (0)

Anonymous Coward | about a year and a half ago | (#41714097)

3
2
1
and....
go

Re:cue the snarky applehead comments (1)

laffer1 (701823) | about a year and a half ago | (#41714151)

Actually, we do we assume this only affects android. Since the developers are ignoring self signed certs as OK, this could happen on any platform. I'd put money on it happening in Apple's app store too.

Re:cue the snarky applehead comments (2)

amiga3D (567632) | about a year and a half ago | (#41714269)

I wouldn't doubt it. I use an acer aspire one running Peppermint Linux off a thumb drive to access my bank. It sits in a drawer until I need it then I pull it out, do my banking and shut it off and back to the drawer. It does nothing else. I got it for $25 dollars and it works great for this function. My Mac Mini workstation and even my Linux laptop are never used for banking as I do too many other things on them and figure it's best to leave that job to a dedicated and secure device. It's not paranoia if they really are out to get you.

Re:cue the snarky applehead comments (-1)

Anonymous Coward | about a year and a half ago | (#41714349)

well i hope you install all the updates everytime you boot up that linux lappysince linux is plagued with constant security holes and needs to be patched almost daily. how often does an os x security issue come up? once every 6 months or something and it makes big headlines. go to any vulnerability tracker and look at the endless stream of linux fuckups, there are so many it's hard to even keep track of them all. i wouldn't trust linux for anything facing the internet accept serving static webpages or an ftp server but even then you have to check daily for new security failings. what a fuckin' nightmare. linux desktop is a bad memory best left in the 00s where it belongs.

Re:cue the snarky applehead comments (1)

laffer1 (701823) | about a year and a half ago | (#41714675)

This is a stupid statement. Every OS has security issues regularly. Apple just sits on them for a long time before a patch comes out. Plus, when looking at updates for linux distros, one has to note it includes EVERY app on the system too. If firefox has a hole in it, the distro pushes a patch, etc.

If you were to look at Mac OS and include all the updates for third party software you install, it's roughly the same as Linux or Windows.

If you're going to be that paranoid about it (1)

caveat (26803) | about a year and a half ago | (#41714817)

I'm not judging, mind you...matter of fact I think it's a nifty idea, I'm just not that nervous myself, BUT, if you're going to go through the trouble of having a dedicated device for security reasons, well, I have an AspireOne myself that's been relegated to toy status since traded in my elderly G4 desktop for a shiny new MBP and it runs OpenBSD well enough for your needs. WiFi isn't working but you probably wouldn't want to use that anyway.

And yes I realize there's virtually no difference in security between the two and you can't put STOP on a netbook but as I said, if you're going to have a dedicated device, only 2 security holes in the default install in a heck of a long time!

Re:cue the snarky applehead comments (0)

Anonymous Coward | about a year and a half ago | (#41714477)

except the apple app store actually has quality controls and rejects apps from retards.

Re:cue the snarky applehead comments (0)

Anonymous Coward | about a year and a half ago | (#41714589)

Wouldn't that be redundant since all of the iOS apps are written by retards?

Re:cue the snarky applehead comments (0)

Anonymous Coward | about a year and a half ago | (#41714759)

Let's see, do you want to write apps for a company that welcomes pirates to steal your software since it makes their phones TCO lower and more attractive to the bottom feeders it targets for sales or write software for a company that defends the intellectual property of creators and markets to a more upscale audience? Think of it as an IQ test.

Re:cue the snarky applehead comments (0)

Anonymous Coward | about a year and a half ago | (#41715807)

Considering the stupidity of your logic I would say you're one of those retards - only you're a --retard because you probably couldn't write an app of any worth.

Re:cue the snarky applehead comments (1)

shiftless (410350) | about a year and a half ago | (#41716177)

... intellectual property ...

Think of it as an IQ test.

And you failed

you faiL i7? (-1)

Anonymous Coward | about a year and a half ago | (#41714221)

Of itS 3ore

team was able to intercept sensitive user data (0)

Anonymous Coward | about a year and a half ago | (#41714271)

If your feeding sensitive data to an android app, the ssl implementation is the least of your wories.

android crapps suck, news at 11 (0)

Anonymous Coward | about a year and a half ago | (#41714309)

tell us something we don't already know

Re:android crapps suck, news at 11 (0)

Anonymous Coward | about a year and a half ago | (#41716183)

android crapps suck, news at 11

tell us something we don't already know

...says the Crapple shill/fanboy

Reimplementing SSL, or misusing OS-supplied tools? (0)

Anonymous Coward | about a year and a half ago | (#41714339)

Huge difference there.

One is barking-at-the-moon batshit fucking crazy, the other is just run-of-the-mill poor implementation.

Yes - if you write your own SSL code and you don't do it for a full-time living YOU ARE BARKING-AT-THE-MOON BATSHIT FUCKING CRAZY. And if you're going to ARGUE that you're not, your also ignorant and STUPID.

It's misusing OS-supplied tools (1)

tepples (727027) | about a year and a half ago | (#41714951)

The article says the latter: poor options provided to Android's native SSL library or to a third-party SSL library included in the application. Quoting Jon Oberheide of Duo Security: "For example, many developers will have an option to disable SSL cert validation when the app is in debug mode, but that code path won't be taken when the app is running for real."

Nobody ever learns (1)

The Second Horseman (121958) | about a year and a half ago | (#41714491)

The thing I love about this industry is that with every new platform, every generation of programmers manages to make errors that were made - and fixed - by a previous generation or on a previous platform. And it's an industry that aggressively weeds out experience - which is uniquely dysfunctional.

Credit card issuers and processors need to come down on this like a ton of bricks. Losing your access to a card network or losing your merchant agreement would probably be a powerful incentive.

FOR SOME REASON my 2 cents worth (0)

Anonymous Coward | about a year and a half ago | (#41714913)

i think that some of the snarky applehead comments are being posted by linux users(or ms users) just so that they can start a new battle in the OS holywar---and vice-versa
kinda funny if i think about it that way but its better than if they were breaking into my car .
WHATEVER IT TAKES TO GET YOU THRU THE DAY!!!

Need SSL UI guidelines (1)

mveloso (325617) | about a year and a half ago | (#41714989)

One of the reasons this problem exists is there are no guidelines as to exactly how to present this problem to the user.

The user can't do anything about the problem - but they have to be told that their transaction (whatever it is) has failed or cannot be completed.

I suspect that on a PC, most people have no idea what that "certificate problem" dialog box means. As far as they're concerned, it's a useless error that happened on the way to their online banking session.

On mobile, it's even worse. You're using SSL behind the scenes, and what can you say?

"I'm sorry, I was trying to log in and the server credentials are different than what I expected. I can't log you in."

This will make even less sense to an end user, and won't fit on the screen.

"It appears that someone is trying to intercept the data we're sending to our servers. Do you want to continue and expose your private data to an unknown person?"

That's probably more accurate.

"For some reason, we couldn't verify the security of your connection. Do you want to continue and expose your data to an unknown person?"

That's probably a good error message, but I'm sure others can come up with better ones.

If you're using a self-signed cert, install your root into your app. Why not? It'll at least allow you to not turn off host checking.

This may be more of a problem overseas, but I've been in hotels in the US that I've been to that have tried to MTM on SSL (ie: the cert is from some network device in the hotel, not my bank). It was very strange.

Re:Need SSL UI guidelines (1)

mveloso (325617) | about a year and a half ago | (#41715225)

And another thing: why don't browsers show you the problem on the screen? They just have a "show certificate" button, and they let you figure out what the heck is wrong. Most people won't have any idea why a given certificate didn't pass validation. Here's a short list that browser makers can use:

1. The server name doesn't match the name on the certificate (common).
Insecurity risk: low.
Action: Highlight the hostname in the URL and the hostname on the destination server.
User Suggestion: contact the server administrator about the problem and continue on.

2. The issuer of the certificate is unknown to me (the browser).
Insecurity risk: high on a public website, low on an internal site.
Action: Highlight the issuer and the website that you were trying to connec tto
User suggestion: if you recognize the issuer as someone you know (like your company) and you're connecting to the company's website, continue. If not, do not continue and disconnect your computer from the network.

3. The domain name on the certificate doesn't match the one I tried to connect to (unusual).
Insecurity risk: high
Action: highlight the domain name on the certificate, the domain name you tried to connect to, and the issuer.
User suggestion: the website i'm trying to connect to appears to be a totally different site than I was expecting. This may mean that someone is trying to intercept your data. We recommend that you stop all activity and disconnect your computer.

4. The certificate is valid, but it's expired (common).
Insecurity risk: low
Action: highlight the expiration date of the cert, and show that everything else is good.
Risk: low, if everything else is valid
User suggestion: It appears the security certification of the website is expired. Everything else looks OK, and the risk of interception is low. Continue?

Re:Need SSL UI guidelines (1)

shiftless (410350) | about a year and a half ago | (#41716251)

Or you can just use a computer, which can be programmed to automatically calculate what the overall level of "insecurity" may be in each particular case, and condense it down to a simple "blue green yellow red" type indicator, to make it easy for the user to tell at a glance what the potential risk may be....instead of overwhelming the user with dialogs full of text which the user simply isn't going to understand. Why the hell should the browser even pop up a dialog? Just flash a big red warning in the corner of the address bar or something if the site security isn't up to snuff.

Mozilla Firefox is the worst example of stupidity in this case. Whichever developers decided it would be best to scare the shit out of the user and make him jump through hoops every time a certificate isn't perfect, out to be hauled out back, lined up, and summarily given a stern talking to. What horrible UI design.

Anyone know (1)

rsilvergun (571051) | about a year and a half ago | (#41715419)

a good 'how to use ssl safely' tutorial? I guess that's the real question. It seems to me something as common as this should be well documented/implemented. I mean, google wrapped SQL for me. Heck, google's code let me get a rudimentary spend tracker [glimmersoft.com] written in under 6 hours and my silly little mirroring app [google.com] in under 4. Their APIs are so simple and well organized that it brings computing back to the age when I write the apps I want, like coding Basic for my C64.

Probably the problem is google can't implement their own SSL w/o worrying about liability :(.

Hey, all you Mensa level tech guys!... (1)

SternisheFan (2529412) | about a year and a half ago | (#41716599)

Hi techie guys, 'normal' non-super techie guy here, and I've been reading all your posts about certificates & the lack of security and all, and I do have a question....

Can you guys all get together on this and FIX IT??!!! WTF??! I thought you all were SUPPOSED TO KNOW how to make financial transactions secure! Sounds like everyone's passing the buck (no pun intended) here, blaming it all on somebody else's bad coding. That's not a reasonable excuse for a user's banking activity to be left so open. Either it's secure or it isn't, even 99.9% secure is not good enough. I mean, thanks for reminding me again why I don't entrust my finances to personal tech, I stay old school offline, and deal directly at a bank office, but c'mon! Come up with a solid secure system that works!!! The people of the world would be reallyreally grateful to you then, right now it's like playing russian roulette when you use any online form of banking, odds are that the hammer will fall on an empty chamber, but sooner or later...

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...