Flutterby™! : Abolish SSH CAs 2011-08-31 21:21:03.153708+00

Abolish SSH CAs

2011-08-31 21:21:03.153708+00 by Dan Lyke 14 comments

Upon 2020: It’s Time To Abolish SSL Certificate Authorities.

Yeah, but at some point... I was talking with a guy who's CTO for a company doing transaction pattern based fraud detection for financial organizations a few weeks ago, and he was currently looking at Windows based exploit-in-the-browser attacks. If you banked at one financial institution and had fallen prey to this particular virus, IE would always show your bank account as having some pre-determined amount while it was silently debiting from the account in the background.

The guy who discovered this did so when his daughter came in to town to visit, used his computer to check her bank account, and thought she'd gotten a windfall.

So, yes, there are always exploits, but there are geographically distributed friends I'd put in my web of trust, and when one of them posts a Facebook status saying "I just made $3000 without leaving my home, just click on [elided]", I can drop their trust rating just a little bit.

The only issue I see with this is that, with the potential value of subverting a financial institution's security, it may be worthwhile investing in an insertion attack, displacing enough "notaries" to gain access.

It's sounding more and more like the solution is some sort of user relative DNS, where the users are asked to pick and choose their trust roots, and there's some balkanization of the domain name space. This would also allow the resulting system to route around censorship attempts, but...

The problem is with the browser vendors. Pay them and they include your root and implicitly tell their users to trust you. Don't pay them and they don't include your root and explicitly tell their users to distrust you. As far as I know they do no checking.

We are left with the odd situation that every so often someone tries to https to a .mil site, gets a warning from her browser that she shouldn't trust this site, points to the .mil and giggles. DoD actually does seriously check the identities of the people/organizations to whom it issues certificates, but it doesn't pay the browser companies.

But Dinotar (sp?) which apparently did no checking at all of the identity of the entity to which it issued a certificate as "google.com"(!)? It paid its fee, so Firefox said it was trustworthy.

Hmmm... Gotta think about this more, but there has to be a fairly easy way to coalesce the CAs with the domain registrars, to limit the potential points of failure, and to remove the false sense of security that the current system instills.

Then your DNS provider would either have to cache keys for every SSL site, with the potential for insertion attacks.

If you have a signature for the DNS provider, then, yes, the DNS provider is a single point of failure, but you could get a server signature from the same place you get your DNS, with equivalent security to getting that information from a CA.

Yup, except with a MITM attack the network itself has been modified and the server you're talking with at a particular IP address is owned by the attacker. (A DNS insertion attack is not a MITM attack.) Without having an encryption key for that server beforehand, or some way of assuring that the key it sends you is legitimate (signed by a trusted source using its private key), you have no way to verify your connection.

I suppose your bank could send you a key fingerprint in the mail, that'd work fairly well, but if they had to change the key in a hurry you might have a problem.

The vulnerability in this case is a matter of having so many independent points of failure. Having a gazillion CAs in your chain of trust doesn't enhance security.

And it means that the CA isn't really adding any value: Nobody cares that there's a verified phone number or whatever associated with that domain name, the question is if that server is associated with the domain name you typed in.

Map that down to "This server has this identity", served from the DNS provider with a chain of trust there and we have a better situation than we have now.

For private stuff (internal to a network) we just run private CA's and certs. With client browser certificates for everyone that SHOULD access the system.

I would like to see an option for my online banking that does the same: They issue me a unique SSL Certificate signed by them.

I'm pretty sure DNSSEC has similar vulnerabilities, and DNSSEC + SSL w/o a certificate does not protect you against a MITM attack.

In practice, when I go to a site I'm not checking on the details of the cert, I'm just wanting to know that gmail.com goes to the same gmail.com that it went to last time, or that my bank's domain name is really resolving to my bank's server, and that the communication between me and them is encrypted.

Adding third-party CAs to the process just introduces another opening for error.