SSL and the Future of Authenticity 98
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."
The CAKE protocol (Score:4, Interesting)
This, Diaspora, and personal interest by friends have gotten me interested in working on The CAKE Protocol [cakem.net] again. My goal is a Python reference implementation that can speak over TCP, email, and possibly IM.
Last time I stalled out once I got a job. I also realized that the protocol design was flawed, and the API design for the internals was awkward. Also, I was all alone in a new city. I have friends who are interested now, which makes it easier. And maker spaces with people to talk to. When you have to work on something all by yourself it's hard to stay motivated.
Re:RTFA (Score:5, Interesting)
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.
Self-signed certs + notaries? (Score:4, Interesting)
Why not switch to self-signed certs + a notary system like Perspectives? [networknotary.org] It would at least be an improvement on today's situation, since there would be no need for CAs and there would be some MITM prevention built into the system.
Minimum standards for CA Relying Party Agreements (Score:5, Interesting)
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. [thawte.com] Or, worse, the one from Starfield, GoDaddy's CA. [godaddy.com])
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.
Re:The main issue (Score:4, Interesting)
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.