Poor SSL Implementations Leave Many Android Apps Vulnerable 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."
A question (Score:5, Interesting)
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 (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.
Re:A lot of apps use SSL (Score:4, Insightful)
Re:A lot of apps use SSL (Score:4, Interesting)
Re: (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.
Certificate expiry is a heuristic (Score:3, 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.
Re: (Score:3)
and that's why my password is a 2048 character password that changes every other second, because, SECURITY!!!!
Re: (Score:2)
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.
Re: (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
Re: (Score:2)
Programming is HARD! Let's go shopping!
Re: (Score:2)
Only if the CA is genuine!
A lot of apps use shared hosting (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:2)
I see you responded later with why this happens - only fixed in 3.0 and above.
And people say there's no fragmentation... bwahahaha
The certificate is not the problem; IPv4 is (Score:5, Informative)
Re: (Score:2)
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'
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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'.
Re: (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!
Re:A lot of apps use SSL (Score:4, 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 [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: (Score:2)
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).
Re: (Score:2)
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.
Re: (Score:3)
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 jus
Re: (Score:2, Interesting)
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: (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.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
go on.... :)
Re: (Score:2)
Re: (Score:3)
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
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:A lot of apps use SSL (Score:5, Insightful)
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 (Score:4, 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/ [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: (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/ [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 (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (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"?
Re: (Score:2)
Re: (Score:2)
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?
Re: (Score:2)
It slightly above what a developer makes per month in some countries. US/Europe isn't the entire world, you know.
Re:A lot of apps use SSL (Score:4, 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.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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 th
Re: (Score:2)
Use a sound card as a cheap hardware RNG (Score:2)
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: (Score:2)
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: (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.
In the 1990s, certs were expensive and IPs cheap (Score:2)
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: (Score:3)
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.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
This is why we can't have nice things.
Re: (Score:2)
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 platfor
Re: (Score:2)
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
I have now read the article and it is apps misuse (Score:5, 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.
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Or someone needs to write a wrapper around the existing SSL API. Put it (and other simplification stuff) in libn00b.
Re: (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
Re: (Score:2)
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, w
User Confidence (Score:1)
Do Android users have confidence in their security? Do they even think about it?
Re: (Score:2, Insightful)
I would never consider using an Android phone for any banking access. Never.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Please don't make the punters think too hard. Their heads may explode.
Re: (Score:2)
frankly I haven't seen anything in google playstore enough better than the free stuff to actually pay money for.
What free movies? (Score:2)
Nobody ever learns (Score:2)
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.
Need SSL UI guidelines (Score:2)
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
Re: (Score:2)
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 ad
Re: (Score:2)
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
Anyone know (Score:2)
Probably the problem is google can't imple
Re: (Score:2)
Re:Android continues to be security disaster (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).
Re: (Score:2)
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: (Score:2)
Holy !@#$, mods! You think that's flamebait?!? Jeebus. :-P
Re: (Score:3)
"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.)
Re: (Score:2)
"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. :-)
Re: (Score:2)
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: (Score:2)
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.]
Re: (Score:2)
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: (Score:3)
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 paranoi
If you're going to be that paranoid about it (Score:2)
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 betw
Re: (Score:2)
I like it. I'll have to look into OpenBSD. My paranoia knows no bounds.
Re: (Score:2)
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.
It's misusing OS-supplied tools (Score:2)