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.
Verisign, Comodo, Digicert and Thawte are running their websites with self-signed certificates. pic.twitter.com/1rtklJZlWX
— @mikko (@mikko) February 13, 2014
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.[ref]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![/ref]
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.
