SSL and the Future of Authenticity

An anonymous reader writes "There has been a growing tide of support for replacing SSL's Certificate Authorities with an alternative authentication mechanism. Moxie Marlinspike, the security researcher who has repeatedly published attacks against SSL, has written an in-depth piece about the questions we should be asking as we move forward, and urges strong caution about adopting DNSSEC for this task."

Comments

The main issue

[dev.null.matt]

It seems like the real problem is that any good solution to this issue will, by necessity, require the user to make informed decisions about who to trust and who to not trust. Based on the state of non-technical scamming, the success of confidence men throughout history and the fact that most people just want their browser to take them to whatever is linked off their friends' facebook pages, I can't see that this will ever be resolved.I mean, unless we decide to trust some body to make these decisions for people. Unfortunately, that pretty much brings us back to our current problem.

That's the main problem I see with the author's notion of "trust agility:... it requires action from Joe Sixpack users who just want their browser to work in the same way their TV does.

Re:The main issue

[increment1]

There is a reasonably straight forward technical solution, that could be implemented in a future SSL protocol, to resolve the issue of trust when you already have an account on a site. A host site can add the hash of your password to the symmetric key used after the key exchange, your browser can then do the same on your side. This is essentially using a a shared secret (the hash of your password) as part of the symmetric key. The result is that no one in the middle can intercept your communication even if they have compromised the certificate.

Since most attacks are done on people who already have accounts, this is a decent improvement in security. It will not, however, prevent spoofing a site before you have an account on it, so extra precaution would need to be taken.

The implementation of this protocol would require that when initiating an https session with the server, you need to input your account credentials to your browser (not posted to the host), which then uses them to establish the SSL session.

Re:RTFA

[Burdell]

I RTFAd, and a few things jump out at me:

- Attacking GoDaddy's trust because Bob Parsons went hunting in Africa to help farmers. Way to bring politics into a supposed technical discussion.

- Confusing management of the DNS root with domain takedowns done at the registrar level.

- Repeated use of "forever", as if certificates don't expire (and protocols never change).

I think DNSSEC could be used to augment SSL security. For example, sites could list valid key IDs in a DNSSEC-signed record. You still use CA-signed certs, but a rogue CA can't also edit your DNSSEC-signed record. It is also much easier to monitor DNS for somebody trying to change something.

Chain of Trust is Good, Penalty for Encryption Bad

[inglorion_on_the_net]

I don't have a big problem with the way the chain of trust works. I have software on my computer that allows me to manage the certificates that I trust. That way, I can decide for myself. Since I don't actually want to bother to do so, I defer to my operating system vendor's judgment. They provide a package containing a list of trusted certificates, which I then use. I can have as much or as little control as I want. I think this is a good system.

What I do have a problem with is the fact that many applications will use cleartext connections without complaint, but give ominous warnings when using TLS with self-signed certificates. Sure, self-signed certificates don't provide authentication, but neither do clear connections. With TLS, at least I get encryption. This should be a step up in security. At the very least, security is no worse than without TLS.

I am OK with a warning being shown the first time I connect to a service with a non-trusted SSL certificate, but I feel applications should take a page from SSH here: give a warning that isn't too ominous, and offer the chance to save the public key. Then, next time I connect, if the key matches, go right ahead without a warning. And shout if the key does not match. This should provide good security if the first contact is uncompromised. Importantly, it matches the scariness of the warnings with the risk of the situation.

Minimum standards for CA Relying Party Agreements

[Animats]

Certificate Authorities issue "Relying Party Agreements", which specify their obligations to users relying on their certificates. Some of these specify financial penalties payable to end users.Over the years, as with EULAs, these have been made so favorable to the CAs as to make them meaningless. (See, for example, Verisign's relying party agreement. Or, worse, the one from Starfield, GoDaddy's CA.)

Now it's time to push back.

The Mozilla Foundation should issue a tough standard for CA Relying Party Agreements to get a root cert into Mozilla. One that makes CA's financially responsible for false certs they issue, with a minimum liability limit of at least $100,000. The CA must be required to post a bond. A third party consumer-oriented organization like BEUC (in the EU) or Consumer's Union (in the US), not the CA, must decide claims.

The technology behind SSL is fine. The problem is allowing CA's that aren't doing due diligence on their customers to have root certificates in major browsers. Mozilla all by itself has enough power to tighten up standards in this area. All it takes is the will.