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

[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

[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

[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

[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

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

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]

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]

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.

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.

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.

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.