Poor SSL Implementations Leave Many Android Apps Vulnerable

← Back to Stories (view on slashdot.org)

Poor SSL Implementations Leave Many Android Apps Vulnerable

Posted by timothy on Saturday October 20, 2012 @12:27AM from the that's-why-they-buy-guns dept.

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

141 comments

Min score:

Reason:

Sort:

Android continues to be security disaster by PieThrow · 2012-10-20 00:28 · Score: 0, Troll

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.
1. Re:Android continues to be security disaster by Anonymous Coward · 2012-10-20 00:48 · Score: 4, Insightful
  
  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).
2. Re:Android continues to be security disaster by tqk · 2012-10-20 02:29 · Score: 0, Flamebait
  
  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.
  
  --
  "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
3. Re:Android continues to be security disaster by Anonymous Coward · 2012-10-20 02:58 · Score: 0
  
  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.
4. Re:Android continues to be security disaster by tqk · 2012-10-20 03:23 · Score: 1
  
  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?!?).
  
  --
  "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
5. Re:Android continues to be security disaster by Anonymous Coward · 2012-10-20 03:31 · Score: 0
  
  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.
6. Re:Android continues to be security disaster by Lord+Ender · 2012-10-20 09:02 · Score: 1
  
  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.
  
  --
  A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
7. Re:Android continues to be security disaster by tqk · 2012-10-20 12:34 · Score: 1
  
  Holy !@#$, mods! You think that's flamebait?!? Jeebus. :-P
  
  --
  "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
8. Re:Android continues to be security disaster by Anonymous Coward · 2012-10-20 13:12 · Score: 0
  You're not especially pedantic this morning; it's possible for a troll to post a flamebait. :)
  Although, to be honest, I never quite got the distinction between "troll" and "flamebait" moderation options. The slashdot FAQ defines them as:
  
  Flamebait: Comments whose sole purpose is to insult and enrage.
  
  Troll: A Troll is similar to Flamebait, but slightly more refined. This is a prank comment intended to provoke indignant (or just confused) responses.
  
  So I guess it depends on how refined you think the post was.
9. Re:Android continues to be security disaster by tqk · 2012-10-20 15:37 · Score: 1
  
  For me, "Flamebait" is (eg.) Apple fanbois dissing Google/Android egregiously, or Android fanbois dissing Apple egregiously, or Linux fanbois dissing (Apple|MS|...) egregiously, ...
  Sucks to be us. I wish we could just all get along. "Trolling" is just dorks trying to get a rise out of anyone that falls for their schpiel. A la spam.
  Good morning! Well, soon methinks.
  [FLOSS fanboi here, if it's not obvious.]
  
  --
  "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
10. Re:Android continues to be security disaster by the_B0fh · 2012-10-20 17:05 · Score: 0
  
  bah. like anything else, most mods are idiots. shrug.
11. Re:Android continues to be security disaster by makomk · 2012-10-20 21:16 · Score: 2
  
  "This century's most fatal security disaster"? Sounds pretty flamebaity to me. (This is also not the worst certificate-related screw-up even within the last year, either - for instance Microsoft has done worse by accidentally giving out certificates that allow attackers to sign fake Windows updates and not fixing the problem until it was exploited in the wild to compromise a number of Windows systems.)
12. Re:Android continues to be security disaster by tqk · 2012-10-23 12:53 · Score: 1
  
  "This century's most fatal security disaster"? Sounds pretty flamebaity to me.
  Methinks you may be too sensitive. Dipshits say stupid things. Just because he's a dipshit saying stupid things doesn't mean he's evil/playing with your BRAINZ. I'd prefer to extend all the rope I've got to give him the chance to hang himself, if he can. :-) Meh. I'm old. I doubt my opinion's relevant nowadays. "So much, for the glory of Rome." -- Marcus Aurelius; "Gladiator."
  "The philosopher; the Warrior; the Tyrant?" Ibid.
  See you in Elysium. :-)
  
  --
  "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
A question by Chrisq · 2012-10-20 00:31 · Score: 5, Interesting

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?
1. Re:A question by Anonymous Coward · 2012-10-20 00:45 · Score: 0
  
  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.
2. Re:A question by cfriedt · 2012-10-20 00:55 · Score: 1
  
  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.
3. Re:A question by Anonymous Coward · 2012-10-20 01:05 · Score: 0
  
  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.
4. Re:A question by Anonymous Coward · 2012-10-20 03:07 · Score: 1
  
  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
5. Re:A question by PPH · 2012-10-20 04:16 · Score: 1
  
  Or someone needs to write a wrapper around the existing SSL API. Put it (and other simplification stuff) in libn00b.
  
  --
  Have gnu, will travel.
6. Re:A question by ajo_arctus · 2012-10-20 08:32 · Score: 1
  
  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...
7. Re:A question by george14215 · 2012-10-20 10:04 · Score: 1
  
  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?
  The issue is that different Android devices in different countries have a different set of root certificates installed. So some customers complain to the app provider that they can't talk to their servers. Invariably, the SSL platform cannot chain the server SSL cert to any installed root cert. The app developers then provide an update to work around this using self signed certs or other workarounds.
A lot of apps use SSL by Kagetsuki · 2012-10-20 00:44 · Score: 5, Insightful

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.
1. Re:A lot of apps use SSL by Anonymous Coward · 2012-10-20 00:46 · Score: 4, Insightful
  
  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.
2. Re:A lot of apps use SSL by Anonymous Coward · 2012-10-20 00:49 · Score: 1
  
  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!
3. Re:A lot of apps use SSL by Anonymous Coward · 2012-10-20 00:55 · Score: 1, Insightful
  
  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.
4. Re:A lot of apps use SSL by sithlord2 · 2012-10-20 00:56 · Score: 5, Insightful
  
  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.
  
  --
  ...You are over-qualified and under-paid. If we give you a raise, we will break the cosmic balance of the universe.
5. Re:A lot of apps use SSL by dbIII · 2012-10-20 01:13 · Score: 3, Interesting
  
  Tell that to what seems like 9/10 of the sites on the net, expired certs seem to be more common than current ones.
6. Re:A lot of apps use SSL by Anonymous Coward · 2012-10-20 01:21 · Score: 2, Interesting
  
  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.
7. Re:A lot of apps use SSL by Kagetsuki · 2012-10-20 01:21 · Score: 3, Informative
  
  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/ 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.
8. Re:A lot of apps use SSL by Xugumad · 2012-10-20 01:26 · Score: 1
  
  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.
9. Re:A lot of apps use SSL by DarkOx · 2012-10-20 01:31 · Score: 1
  
  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?
  
  --
  Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
10. Re:A lot of apps use SSL by Anonymous Coward · 2012-10-20 01:36 · Score: 0
  
  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.
11. Re:A lot of apps use SSL by Kagetsuki · 2012-10-20 01:39 · Score: 2
  
  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.
12. Re:A lot of apps use SSL by DarkOx · 2012-10-20 01:40 · Score: 3, Insightful
  
  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.
  
  --
  Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
13. Re:A lot of apps use SSL by Kagetsuki · 2012-10-20 01:46 · Score: 1
  
  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.
14. Re:A lot of apps use SSL by Anonymous Coward · 2012-10-20 02:03 · Score: 1
  
  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.
15. Re:A lot of apps use SSL by Kagetsuki · 2012-10-20 02:09 · Score: 1
  
  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.
16. Re:A lot of apps use SSL by Anonymous Coward · 2012-10-20 02:16 · Score: 1
  
  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/ 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?
17. Re:A lot of apps use SSL by Alan+Shutko · 2012-10-20 02:28 · Score: 1
  
  Programming is HARD! Let's go shopping!
18. Re:A lot of apps use SSL by Anonymous Coward · 2012-10-20 02:31 · Score: 0
  
  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 :)
19. Re:A lot of apps use SSL by Anonymous Coward · 2012-10-20 02:33 · Score: 2, Insightful
  
  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.
20. Re:A lot of apps use SSL by Anonymous Coward · 2012-10-20 03:07 · Score: 0
  
  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.
21. Re:A lot of apps use SSL by tqk · 2012-10-20 03:12 · Score: 1
  
  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.
  
  --
  "Tongue tied and twisted, just an Earth bound misfit ..." -- Pink Floyd.
22. Re:A lot of apps use SSL by multi+io · 2012-10-20 03:14 · Score: 1
  
  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
23. Re:A lot of apps use SSL by cratermoon · 2012-10-20 04:06 · Score: 1
  
  à_à
  This is why we can't have nice things.
24. Re:A lot of apps use SSL by cratermoon · 2012-10-20 04:09 · Score: 1
  
  Let me tell you the story about the guy who wanted to use oauth2 bearer tokens over an unsecured connection.
25. Re:A lot of apps use SSL by cratermoon · 2012-10-20 04:15 · Score: 1
  
  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?
26. Re:A lot of apps use SSL by cratermoon · 2012-10-20 04:22 · Score: 1
  
  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?
27. Re:A lot of apps use SSL by sithlord2 · 2012-10-20 04:50 · Score: 1
  
  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.
  
  --
  ...You are over-qualified and under-paid. If we give you a raise, we will break the cosmic balance of the universe.
28. Re:A lot of apps use SSL by sithlord2 · 2012-10-20 05:02 · Score: 1
  
  And I don't see the problem with that if the developer needs the money to feed his family.
  
  --
  ...You are over-qualified and under-paid. If we give you a raise, we will break the cosmic balance of the universe.
29. Re:A lot of apps use SSL by colinrichardday · 2012-10-20 05:22 · Score: 1
  
  Only if the CA is genuine!
30. Re:A lot of apps use SSL by WaffleMonster · 2012-10-20 05:31 · Score: 1
  
  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.
31. Re:A lot of apps use SSL by dgatwood · 2012-10-20 05:43 · Score: 3, Insightful
  
  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 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.
  
  --
  Check out my sci-fi/humor trilogy at PatriotsBooks.
32. Re:A lot of apps use SSL by Anonymous Coward · 2012-10-20 05:47 · Score: 0
  
  But... but... but... Apple is teh evilzz!!!!111!!!
33. Re:A lot of apps use SSL by Pieroxy · 2012-10-20 06:15 · Score: 1
  
  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?
  
  --
  Write boring code, not shiny code!
34. Re:A lot of apps use SSL by cratermoon · 2012-10-20 06:33 · Score: 1
  
  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.
35. Re:A lot of apps use SSL by shiftless · 2012-10-20 07:09 · Score: 1
  
  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.
36. Re:A lot of apps use SSL by shiftless · 2012-10-20 07:18 · Score: 1
  
  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?
37. Re:A lot of apps use SSL by Jmc23 · 2012-10-20 07:31 · Score: 1
  
  I think we can all tell that by your childish nick.
  
  --
  Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
38. Re:A lot of apps use SSL by KZigurs · 2012-10-20 09:28 · Score: 1
  
  With android a common problem is which CAs are recognised, which versions of their root certs and which operators have decided to fuck up the cert chain due to political reasons.
  Also - whether webview in applications support the same cert chains that browsers do or subset at mercy of 3 year old out of date build.
  So yeah, as far as I'm concerned the SSL on android is generally useless. Due to SSL being unusable in real world more so than due to 'lazy devs'.
39. Re:A lot of apps use SSL by dkf · 2012-10-20 11:25 · Score: 2
  
  But... but... but... Apple is teh evilzz!!!!111!!!
  But correct in this case. Of course, it's been the right thing to do since long before Apple started making iPods; they're just repeating the statement of best practices (that they've copied from elsewhere; in this case, not a problem at all).
  No, the real problem in this case is to do with developers who insist on not acquiring a properly-signed certificate during development and testing (I've seen several different reasons for doing it, from being cheap-asses to "not wanting The Man to track me"). They just use a self-signed cert and turn off everything that tries to tell them that this is a spectacularly bad idea. It's not rocket science (unless you're dumb-smart enough to want to write your own SSL implementation from scratch), but it does require you to plan to do things right a little earlier.
  
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
40. Re:A lot of apps use SSL by Kagetsuki · 2012-10-20 14:56 · Score: 1
  
  Actually I didn't want to deal with the client. It was a job nobody else was taking, but a friend of a friend, and when I made it clear there was an SSL issue he just said to make it work and he didn't care. In order to make it work their in-house dev would have had to set things up serverside to do so and I don't think I could have ever gotten him to do it right anyway.
  And the pay was awful, I pretty much lost money on it.
41. Re:A lot of apps use SSL by Kagetsuki · 2012-10-20 15:09 · Score: 1
  
  I wasn't the only factor here (the serverside deve was a different person unrelated to me) and in this case it was an internationalized domain that needed subdomain wildcards and a corporate cert. Find me one of those for $50 and I'll love you forever.
  But you are damn right about SSL giving devs rope to hang themselves with. There are so many places to create holes in the system, and if your implementation scenario has one exception you need to make [not a "common usage scenario"] things get real messy real quick.
  But I would like to point out that serverside SSL on nginx is very easy and if you don't have a funny configuration or your app isn't an intranet app then the standard SSL handlers on Android can pretty much be used as-is. So the reality is if you have a common usage scenario it is not difficult at all.
42. Re:A lot of apps use SSL by MikeBabcock · 2012-10-20 16:32 · Score: 1
  
  Funny, I almost never see an expired cert in my day to day browsing. I pay for a cert every year for my mail server, its not expensive and its well worth it.
  
  --
  - Michael T. Babcock (Yes, I blog)
43. Re:A lot of apps use SSL by the_B0fh · 2012-10-20 17:56 · Score: 1
  
  go on.... :)
44. Re:A lot of apps use SSL by dkf · 2012-10-20 22:15 · Score: 1
  
  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".
  Operationally, a private CA works at least as well and provides an equivalent level of trust. The advantage is that the CA's private credentials can be kept offline in a safe most of the time, so they're much harder to lose, yet you don't need to futz around with adjusting clients so much when you create a new server certificate for operational use.
  
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
45. Re:A lot of apps use SSL by strikethree · 2012-10-20 22:41 · Score: 2
  
  With those prices today, I cannot find one argument in favor of a self-signed certificate.
  I can. Trust. I do not trust -any- of the commercial registrars and neither should you. We have seen all sorts of crazy antics where they delegate trust and shenanigans happen. Of course, you are welcome to trust them if you wish. :)
  I use SSL as if it were PGP. I like the encryption and I like the non-repudiation. I also appreciate the capability to set up an infrastructure of trust but I have not seriously set up any such infrastructure yet.
  
  --
  "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
46. Re:A lot of apps use SSL by dkf · 2012-10-20 22:45 · Score: 1
  
  Fortunately Carol already heard through the grapevine that Mallory is a sleazy whore, and refused to accept her certificate.
  It's a good thing that certificates are only proof of identity, not proof of authority.
  
  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?
  I suggest you go away and actually try to fake or backdoor a digital signature (on something with a realistic key size and used in a proper protocol like SSL) before making that claim. While you can easily fake the Distinguished Name, the cryptographic part of the signature is really hard to fake; the easiest way to fool a client is to get it to trust a different trust root that you control so you can inject certs with the same DN as the real ones. Which is what TFA was originally about.
  
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
47. Re:A lot of apps use SSL by cratermoon · 2012-10-21 05:19 · Score: 1
  
  That's not wrong, but it still doesn't explain to me why I, as a user, should trust both application A and site B that have agreed to trust each other with a self-signed certificate. The reason was have the CA model is to introduce a trusted third-party* that can verify for us that everything is on the up-and-up. The user should not be in the position of having to trust unknown parties.
  *Yes I know the CA companies have problems. Maybe the model is so broken by nature that it doesn't matter, but it's still true that the self-signed model bypasses it.
48. Re:A lot of apps use SSL by cratermoon · 2012-10-21 05:23 · Score: 1
  
  Probably no shock that it's a PHP developer:
  
  $opts[CURLOPT_SSL_VERIFYPEER] = false; $opts[CURLOPT_SSL_VERIFYHOST] = 2;
49. Re:A lot of apps use SSL by cratermoon · 2012-10-21 05:27 · Score: 1
  
  Next time say, "I'm sorry, I'm a professional software developer, and I have to follow certain principles, same as a doctor or lawyer must follow their respective professional codes. Please contact me when your server side is properly configured and I will be able to complete the work."
50. Re:A lot of apps use SSL by cratermoon · 2012-10-21 05:31 · Score: 1
  
  Good answer. To be fair to the parent post, the certificate authorities *do* have some work to do in cleaning their own houses. Stolen or compromised certificates do exist, and while we can revoke the ones we know about, there's the ones we don't know about, and there's the clients that don't handle revocation properly. It's not clear that the CA houses are doing their jobs well enough.
51. Re:A lot of apps use SSL by KZigurs · 2012-10-21 09:30 · Score: 1
  
  Fix the way Android threats CA's first, then speak.*
  *subject to whims of operator, out-of-date root CA's, sets of devices support one CA, sets - somebody else (and I'm talking here about the support of first name operators).
52. Re:A lot of apps use SSL by dgatwood · 2012-10-22 08:36 · Score: 1
  
  That problem can be fixed with the same technique that you *should* be using if you're working with self-signed certs—either hard-code your CA cert into your app and override the method that returns the list of trusted anchors to return the system set plus your own or set up a trust store that indicates trust for that anchor.
  Or if you're really paranoid, hard-code a list of CA certs that you trust, which may only partially overlap with the system-provided set.
  
  --
  Check out my sci-fi/humor trilogy at PatriotsBooks.
53. Re:A lot of apps use SSL by hobarrera · 2012-10-24 09:05 · Score: 1
  
  It slightly above what a developer makes per month in some countries. US/Europe isn't the entire world, you know.
User Confidence by BoRegardless · 2012-10-20 00:52 · Score: 0

Do Android users have confidence in their security? Do they even think about it?
1. Re:User Confidence by amiga3D · 2012-10-20 01:46 · Score: 1, Insightful
  
  I would never consider using an Android phone for any banking access. Never.
2. Re:User Confidence by Anonymous Coward · 2012-10-20 02:08 · Score: 0, Insightful
  
  I would never consider using an Android phone for any access. Never.
  FTFY
3. Re:User Confidence by cratermoon · 2012-10-20 03:58 · Score: 1
  
  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.
4. Re:User Confidence by tepples · 2012-10-20 04:19 · Score: 1
  
  Do you consider paying for paid applications through Google Play Store or Amazon Appstore to constitute "banking access"?
5. Re:User Confidence by the_B0fh · 2012-10-20 18:20 · Score: 1
  
  Please don't make the punters think too hard. Their heads may explode.
6. Re:User Confidence by amiga3D · 2012-10-23 09:53 · Score: 1
  
  frankly I haven't seen anything in google playstore enough better than the free stuff to actually pay money for.
I have now read the article and it is apps misuse by Chrisq · 2012-10-20 00:53 · Score: 4, Informative

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.
cue the snarky applehead comments by Anonymous Coward · 2012-10-20 00:55 · Score: 0

3
2
1
and....
go
1. Re:cue the snarky applehead comments by laffer1 · 2012-10-20 01:10 · Score: 1
  
  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.
  
  --
  MidnightBSD: The BSD for Everyone
2. Re:cue the snarky applehead comments by amiga3D · 2012-10-20 01:51 · Score: 2
  
  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.
3. Re:cue the snarky applehead comments by Anonymous Coward · 2012-10-20 03:04 · Score: 0
  
  except the apple app store actually has quality controls and rejects apps from retards.
4. Re:cue the snarky applehead comments by Anonymous Coward · 2012-10-20 03:28 · Score: 0
  
  Wouldn't that be redundant since all of the iOS apps are written by retards?
5. Re:cue the snarky applehead comments by laffer1 · 2012-10-20 03:42 · Score: 1
  
  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.
  
  --
  MidnightBSD: The BSD for Everyone
6. Re:cue the snarky applehead comments by Anonymous Coward · 2012-10-20 03:55 · Score: 0
  
  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.
7. Re:cue the snarky applehead comments by Anonymous Coward · 2012-10-20 06:30 · Score: 0
  
  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.
8. Re:cue the snarky applehead comments by shiftless · 2012-10-20 07:28 · Score: 1
  
  ... intellectual property ...
  
  Think of it as an IQ test.
  And you failed
team was able to intercept sensitive user data by Anonymous Coward · 2012-10-20 01:53 · Score: 0

If your feeding sensitive data to an android app, the ssl implementation is the least of your wories.
android crapps suck, news at 11 by Anonymous Coward · 2012-10-20 02:11 · Score: 0

tell us something we don't already know
1. Re:android crapps suck, news at 11 by Anonymous Coward · 2012-10-20 07:30 · Score: 0
  
  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? by Anonymous Coward · 2012-10-20 02:22 · Score: 0

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.
Nobody ever learns by The+Second+Horseman · 2012-10-20 03:07 · Score: 1

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.
Re:I have now read the article and it is apps misu by cratermoon · 2012-10-20 03:53 · Score: 1

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. 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.
Certificate expiry is a heuristic by tepples · 2012-10-20 03:58 · Score: 2, Interesting

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.
1. Re:Certificate expiry is a heuristic by the_B0fh · 2012-10-20 17:08 · Score: 2
  
  and that's why my password is a 2048 character password that changes every other second, because, SECURITY!!!!
The certificate is not the problem; IPv4 is by tepples · 2012-10-20 04:03 · Score: 4, Informative

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.
1. Re:The certificate is not the problem; IPv4 is by KZigurs · 2012-10-20 09:30 · Score: 1
  
  What does it matter if 70% of android phones sold doesn't include even current root CAs of the recognised authorities. Not even touching on the subject of what makes them 'trusted'
2. Re:The certificate is not the problem; IPv4 is by strikethree · 2012-10-20 21:59 · Score: 1
  
  Hm. I have not played with certificates and such for a while; however, I am pretty sure that IP addresses are irrelevant. IIRC, the DNS needs to match the CN (CN == Common Name field in the certificate). If an otherwise valid certificate is used on a site with a DNS CN mismatch, then there is an error. The IP address can change randomly as long as the DNS resolves correctly.
  
  --
  "Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
3. Re:The certificate is not the problem; IPv4 is by cmdrbuzz · 2012-10-20 23:09 · Score: 1
  
  Without SNI you can only have one certificate per IP address as the certificate is sent to the client before the client can send the Host: header to indicate which site he is trying to access.
  The only way around this (apart from using SNI) is either wildcard certs or SAN attributes.
  Once the server has sent the certificate the client will check to see if the certificate matches the DNS name it is attempting to access (either CN or SAN), however this is done by the client without the server knowing which DNS name the client is looking for. Hence the SNI requirements.
If you're going to be that paranoid about it by caveat · 2012-10-20 04:04 · Score: 1

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!

--

Facts do not cease to exist because they are ignored. - Aldous Huxley
1. Re:If you're going to be that paranoid about it by amiga3D · 2012-10-23 09:50 · Score: 1
  
  I like it. I'll have to look into OpenBSD. My paranoia knows no bounds.
A lot of apps use shared hosting by tepples · 2012-10-20 04:06 · Score: 2

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.
1. Re:A lot of apps use shared hosting by the_B0fh · 2012-10-20 17:13 · Score: 1
  
  If Chrome on Windows can use Server Name Indication then there is no reason why those libraries would not be available on Android unless Google became really really stupid.
2. Re:A lot of apps use shared hosting by the_B0fh · 2012-10-20 17:15 · Score: 1
  
  I see you responded later with why this happens - only fixed in 3.0 and above.
  And people say there's no fragmentation... bwahahaha
Micro-ISVs by tepples · 2012-10-20 04:12 · Score: 1

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"?
1. Re:Micro-ISVs by cratermoon · 2012-10-20 04:26 · Score: 1
  
  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?
2. Re:Micro-ISVs by tepples · 2012-10-20 05:04 · Score: 1
  
  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.
3. Re:Micro-ISVs by sithlord2 · 2012-10-20 05:29 · Score: 1
  
  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...!!
  
  --
  ...You are over-qualified and under-paid. If we give you a raise, we will break the cosmic balance of the universe.
4. Re:Micro-ISVs by cratermoon · 2012-10-20 06:29 · Score: 2
  
  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?
5. Re:Micro-ISVs by shiftless · 2012-10-20 07:14 · Score: 2
  
  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"?
6. Re:Micro-ISVs by tepples · 2012-10-21 02:22 · Score: 1
  
  You make good points. I need clarification on one more thing: where should one find "enough cash for your initial investments + cover your costs for the first year at least"?
7. Re:Micro-ISVs by cratermoon · 2012-10-21 05:33 · Score: 1
  
  I can't answer that right now, I don't have a tinfoil hat handy. Sorry.
8. Re:Micro-ISVs by shiftless · 2012-10-22 04:15 · Score: 1
  
  Tinfoil hat? No, what you have is your head buried so far up your ass you haven't seen daylight in years. If you don't think U.S. intelligence services (i.e. NSA) have backdoors into such things, you're naive.
9. Re:Micro-ISVs by sithlord2 · 2012-10-29 01:31 · Score: 1
  
  By saving a lot of money for a few years before you start your business and/or involving investors...
  
  --
  ...You are over-qualified and under-paid. If we give you a raise, we will break the cosmic balance of the universe.
10. Re:Micro-ISVs by tepples · 2012-10-29 02:37 · Score: 1
  
  By saving a lot of money for a few years
  And where does this money come from, if one is considering starting a business because he is having trouble finding an employer in his field?
11. Re:Micro-ISVs by sithlord2 · 2012-10-30 10:33 · Score: 1
  
  Okay listen... Starting a business costs money... a lot of money. If you don't have the funds to overcome a year without income, you shouldn't be starting a business in the first place. If you are out of a job, I hope you saved money when you still had a job.
  
  And read the second part of my sentence: involving investors. Maybe you can convince former businesspartners to invest in your company? Or maybe contact an ex-colleague who happens to be out of a job too?
  
  You may not like the truth, but that doesn't change the fact that starting a business costs money. I considered the same thing when I was unemployed, and I almost started one too. But I took a look at the worst-case scenario (giving my current financial status at that time), and I realized that things could get very ugly if I didn't start making profit after the first 6 months. That's quite a short period, and given the economy at that time, I was not sure that would be the case. So, yeah, I know what you are going through. Ofcourse, if you already have an interested customer who's willing to spent his money on you for a year, than I guess you can take the risk.
  
  You can also try to do some freelance consulting (team up with some big consulting companies if you have to). It allows you to make money, and gives you the freedom to start your company when your finances are looking better. Most IT freelancing jobs don't require a big investment (laptop+office suite software+some bookkeeping stuff). That's how Joel Spolsky of Fog Creek Software started his company, I believe... (do consulting to bring in the money, while working on his software product)
  
  --
  ...You are over-qualified and under-paid. If we give you a raise, we will break the cosmic balance of the universe.
Use a sound card as a cheap hardware RNG by tepples · 2012-10-20 04:15 · Score: 1

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.
In the 1990s, certs were expensive and IPs cheap by tepples · 2012-10-20 04:18 · Score: 1

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.
FOR SOME REASON my 2 cents worth by Anonymous Coward · 2012-10-20 04:19 · Score: 0

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!!!
It's misusing OS-supplied tools by tepples · 2012-10-20 04:24 · Score: 1

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."
Need SSL UI guidelines by mveloso · 2012-10-20 04:28 · Score: 1

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.
1. Re:Need SSL UI guidelines by mveloso · 2012-10-20 04:57 · Score: 1
  
  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?
2. Re:Need SSL UI guidelines by shiftless · 2012-10-20 07:38 · Score: 1
  
  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.
3. Re:Need SSL UI guidelines by dkf · 2012-10-20 23:00 · Score: 1
  
  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.
  The problem is this case (from the GP):
  
  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.
  The problem? Knowing whether a site is public or internal is rather hard to do. (For example, we use very many domains in our internal websites, especially ones that have substantial pieces that are also public.) I suppose you could do it by having some way of finding out (from DHCP? or maybe local DNS?) the address of a service that will describe what services are internal to you, but that's starting to get really complicated (and not widely deployed, which makes it a problem in practice).
  
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
Re:In the 1990s, certs were expensive and IPs chea by sithlord2 · 2012-10-20 04:57 · Score: 1

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

--
...You are over-qualified and under-paid. If we give you a raise, we will break the cosmic balance of the universe.
Re:In the 1990s, certs were expensive and IPs chea by sithlord2 · 2012-10-20 04:59 · Score: 1

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

--
...You are over-qualified and under-paid. If we give you a raise, we will break the cosmic balance of the universe.
Anyone know by rsilvergun · 2012-10-20 05:24 · Score: 1

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 written in under 6 hours and my silly little mirroring app 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 :(.

--
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Re:I have now read the article and it is apps misu by sithlord2 · 2012-10-20 05:45 · Score: 1

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.

--
...You are over-qualified and under-paid. If we give you a raise, we will break the cosmic balance of the universe.
Exactly, SSL should already be provided by Anonymous Coward · 2012-10-20 06:22 · Score: 0

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:I have now read the article and it is apps misu by cratermoon · 2012-10-20 06:27 · Score: 1

Do they actually check or are you saying they could or should?
Hey, all you Mensa level tech guys!... by SternisheFan · 2012-10-20 08:35 · Score: 1

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...
And this is news? by anerki · 2012-10-20 10:47 · Score: 1

Allowing just about anybody to create an app has a lot of upsides.
Allowing just about anybody to create an app has a lot of downsides. Too.

--
Life is great! (as told by Lady Susan)
What free movies? by tepples · 2012-10-23 11:49 · Score: 1

So what free music and free movies do you recommend as substitutes for those from Google? Or do you happen to live in a country where record labels and movie studios have chosen not to license their works to Google, and your version of the store has only apps or only apps and books?