Flutterby™! : Abolish SSH CAs

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

Abolish SSH CAs

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

comments in descending chronological order (reverse):

#Comment Re: made: 2011-09-08 15:55:29.602142+00 by: Dan Lyke

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.

#Comment Re: made: 2011-09-08 15:23:49.9862+00 by: TheSHAD0W

Re the above: http://tech.slashdot.org/story...s-Solution-To-the-SSL-CA-Problem

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.

#Comment Re: made: 2011-09-04 23:44:22.427188+00 by: spc476

There's an approach outlined in this BlackHat presentation: http://www.youtube.com/watch?v=Z7Wl2FW2TcA

#Comment Re: made: 2011-09-03 20:12:15.412687+00 by: Dan Lyke

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

#Comment Re: made: 2011-09-03 20:04:40.351253+00 by: jim moody

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.

#Comment Re: made: 2011-09-02 01:49:05.825686+00 by: Dan Lyke

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.

#Comment Re: made: 2011-09-02 01:07:23.829226+00 by: TheSHAD0W

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

#Comment Re: made: 2011-09-01 16:43:52.84762+00 by: Dan Lyke

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.

#Comment Re: made: 2011-09-01 15:47:56.885909+00 by: TheSHAD0W

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.

#Comment Re: made: 2011-09-01 14:06:59.605356+00 by: Dan Lyke

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.

So, if anything, all the CAs are reducing value.

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.

#Comment Re: made: 2011-09-01 13:10:41.602812+00 by: meuon

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.

#Comment Re: made: 2011-09-01 11:59:55.070695+00 by: TheSHAD0W

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

#Comment Re: made: 2011-09-01 00:04:35.706929+00 by: Dan Lyke

A crypto sound DNS and the SSL layer checking against that.

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.

#Comment Re: made: 2011-08-31 23:29:26.178202+00 by: TheSHAD0W

And replace them with... ?