Democratizing SSL Certificates

You’re not reading this site over SSL.  That means anyone else on the network can see not only the domain you’re browsing but the page you’re reading.  If you submit a search or a contact form here, your request will be sent to my server in plain text for all the world to see.

Hopefully, you’re OK with that.

On some sites, however, this can be a major security issue.  Sensitive files might be hosted on the domain – files with names you don’t want exposed.  You might be posting private information – like credit card data – to the server for processing.  The server might be transferring data to you and you want to be sure you’re the only one who can read it.

This is why important websites use SSL – secure socket layers – to encrypt traffic between the client (your browser) and the server.

Again, you’re not reading this site over SSL, not because I don’t value SSL, but because I don’t want to pay a 3rd party to sign my certificate.

The System is Broken

Currently, you have to shell out cash to one of a handful of large corporations to get them to sign your SSL certificate, otherwise browsers display an “I don’t know who this is” message to your visitors.  Typically, this isn’t a bad thing, except most of your visitors won’t understand the message and will think you’ve been hacked.

Ironically, most of the big players sign their own certificates.  If you or I were to do that, browsers would flag things and alert the user that something’s amiss.

These trusted authorities are hard-coded into your browser software – Chrome, Firefox, Internet Explorer, Safari, etc all trust them by default, even when things go wrong and rogue certificates are issued.  There’s no way to prevent a hack in such a situation without a browser update – again, not many visitors will understand this or update their browsers to prevent a fix.

We live in a world where software – particularly open source software – is democratizing more and more of the web.  Publishing is open.  Even hosting these tools is inexpensive. 1

So long as certificate security remains in the hands of large corporate conglomerates, it will never be as open as the tools it purports to protect.

Patches Welcome

I propose a simple change to the above paradigm: peer-to-peer trust.

I don’t know you.  You don’t know me.  However we both know Sam.  I trust Sam; Sam trusts me.  You trust Sam; Sam trusts me.  By extension (because Sam will vouch for me), you can trust me.

It’s a simple extension of the above system – you elevate individuals (or companies) whom you trust to the same level as the larger certificate authorities I already discussed.  Smaller entities become capable of signing peers’ certificates (likely in exchange for those same peers signing their certificates in turn) and visitors who trust these entities know they can trust those entities’ peers as well.

Much of the infrastructure we currently use for SSL certificate verification today could be reused for these purposes – it would just need to be extended a bit.  For example, to allow more than one “hop” to reach verification: I know Sam – Sam knows Tom – you know Tom – you can trust me through your trust of Tom, Tom’s trust of Sam, and Sam’s trust of me.

Benefits and Drawbacks

The biggest benefit is a decentralization of certificate security.  By running certificates through multiple verification nodes instead of a handful of monolithic entities, the system becomes inherently more sturdy in the face of attack: failure of one node or another has far less of an impact on the network as a whole than, say, failure of Comodo.

The drawback is that this system remains to be built and, until an adequate prototype exists, it’s hard to know for sure the impact of the failure of any given node.  Rogue nodes are sure to arise – but once detected the network could, in a sense, self-heal and notify other nodes of the failure and dynamically revoke trust.

This would necessarily be a very dynamic system and, once launched, will be very difficult to reel back in.  I’d like to fully understand the potential downsides of such a change before prototyping anything – that said, this feels like the right solution.

I have an easier time trusting individuals and corporations I personally know than large companies with whom my only relationship is as a certificate vendor.  I’m also a huge proponent of democratizing both publishing on the Internet and the Internet itself.

If you agree, I’d like to hear it – and other potential benefits you see with such a system.  If you disagree, I’d like to hear it – and any potential drawbacks you see with such a system.

I want to democratize security, and I need your help to do it.

Notes:

  1. I host one of my sites on a $5/month VPS. That’s less than I paid for crappy shared hosting when I first started online!

Comments

  1. says

    I actually don’t think that the problem with SSL authentication is due to there only being a handful of root CAs — there are actually too many! Since SSL was not developed with the thought of a malicious CA (and authentication was really an afterthought), there is nothing built into it to prevent someone from creating a cert at one CA when it already exists on another. You can do this if you control the application through cert pinning (Google does this with Chrome for their web apps), but anyone who does not make their own browser is in a much more difficult position.

    There are in excess of 330 root certificates pushed out by Microsoft and many of these will allow third party “affiliates” to create certificates in their name (see the Comodo breach). Every one of these root CAs can sign for any domain, which could mean >300 certificates can be created which sign for “*.eamann.com” and could be initiated by thousands of organizations. If someone has a valid certificate for your site, they can easily MitM any transmission and listen in without anyone noticing. Oh — and at least one “trusted” CA is owned by the Chinese government and another is owned by the US DoD.

    There have been some proposals for fixing that issue, such as Moxie Marlinspike’s TACK (http://tack.io), as well as a competing method proposed by Google that would allow for certificate pinning. However, they were both proposed in 2012 and I haven’t seen much movement on them since.

    SSL — or more accurately now, TLS — is a huge accident waiting to happen. It’s been straining at the seams for years, with new vulnerabilities being demonstrated every year (BEAST, CRIME, BREACH) and no replacement in sight. I think we will eventually need to have a ground-up re-do before the end of this decade.

    Back to your proposal, it sounds like you’re thinking about applying the PGP “Web of Trust” model to SSL, which is essentially what Moxie Marlinspike is working on with his “Convergence” project (see https://en.wikipedia.org/wiki/Convergence_(SSL) and http://convergence.io/). I happened to see him at Black Hat a couple of years back when he presented this and it is an interesting concept. However, he has not had the best luck with getting mass support for it. Part of the issue is that the CAs do not want to support anything that could threaten their business model.

    • says

      Actually, that is exactly what I’m proposing. I’ll have to look into this existing project; I’m not surprised the CAs don’t want to support it, though :-)

Leave a Reply