FTC Settles With Sites Over SSL Lies

An anonymous reader writes "The makers of two major mobile apps, Fandango and Credit Karma, have settled with the Federal Trade Commission after the commission charged that they deliberately misrepresented the security of their apps and failed to validate SSL certificates. The apps promised users that their data was being sent over secure SSL connections, but the apps had disabled the validation process. The settlements with the FTC don't include any monetary penalties, but both companies have been ordered to submit to independent security audits every other year for the next 20 years and to put together comprehensive security programs."

Comments

Tip from a programmer

[jgotts]

This should be a lesson: If somebody is having trouble connecting with you, or you're under some kind of deadline pressure and you can't connect to them, don't turn off SSL validation. Get your connection working properly before going live. Because once you go live, you won't want to/may not be able to properly set up SSL.

Re:Tip from a programmer

[mysidia]

you're under some kind of deadline pressure and you can't connect to them, don't turn off SSL validation.

OR: Always turn off SSL validation, because it's totally worthless.

The problem is CAs get suberted all the time into issuing certs they shouldn't issue.

In general, the validation provided by a certificate doesn't work, and many developers and security professionals alike mistake the theoretical security benefits of validation, from the fact in reality.

SSL Certs = Maginot Line

What a sad state of affairs. The CA-signed certificate, far from being the key to browsing security, is the Maginot Line that preserves the masses in a state of blissful ignorance. It works perfectly against the attacks conceived and theorised as the dramatic threat to mankind, commerce and the Internet, a decade ago. Problem is, the attackers bypassed it, with as much disdain as any invading army against the last war's dug-in defence. Problem is, the security model had unreasonable expectations. Problem is, the users didn't subscribe to their part of the protocol. (To be fair, it's hard to communicate to users that they are even expected to be part of anything.)

Problem is, the browser manufacturers that were sold on the need for the certs also got sold on the convenience of click and launch. So, they turned around and sold the security model down the river faster than one can say "check the URL..."

The frequency of a true MITM - one defined above where someone has the ability to control an intermediate node at low level and take central position - is so low as to be difficult to measure. Using risk analysis, there is no economically viable support for mandating protection, so the deployment of a cert should be optional if there is any cost involved.

What about the spoof? In total contrast to the MITM, spoofs are common. As common as dirt, and as equally unclean. E-commerce sites with real value for thieving suffer spoofing attacks Does the Cert stop the Spoof? Nope. Well, of course not - not as described above. Obviously the user is at fault for entering - clicking - the wrong address, and not checking... ....

Re:Tip from a programmer

[EvanED]

The frequency of a true MITM - one defined above where someone has the ability to control an intermediate node at low level and take central position - is so low as to be difficult to measure.

This is about as dumb of an argument against SSL as I can imagine. True MITMs are reasonably rare in large part because of SSL.

SSL and CAs are far from perfect, but the situation is a hell of a lot better than if they weren't around...

Re:Tip from a programmer

[93 Escort Wagon]

I don't see any real lesson here because there was nothing punitive in the settlement. So, from the developer's perspective, what was so bad about disabling validation?

To my eye, the "lesson" is "feel free to do whatever you want, because even if you get caught all that'll happen is they'll make you start doing it the right way afterward".

Re:Tip from a programmer

[EvanED]

Not incidentally, I'll also point out that the linked article was written before wi-fi was common. At that point, it was perhaps much more reasonable. But nowadays, when people think nothing of connecting to public wi-fi networks, MITM protection is critical.

Re:Tip from a programmer

[jgotts]

Hi, you would be right except there is definitely something punitive in the settlement. Both formal security audits and formal certification procedures are very expensive to small business. If you have only a handful of developers and the audit or certification takes him out of circulation for 3-6 months that's very expensive. Even having your developers distracted by the necessarily niggling and picky auditors is expensive even if they aren't on it full time.

Okay, SSL has its flaws. But if you say SSL and don't have validation turned on then you're lying. If you don't believe in SSL then don't use it. Encrypt contents, but don't screw that up. A PCI-compliant installation might use SSL, encrypt the credit card data using a public key, and decrypt using a private key only on a server accessible via two-factor authentication. SSL is only one layer of the onion.

I'll bow out after this one. Thanks for the good discussion.

Re:Tip from a programmer

[radish]

If you don't trust your CA chain then do cert pinning. Either way you need to know you're talking to the right server, pretending that's impossible so it's not worth trying is a cop out.

Re:Tip from a programmer

[Anonymous Coward]

The problem is CAs get suberted all the time into issuing certs they shouldn't issue.

In general, the validation provided by a certificate doesn't work, and many developers and security professionals alike mistake the theoretical security benefits of validation, from the fact in reality.

The 2nd does not follow from the first.

Your comment should have been modded "Ignorant".

Re:Tip from a programmer

[bill_mcgonigle]

SSL and CAs are far from perfect, but the situation is a hell of a lot better than if they weren't around...

And sooner or later (sooner, I hope) we're going to move to multiple-CA attestations in the web's use of TLS. Go ahead, NSA, compromise three out of five of my CA's whist I send them each a CSR...

Re:Tip from a programmer

[arglebargle_xiv]

The frequency of a true MITM - one defined above where someone has the ability to control an intermediate node at low level and take central position - is so low as to be difficult to measure.

This is about as dumb of an argument against SSL as I can imagine. True MITMs are reasonably rare in large part because of SSL.

[Citation needed].

(For those who can't see the problem with this claim, consider the following: I wear a unicorn-repellent shirt. I know it works because while wearing it I've never been attacked by a unicorn).

Re:Tip from a programmer

[Charliemopps]

Yea, but Cert problems are so common that people routinely just click "yes" to anything that is cert related. The biggest problem with SSL is that it is difficult enough to get right that people are used to it not working right. When I was a teenager I worked in a department store where the alarm at the door would go off about once an hour... needless to say we never caught a single shop lifter.

Re:Tip from a programmer

[LordLimecat]

Wrong.

SSL certs do what theyre supposed to. There can be trust issues, but the whole "fake CA" thing isnt as big a deal as youre saying for a few reasons:

1) Such attacks are INCREDIBLY obvious. You may not notice right away, and I may not notice right away, but SOMEONE is going to notice that the thumbprint, issuing CA, etc for a prolific website all just changed. Gee, the Google SSL cert just change to an issuance date of today, the issuer changed from "Google Internet Authority G2" to "DigiNotar". Golly Gee, I wonder what that means?

2) Once such an attack is noticed, it is pretty easy to eliminate the threat: You untrust the CA. This has a number of great effects-- it removes the bad actors, it provides a good incentive for CAs to have their crap together, and it immediately fixes the threat for you.

3) Its risky because of #1. You have to REALLY need that information to risk the media feeding frenzy that will occur once someone notices the change.

4) Its hard to pull off. Not many attackers are going to have access to a trusted CA's signing certs.

So yes, you can be spied on with SSL, but its a LOT better to have SSL on than off as you have a number of ways of determining whether you are being spied on, there can be big repercussions for those doing the MITM, and it substantially raises the bar for most attackers.

Re:Tip from a programmer

[LordLimecat]

MITMs happen all the time in workplaces. Theyre called proxies. Thing is, if you're not using SSL they can be literally undetectable on your end. With SSL, they have to modify your trusted CA list and make obviously forged certs.

I believe there are firefox addons which detect SSL MITMs immediately.

Re:Tip from a programmer

[LordLimecat]

Thats THEIR problem, not SSL's problem. SSL works as intended, and notifies you when things arent right.

Re:Tip from a programmer

[mysidia]

This is about as dumb of an argument against SSL as I can imagine.

I'm not arguing against SSL. I'm arguing against CA Validation which was just A hand wave bolted onto SSL at the very end, in vain attempt to provide authenticitiy.

Re:Tip from a programmer

[arglebargle_xiv]

As the OP has pointed out, the argument is not against SSL, which isn't the problem, but the assumption that CAs provide some silver bullet against MITMs. This is what I meant with my post above.

Re:Tip from a programmer

[dgatwood]

Why would they need to compromise your CAs? They can compromise any CA, because unless the client uses a tighter-than-normal designated requirement, it will trust any cert for your domain as long as it is signed by any of dozens of CAs. That's what makes TLS so flawed.

Re:Tip from a programmer

[mysidia]

when people think nothing of connecting to public wi-fi networks, MITM protection is critical.

When people visit websites, they are often typing in example.com, not https://example.com

If you think MITM is the issue; the CA system doesn't help in this scenario, as the MITM is likely to negate the redirect to SSL in the first place, and to just keep the user in plain http.

Re:Tip from a programmer

[Lennie]

If you control both sides, use your own CA.

Really, it isn't that difficult.

But please don't disable validation.

Re:Tip from a programmer

[David Jao]

True MITMs are reasonably rare in large part because of SSL.

WRONG. Provably wrong.

There exists an extremely widely-used crypto protocol which uses no certificate validation and yet prevents almost all MITM attacks. It's called SSH. In fact SSH has done something that SSL will never do: it has completely replaced the corresponding unencrypted protocol, to the point where no one, I mean no one, uses telnet anymore.

How does this magic work? SSH performs key validation. It performs this validation without requiring certificates. The validation model is very simple: trust on first use (TOFU). Although TOFU on paper is theoretically inferior to CA validation in every way, real life does not take place on paper. In the real world, TOFU is far superior to CA validation. It prevents the kinds of attacks that actually matter, while ignoring the kinds of attacks that look great on paper but aren't really a big deal in practice.

Re:Tip from a programmer

[David Jao]

If you don't trust your CA chain then do cert pinning. Either way you need to know you're talking to the right server, pretending that's impossible so it's not worth trying is a cop out.

Certificate pinning is not possible in any real-world scenario. The problem is that certificates change too often. Certificate authorities are part of the problem: they encourage high turnover, because it increases their profits. Certificate pinning only works in situations where you have inside knowledge of a company's certificate policies. Google implements certificate pinning on their own Google properties in Chrome in this way. There is nothing in SSL that technically prevents certificate pinning, but the design of SSL has inevitably led to non-technical economic incentives that indirectly make certificate pinning impossible.

SSH essentially relies exclusively on key pinning (not certificate pinning) for authentication, and it works beautifully. SSH has no certificates, and yet has a higher market share in the shell connection market than SSL has in the http connection market. SSL should become more like SSH, but this is impossible to achieve, because CAs are already economically entrenched.

Re:Tip from a programmer

[aaaaaaargh!]

How do you know that? Clairvoyance?

For all we know by now it's possible and not implausible to assume that MITM attacks are conducted routinely by various intelligence agencies across the world. SSL is broken. You should not rely solely on CAs anymore. Use physically delivered security tokens (such as encrypted random data on a USB stick) and/or the trust model of ssh instead.

Re:Tip from a programmer

[DarkOx]

Well you can give people are the security tools in the world and if they are careless they will still leave the door unlocked and the alarm disarmed. There will always come a point where a human being has to make a security decision, because fundamentally all these machines exist in service of us humans in the first place.

Security is about risk, if someone does not perceive the probability times the costs of potential losses from an attack to be worth investing in learning enough about SSL/TSL, x.509 certificates, and the trust model to use it safely; they won't. Other people who do see the value, can effectively protect themselves with these tools against all but the most sophisticated attacks that generally require collusion by multiple parties.

No matter how much you invest in security and no matter what tools you employ there are some attacks you will not be able to resist. Finding the right balance is important.

I don't think SSL is to hard to use for must of what it protects though, "things should be as simple as possible but no simpler" Every way I can think to simplify the current system makes it more vulnerable not less.

Re:Tip from a programmer

[mysidia]

I may not notice right away, but SOMEONE is going to notice that the thumbprint, issuing CA, etc for a prolific website all just changed.

People are going to notice this regardless of whether or not you do CA-based certificate validation or not, so it is not a factor.

2) Once such an attack is noticed, it is pretty easy to eliminate the threat: You untrust the CA.

*Cough* Nonsense. What happened to Comodo? After they were compromised 3 times and issued numerous false certificates?

NOTHING. Zip. Nada. None of the browsers untrusted them.

Neither did any of the browsers untrust any of the other CAs that had issued and still have issued phony certs as a result of security compromise.

4) Its hard to pull off. Not many attackers are going to have access to a trusted CA's signing certs.

It is the MITM bit that is hard to pull off. It's relatively easy for attackers to get a fraudulently issued certificate issued, or to get one of thousands of CA's signing keys compromised ----- but in general the attacker can just ask for one, and authenticity verification when issuing a certificate happens to be a weak point.

Is Email encrypted? NO Then why is an e-mailed link being used to validate authorization to issue a cert?

Re:Tip from a programmer

[drinkypoo]

There exists an extremely widely-used crypto protocol which uses no certificate validation and yet prevents almost all MITM attacks. It's called SSH. In fact SSH has done something that SSL will never do: it has completely replaced the corresponding unencrypted protocol, to the point where no one, I mean no one, uses telnet anymore.

Or, for that matter, rsh. You know, the corresponding unencrypted protocol.

Telnet was an abomination, whose continued popularity was only necessary because there were so many crap terminals out there in the world, and systems without a POSIX environment :D

Re:Tip from a programmer

[Antique Geekmeister]

And the "man in the middle" is often actually at one end, on the local router or on the local network switch, with simple packet snifing in place. It's not rare, it is _ubiquitous_ in many educational and corporate environments.

Re:Tip from a programmer

[Antique Geekmeister]

> There exists an extremely widely-used crypto protocol which uses no certificate validation and yet prevents almost all MITM attacks.

Nonsense. Ownership of the host private keys, stolen from the target SSH server, allows quite effective MITM: see http://www.gremwell.com/ssh-mi... and http://www.snailbook.com/docs/.... Moreover, there is no reliable ownership or timestamp on SSH private keys. And worse, there is no working signature authority _available_ for SSH host keys. This makes spoofing an SSH server for new users much simpler. And most envornmnets are not careful to tie the SSH private keys to a specific exposed server or service: they wind up resetting the host keys when they rebuild the host, and pay no attention to a client's confusion about changing keys.

This is, effectively, no different than enabling SSL keys without any signature whatsoever, which is the state of SSL in most environments because many private and public institutions do not bother to purchase signatures for their SSL keys.

Re:Tip from a programmer

[kasperd]

In fact SSH has done something that SSL will never do: it has completely replaced the corresponding unencrypted protocol

You surely know the reasons ssh was able to achieve this and SSL isn't. But for the benefit of others it is worthwhile spelling out the reasons. First of all SSL certificates means there is some additional difficulty to getting started with SSL, which isn't there for ssh. Switching from telnet, rsh and rcp to ssh really was as simple as installing the server and client and then start using it as a drop-in replacement.

It was that easy to get started, and you may not get the full security benefit, but even with this tiny effort in getting started you got much better security than the old scheme.

There is an additional reason why ssh was so successful in replacing the older alternatives, that was that ssh also added some useful new features. And features which run as the user you log in as - after you have authenticated - cannot as easily have exploitable security problems. So even with those added features, security was better than what it replaced.

Re:Tip from a programmer

[kasperd]

And worse, there is no working signature authority _available_ for SSH host keys. This makes spoofing an SSH server for new users much simpler.

In many cases communicating the host public key out-of-band is simpler and more secure than using a certificate. Consider what happens in those cases where an SSL certificate is considered too much work or too expensive. Sites go with http instead. If the out-of-band communication of an ssh host key is too much work, you still go with ssh, you just trust the key exchanged the first time around. That may not give perfect security but it is still better than the completely unprotected communication channel. With ssh you get the additional benefit of the client remembering the key as well as simple to configure key based authentication. If the server is spoofed when the client uses key based authentication, the attacker does not learn any password or secret key. And though the attack may go undetected at first, it won't go undetected forever.

Also it isn't entirely true that there isn't any authority available for ssh. You could make use of RFC 4255 or RFC 6187.

And most envornmnets are not careful to tie the SSH private keys to a specific exposed server or service: they wind up resetting the host keys when they rebuild the host, and pay no attention to a client's confusion about changing keys.

When sysadmins pull such a stunt, users need to tell them to go fix it. If they have no other way to fix it, they need to communicate the new public key to the users in a secure fashion.

Sysadmins and IT supporters convincing users that some insecure practice is acceptable is probably the largest IT security threat we are facing today. Everybody who see that happening need to fight it.

An IT supporter may very well be saving a minute every now and then due to ignoring security. We need enough users giving those IT supporters a hard time, when they pull such a trick, that it isn't worthwhile to ignore security in the first place.

Re:Tip from a programmer

[Antique Geekmeister]

> Also it isn't entirely true that there isn't any authority available for ssh. You could make use of RFC 4255 or RFC 6187.

Neither were part of the original RFC specifications, and neither work in most production SSH clients. I'm afraid that I've not seen anyone actually use the DNS published signatures for SSH keys in the 8 years since RFC 4255 was published, and most clients have no capability for it. RFC 6187 seems to have been roundly rejected by the OpenSSH developers, who came up with their own signature technology that no other SSH client seems compatible with and is not easily backported to previous OpenSSH releases. And again, I've seen no corporate, educational, or private institutions even trying either technology.

I agree that it's problematic: secure handling of credentials is a very, very sore point in many IT organizations, and many groups ignore good practices because they "trust the people they work with" and "if they're on our network, we have much worse problems". Or they sign extensive security policies and then simply ignore them.

Re:Tip from a programmer

[EvanED]

For all we know by now it's possible and not implausible to assume that MITM attacks are conducted routinely by various intelligence agencies across the world.

Better than MITM attacks being conducted routinely by anyone who can set up a wi-fi access point.

Use physically delivered security tokens (such as encrypted random data on a USB stick)

I'll be sure to order one for my (non-AWS, just to be clear) Amazon account right away. </sarcasm>

Re:Tip from a programmer

[EvanED]

I didn't say they provide a silver bullet. In fact I pretty much explicitly said they aren't a silver bullet: "CAs are far from perfect."

What I said they're a hell of a lot better than nothing.

Re:Tip from a programmer

[EvanED]

[TOFU] prevents the kinds of attacks that actually matter, while ignoring the kinds of attacks that look great on paper but aren't really a big deal in practice.

If HTTPS used TOFU, it would mean that if I wanted to connect to some high-value site on a device that hadn't visited it before, I couldn't do it on a network that I didn't at least kind of trust. Traveling? Sucks to be you if you need to contact your bank on a relatively new laptop.

TOFU and CAs do have some interesting security tradeoffs, but I definitely disagree that "TOFU is far superior to CAs". For typical HTTPS browsing situations, I think CAs provide the better set of tradeoffs.

Re:Tip from a programmer

[EvanED]

... the CA system doesn't help in this scenario, as the MITM is likely to negate the redirect to SSL in the first place, and to just keep the user in plain http.

I can't speak for most people obviously, but I usually glance at the address bar and make sure it indicates HTTPS when I'm connecting to a high-value site.

Re:Tip from a programmer

[EvanED]

SSH has no certificates, and yet has a higher market share in the shell connection market than SSL has in the http connection market

This is not a particularly fair comparison.

I would say that almost all traffic that goes via SSH/telnet/whatever is reasonably private. In most cases; even if the traffic isn't so private, you're getting a shell connection to another computer! There's only one time I can think of where I've SSH/telnetted to that wasn't private like that, and that's to towel.blinkenlights.nl.

By contrast, a large portion of traffic that goes via HTTP is just generic traffic. If you or I go to slashdot.org, we'll get almost the same thing. That information pretty fundamentally will be present with encryption too. There is some privacy issue in terms of exactly what URL you're going to (e.g. what /. stories you're interested in, potentially what AC comments you make), but for the most part its much less than your typical shell session from a privacy perspective.

The other thing that encryption does from a network infrastructure level is kill caching. That doesn't matter so much for SSH/telnet connections (at least until you start tunneling other stuff across them) because they're probably unique anyway; it does matter for something like Netflix.

Re:Tip from a programmer

[mysidia]

If you control both sides, use your own CA.

Unless you're Apple; you don't control what CAs are trusted by default in Safari, or on the iPhone.

Your best bet is still to shut off validation altogether, don't bother with a valid SSL certificate, and do store a hard-coded public key in your app, instead.

Re:Tip from a programmer

[IamTheRealMike]

Fail. SSH has been researched and discovered to not work.

We monitored SSH logs to analyze user behavior when our system adminis- trators changed the SSH host key on a popular server within our department. The server’s public key had remained static for over two years and thus expected to be installed at most user’s machines. Over 70 users attempted to login over the server after the key change during the monitored period. We found that less than 10% of the users asked the administrators if there was a key change and none verified the actual key.

SSL is a hell of a lot better at stopping MITM attacks than anything else humanity has created. Certainly SSH does not even qualify.

Re:Tip from a programmer

[IamTheRealMike]

You realise you can do key pinning in SSL as well, right? The point of certificates is to let you find out a public key when you don't have advance knowledge. Certainly for mobile apps, there's no requirement that the app trusts any CA.

Re:Tip from a programmer

[IamTheRealMike]

HSTS is designed to solve the problem of people not requesting encrypted sites.

Re:Tip from a programmer

[IamTheRealMike]

The problem is CAs get suberted all the time into issuing certs they shouldn't issue.

Can you please prove this? Unless you're using a very flexible definition of "all the time", there is no publicly known evidence for this point of view. There are millions of certificates in the world and the number of bad certs is low enough that people can enumerate all the compromises on wiki pages.

Re:Tip from a programmer

[LordLimecat]

*Cough* Nonsense. What happened to Comodo? [youtube.com] After they were compromised 3 times and issued numerous false certificates?

That was a long time ago, and SSL threat mitigation has been stepped up a LOT recently. A better example would be DigiNotar, which was revoked following its breach 2 years ago.

Re:Tip from a programmer

[cbhacking]

This is an app, not a browser. There *IS* no "yes" to click in an app. Cert not valid? Connection closed, user gets "connection is probably being tampered with" error message. No "shoot self in foot" option is needed, because the same developer owns both the client and the server.

Sigh... the sheer amount of stupidity (mostly in the form of people trying to ack like they know what they're talking about) in this thread is painful!

Re:Tip from a programmer

[cbhacking]

So... mobile apps aren't a real-world scenario? You know, where cert pinning is used *all the time* because the same developer provides both client and server? You know, the entire context of this discussion?

Do you even *try* and think before posting bullshit on the Internet?

By the way, it is entirely possible to implement public key TOFU in browsers. It's called HTTP Public Key Pinning. Chrome is already supporting it, I believe. It could also be achieved through browser extension/plugin pretty easily.

Re:Tip from a programmer

[cbhacking]

You are an idiot, and dragging down the collective intelligence of this entire thread. Just for your information, in case you weren't yet aware...

IT IS A MOBILE APP! The developers *DO* control what CAs are trusted by the app. In fact, they do it through *exactly* the same mechanism as turning off cert validation entirely: they implement a custom validator function, instead of having the app use the platform's built-in validation.They can control the CA that is trusted. They can pin the certificates (or just the public key, in case they want to re-issue the certificate with different details but keep the pinning). They can implement a backup pin. They don't even need to check the CA chain of trust; they could use a self-signed cert if they wanted to and just make sure it is the one the app expects.

Hard-coding the public key comes *close* to being correct, while simultaneously completely missing the mark. What if the private key becomes compromised and needs to be rotated? What if you want to rotate it anyhow, just as a defensive measure? What if you want to switch to a stronger key? What if an attacker steals the key and starts using it to intercept traffic, and the app has no way to check for revocation?

Seriously, you are - much like un-validated encryption - worse than useless. You post like you know what you're talking about, and yet obviously do not.

Re:Tip from a programmer

[cbhacking]

E can't prove it, no. Because it's bullshit. Don't get me wrong, CAs as a single point of failure is stupid. Trusting *all* CAs for any given connection is also stupid. On the hand, trusting any random certificate is much, much stupider. There are solutions for the problems with the CA system...

The obvious one, in the case of mobile apps, is certificate pinning. That's not a new idea, or even terribly hard to implement. Make sure you pin a backup as well, and if you want to you can pin at the intermediate CA level rather than at the host cert level (handy if you want to rotate host certs, or if different hosts have different certs for some reason). Don't turn off validation, though. In fact, turn on things like CRL checking and so on if they're disabled by default.

For other situations, there are alternative trust models. HTTP Public Key Pinning gives trust-on-first-use, for example, and can even be implemented client-side without server support if you're willing to accept the risk that the server will change certs for completely legit reasons. Web-of-trust isn't hugely practical in something like the web, but works fine for email and the like where you usually have other methods of communication with the people you're talking to. Secure Remote Password has a bootstrapping problem, but once you're past that it provides another method for secure authentication and key exchange.

Re:Tip from a programmer

[pop ebp]

Always turn off SSL validation, because it's totally worthless.

Yeah, because if a sufficiently motivated person can always pick a lock, we should just remove all locks?

With certificate validation, someone will have to compromise a CA (admittedly, any trusted CA will do) and do a MITM to get your data. Without certificate validation, anyone who can do a MITM can get your data.

And you seem to think that the difficulty of pulling a MITM attack is about the same as compromising a CA. It is not: Just set up a rogue Wi-Fi hotspot in a cafe or other public place and wait for people to connect. Then, there are off-the-shelf software for sniffing SSL data using rogue certificates generated on the fly (which would now be accepted since your turned off validation) See: Are MITM attacks extremely rare?

I agree that the chances of you getting actually MITM-ed on your typical connection are pretty slim, but then the chances of getting eavesdropped are pretty slim too, so why are you still advocating to use SSL then? (I assume you are because otherwise it doesn't make sense to say "turn off validation") And I would argue that if you can do passive eavesdropping and you are not actually one of the endpoints, you probably already control a node in the middle, and already well-positioned to do an MITM.

But yes, the CA system definitely has its flaws and can't keep up with some new attacks. There are several projects trying to fix this part of SSL. But I find it interesting that instead of proposing a solution, you are effectively proposing that we turn off all security.

Re:Tip from a programmer

[kasperd]

Certificate pinning is not possible in any real-world scenario. The problem is that certificates change too often.

There is a fairly simple fix for that, but it requires a bit of standardization. The idea is simply to not only have a certificate chain from a CA to the server certificate, but also have a secondary chain going through the server certificates over time. If the client has already stored a previous certificate, the server need to provide a chain from that old certificate to the new certificate.

Re:Tip from a programmer

[David Jao]

Mobile apps can and do use key pinning, but certificates are not necessary for that. They can just pin individual self-signed public keys. For that matter, they don't even need SSL; they could just use SSH.

It's possible, but useless, to implemet public-key TOFU in web browsers. Almost all web sites rotate keys too fast for the pin to be useful.

Re:Tip from a programmer

[David Jao]

Yeah great. This kind of SSH compromise requires a targeted attack, and will only work on that one server. By contrast, with SSL, a single DigiNotar stunt allows you to attack thousands of servers and millions of users all at once. See the difference? SSL is great in theory, horrible in practice. Anyone claiming otherwise is willfully blind of real-world considerations. This includes most cryptography researchers.

Re:Tip from a programmer

[mysidia]

You are just an imbecile who can't even spell Ad Hominem, let alone remember that an attack against the person does not form a sound argument.

They don't even need to check the CA chain of trust

Then they are not implementing SSL Certificate validation. They are implementing a custom validation scheme. IF they are implementing a custom validation scheme, they may as well implement one that is as SIMPLE as possible, and as SPECIFIC to their application as possible, so it is least likely to be vulnerable to unexpected attacks.

They can control the CA that is trusted.

This is complicated, and likely to result in security errors. There is also the problem that even the "trusted" CA can be compromised. From a security perspective, this is much riskier than just hard coding a single public key.

What if the private key becomes compromised and needs to be rotated?

What If. What if.... You dolt. It's just the same as if a CA key becomes compromised. Publish a security update to the app.

They can implement a backup pin.

AGAIN... with you. More keys that can be attacked, compromised, or guessed. I thought you were trying to PREVENT a covert MITM, not to facilitate one.

What if an attacker steals the key and starts using it to intercept traffic, and the app has no way to check for revocation?

There is an easy way to check revokation --- client or server-side version checks warning the user that their version is out of date and there are security issues.

Seriously, you are - much like un-validated encryption - worse than useless.

Unvalidated encryption is good enough to stop the NSA and 99% of eavesdrop attackers who will be stopped by Validated encryption.

You post like you know what you're talking about, and yet obviously do not.

Well, actually, You: cbhacking do.

Re:Tip from a programmer

[Antique Geekmeister]

Nice name calling. It doesn't support your argument, though. Let me go back to your original statement.

> > There exists an extremely widely-used crypto protocol which uses no certificate validation and yet prevents almost all MITM attacks.

"Almost all MITM attacks" is the phrase you used. Many MITM attacks do, indeed, rely on stolen or legitimately obtained copies of the server encryption keys, so please don't claim that SSH is immune from "almost all MITM attacks". And I just showed where the current lack of signatures for SSH private host keys make such attacks very easy indeed.

The need for a targeted attack that you mention is real. But, so what? If you're doing a MITM against a banking or e-commerce site, _of course_ you're going to target them. As it stands, SSH doesn't _buy_ you anything compared using SSL without key verification altogether, and that's demonstrably _worse_ than the current status with SSL.

Re:Tip from a programmer

[David Jao]

Your argument remains completely nonsensical for one very basic and unavoidable reason: SSL is also equally vulnerable to stolen keys. There is no way in which SSH is worse than SSL.

Of the MITM attacks against SSL actually deployed in the wild, what proportion rely on stolen keys compared to compromised certs? Answer that question, and you'll see that my "most attacks" claim is fully valid.

Re:Tip from a programmer

[David Jao]

Another point that you missed completely is that your targeting assumption is wrong. If you're doing a MITM against a banking site, you DON'T need to target them. Not with SSL. You can compromise instead any one of the thousands of certificate authorities in the world. Any single successful compromise of any of these unrelated third parties gives you free rein to MITM any banking site in the world. From the point of view of the server administrator, this is absolutely insane. No matter how good my own security is, an attacker can MITM me by compromising any single one of any of thousands of unrelated CAs, 99.99% of which I as a server administrator have never done business with. At least with SSH if my own server keys get compromised it's my own damn fault. Not so with SSL.

Re:Tip from a programmer

[Lennie]

"Unvalidated encryption is good enough to stop the NSA and 99% of eavesdrop attackers who will be stopped by Validated encryption."

If you think you still life in a world with only passive attackers, then you would be wrong.

You'd think Firesheep has demonstrated that more than enough now.

Re:Tip from a programmer

[Antique Geekmeister]

> SSL is also equally vulnerable to stolen keys. There is no way in which SSH is worse than SSL.

I'm pointing out a real attack vector for Man-In-The-Middle attacks, which you seemed to think was impossible for SSH. I didn't say it was worse: I'm pointing out that it's still vulnerable.

> Of the MITM attacks against SSL actually deployed in the wild, what proportion rely on stolen keys compared to compromised certs

Since so many MITM attacks are actually performed by institutions against their own users, using the company's own SSL keys on their own proxy servers or routers, I'm afraid it depends on whether you call those keys "stolen". I'd be willing to call them stolen: I'm afraid that most web site owners are not fully aware of the vulnerability they face when they share the key to ease load balancer or proxy access, or when they order private keys through their corporate IT department.

Re:Tip from a programmer

[mysidia]

Yeah, because if a sufficiently motivated person can always pick a lock, we should just remove all locks?

No... SSL encryption is the lock. Authenticity is supposed to be the anti-pick mechanism. I suggest not using the anti-pick mechanism called "CA based certificate validation" that comes with SSL. I mentioned there are better options available, such as hard coding good public keys on the client side.

But you have to throw away SSL certificate validation, before you can implement good crypto practices, because of the fact that SSL doesn't use good practices.

Also... while throwing away bad crypto; perhaps a good opportunity to stream encrypt your data with AES256 using Encrypt-then-MAC, rather than SSL/TLS's flawwed and weak Mac-then-Encrypt approach.

With certificate validation, someone will have to compromise a CA (admittedly, any trusted CA will do) and do a MITM to get your data. Without certificate validation, anyone who can do a MITM can get your data.

There are enough holes in the CA system and SSL certificate verification within SSL software frameworks and libraries that anyone who can do a MITM will most likely have little trouble compromising a CA or other point in the validation chain. We know that in practice it is rare that anyone even knows the theory behind executing a MITM attack, let alone the ability to pull off SSL MITM.

Re:Tip from a programmer

[rsclient]

OK, I'm a little late to the party here. The issue with the apps isn't that "SSL is insecure" or that "SSH is better". The problem is: most security APIs require multiple levels of APIs to work correctly, where each level is hard to get right, and easy to get wrong.

Worse, a substantial number of apps will turn off one level or another "for debugging" and then not turn them back on for their release version.

Re:Tip from a programmer

[hobarrera]

you're under some kind of deadline pressure and you can't connect to them, don't turn off SSL validation.

OR: Always turn off SSL validation, because it's totally worthless.

The problem is CAs get suberted all the time into issuing certs they shouldn't issue.

You're asuming that they're using a third-party CA, and using the same pool of CAs browsers use to validate.

In truth, when developing applications, you don't need that. If I were to make an application and server right now, I'd use my own CA certificate. I'd then bundle it with my application, and sign the server certificate with it. TLS validation will mean TRUE security in this case.

Re:Tip from a programmer

[Anonymous Coward]

If you can get a CA to validate you as Bank of America, you still need to poison DNS to get browsers pointing to your proxy. Or start sending out phishing emails.

If it were as easy as you claim, it would happen every fucking day, but it doesn't.

Re:Tip from a programmer

[vilanye]

Name calling != ad hominem

Self-policing doesn't work

[uCallHimDrJ0NES]

I have a hard time believe the FTC will follow through with reviewing and verifying the contents of these security audits. This is a non-punishment. Not even a slap on the wrist. They should have gone for a stiff monetary fine. That said, I don't know how likely such an outcome would have been for the FTC. However, fining till it hurts is the only thing I am certain businesses will respond to.

Re:Self-policing doesn't work

[ShaunC]

I have a hard time believe the FTC will follow through with reviewing and verifying the contents of these security audits.

They probably aren't planning to, and won't need to. Credit Karma will set up a new corporate entity like "Karma New Holdings LLC," transfer all assets including the domain, customers, and brand, and keep on truckin'. Hell it's probably already been done. Assuming the FTC ever does call them up two years from now, the entity which received sanctions will conveniently no longer exist.

Re:Self-policing doesn't work

[greylion3]

Credit Karma will set up a new corporate entity like "Karma New Holdings LLC," transfer all assets

.. unless the settlement specifically prohibits them from doing so.

No coupon settlement?

[hawguy]

I'm surprised they didn't go with the typical million dollar settlement payable entirely in 75 cent coupons sent to every customer. I guess that only happens in class action lawsuits.

What about Apple?

[Anonymous Coward]

They weren't validating SSL for the last TWO YEARS:

http://www.macworld.com/articl...

Most sanctions are are form of revenge

[TapeCutter]

This one is real justice, particularly if they have to foot the bill for the regular audits, something they should have been doing in the first place. Just because a PHB makes the moronic decision to "bend the truth" does not mean everyone else in the company should suffer a loss of employment.

PHB - Actually it sounds more like a geek "technical argument" to me - "Supports SSL" is open to creative interpretation when a deadline is looming.

Incidentally Microsoft include a disclaimer on third party stuff that goes something like. "...supports Berkley Sockets, for the parts of Berkley Sockets that are implemented". Which is a weasel's way of saying "not be fully implemented".

Original article is a bit misleading....

[alphad0g]

"However, the app didn’t validate those connections, so users’ financial information was exposed during transmission." - This is false, the channel was still encrypted, but it is possible for an MTM attack to occur. Now if the client knows who it is talking too (IP Address) with some messages exchanged in the application layer, then SSL verification may not be needed. The real purpose of SSL cert validation is to authenticate who you are talking too - if you know you want to talk to server 10.10.10.10, then someone would have to subvert the routing protocols to intervene. And even with Cert validation, there are ways to conduct a MTM attack if that is turned on - NG firewalls and other SSL decryption corporate tools do it all the time if the users machine or phone has a custom issuing cert installed.

Re:Original article is a bit misleading....

[DarwinSurvivor]

"However, the app didn’t validate those connections, so users’ financial information was exposed during transmission." - This is false, the channel was still encrypted, but it is possible for an MTM attack to occur. Now if the client knows who it is talking too (IP Address) with some messages exchanged in the application layer, then SSL verification may not be needed.

No. If your verification is done on a separate layer from your encryption, then you are doing it wrong. This in no way prevents a MITM attack at all. All you need to do is get between them (wifi, arp poison, dns redirect, etc), MITM the ssl, then you can pass the "verification" right through while reading all of the "encrypted" information as it passes. You can also wait for the verification to succeed, then start screwing with the data because the verification is not connected to the encryption (which is also your integrity validation).

The real purpose of SSL cert validation is to authenticate who you are talking too - if you know you want to talk to server 10.10.10.10, then someone would have to subvert the routing protocols to intervene.

Subverting is easy if you are on the same lan as them (public internet, business LAN, separate infected machine in their home, etc). How many people use their banking apps at public access points because their data plan is too expensive so they set LAN to "auto"?

And even with Cert validation, there are ways to conduct a MTM attack if that is turned on - NG firewalls and other SSL decryption corporate tools do it all the time if the users machine or phone has a custom issuing cert installed.

Riiiight, because secretly installing a 3rd party certificate on someone else's PHONE is easier than arp poisoning the wifi at McDonald's.

20 Years?

[cosm]

I'm not defending these companies, but in internet time we'll all be floating heads in jars connected to the singularity hyperspace flux capacitor continuum gravimatrix in 20 years.

Re:20 Years?

[techno-vampire]

I can remember people saying the same thing 20 years ago and it hasn't happened. And, I expect to be making the same kind of comment 20 years from now as well.

That'll teach them....

[Anonymous Coward]

Weak.

The next 20 years?

[Cthefuture]

I can guarantee you that none of these companies will be in business in 20 years.

What about Apple?

[cnkurzke]

Where basically any app relying on the OS for SSL got duped?

The real problem is with the X.509 certificate aut

[Anonymous Coward]

The real problem is getting the X.509 certs from a dev/testing prospective and keeping them maintained from a live prospective. It's a real pain in the ass dealing with third parties for this stuff. Most devs will either not understand how to implement it properly, or just fail to use it because its a headache!

yes is this

[Anonymous Coward]

http://full-hd-film-izle.net/

Re:The real problem is with the X.509 certificate

[cbhacking]

There are so, so many ways around this. A simple one, for example, is to only perform certificate validation past a date in the future when you will have the cert ready for testing (ideally shortly before publication). That's an easy check to perform in a custom validation function (which happens to be the same way you turn validation *off*, in most cases, so it's a truly trivial amount of extra effort). Or you can have the validation disabled in debug builds, but enabled for any "release" build (including the final pre-release tests). Or you can pin a given certificate (might even be a self-signed one) and not worry about the CAs at all. Or you can do some combination of the above.

Any of them are better than just being lazy and insecure.