The SSL trust model has been with us for many years now and has been the underpinning of the vast majority of the cryptography on the internet. It has protected logins to all manner of websites across the world and for the most part seems to have worked well. We don't generally log on to a 'secure' banking website only to find that the next day an attacker has logged on and accessed to our account.
Cryptography is a chain of systems which starts with a point of trust. In SSL that point of trust is the Certificate Authority (CA). If you don't trust the CA, you don't trust SSL and you don't trust the security of your connection.
The way this works is actually pretty simple. The CA is supposed to only allow the genuine owner and operator of a website to purchase a certificate. If I want to masquerade as Google.com and have SSL connections believe me then I need to find a CA (one which is trusted by the SSL connection client - e.g. your browser) to issue me a certificate saying I am Google.com. If I can do that then assuming I can also get the DNS changed to point to my server I can masquerade as Google.com and nobody knows I am not.
You can see just from this description that it all hinges on trust in the CAs. If they issue certificates to just anyone without thoroughly checking their identity then the entire trust model breaks down and people can easily pretend to be websites they are not, rendering the whole system pretty pointless. Sure you can create an encrypted connection, but to who? If you can't even be sure who you are talking to then keeping the rest of the world out has very limited value.
Cryptography is a chain of systems which starts with a point of trust. In SSL that point of trust is the Certificate Authority (CA). If you don't trust the CA, you don't trust SSL and you don't trust the security of your connection.
The way this works is actually pretty simple. The CA is supposed to only allow the genuine owner and operator of a website to purchase a certificate. If I want to masquerade as Google.com and have SSL connections believe me then I need to find a CA (one which is trusted by the SSL connection client - e.g. your browser) to issue me a certificate saying I am Google.com. If I can do that then assuming I can also get the DNS changed to point to my server I can masquerade as Google.com and nobody knows I am not.
You can see just from this description that it all hinges on trust in the CAs. If they issue certificates to just anyone without thoroughly checking their identity then the entire trust model breaks down and people can easily pretend to be websites they are not, rendering the whole system pretty pointless. Sure you can create an encrypted connection, but to who? If you can't even be sure who you are talking to then keeping the rest of the world out has very limited value.
SSL is broken
The cracks in SSL have been showing for some time though. The DigiNotar hack in 2011 led to fake certificates being created and the hacker claimed that they had had access to other certificate authorities. In many ways this serious failure was papered over and forgotten.
The attack meant that the ability to issue trusted certificates (private keys) was compromised. It doesn't matter which CA is compromised, it only matters that one is. This is enough for all SSL clients to trust your fake certificate.
The correct response to this to maintain SSL's model would have been to thoroughly audit the existing CAs and work out if they had been compromised and then blacklist a range of them so that SSL clients (your browser, email client, phone apps etc etc) would no longer trust those CAs and no longer trust certificates issued by them. Although DigiNotar was blacklisted it isn't clear whether this was enough and remember that just one compromised CA certificate allows you to generate fake certificates for any website.
The recent 'heartbleed' bug in OpenSSL is in some ways much worse. OpenSSL is in use on 60%+ of websites on the internet and the attack allows anyone else on the internet to recover bits of memory from the target server. This has the potential to leak anything - user data, passwords, private keys for the entire secure session, server certificates.
The implications of this failing are huge. Certificates that affected websites are using should be assumed to be compromised. This will mean they will need to go back to the CA to get a new one. So far so bad but it sounds fairly manageable. The problem though is that those compromised certificates could still be used by an attacker to spoof (pretend to be) the attacked website and recover user data, passwords etc. The certificates then need to be blacklisted so that SSL clients (your browser, email client etc) no longer trust them.
The next problem here is that the list is just too big. Every SSL client can't carry a list of 60% of the sites on the internet. Just for practical purposes the blacklisting needs to be done at a higher level - at the CA level. Rather than just seeing DigiNotar get blacklisted we could see every CA get blacklisted.
Even the CAs at the very top issue end user certificates and will likely have issued enough that they couldn't just be included in a blacklist, so they themselves must be blacklisted.
The attack meant that the ability to issue trusted certificates (private keys) was compromised. It doesn't matter which CA is compromised, it only matters that one is. This is enough for all SSL clients to trust your fake certificate.
The correct response to this to maintain SSL's model would have been to thoroughly audit the existing CAs and work out if they had been compromised and then blacklist a range of them so that SSL clients (your browser, email client, phone apps etc etc) would no longer trust those CAs and no longer trust certificates issued by them. Although DigiNotar was blacklisted it isn't clear whether this was enough and remember that just one compromised CA certificate allows you to generate fake certificates for any website.
The recent 'heartbleed' bug in OpenSSL is in some ways much worse. OpenSSL is in use on 60%+ of websites on the internet and the attack allows anyone else on the internet to recover bits of memory from the target server. This has the potential to leak anything - user data, passwords, private keys for the entire secure session, server certificates.
The implications of this failing are huge. Certificates that affected websites are using should be assumed to be compromised. This will mean they will need to go back to the CA to get a new one. So far so bad but it sounds fairly manageable. The problem though is that those compromised certificates could still be used by an attacker to spoof (pretend to be) the attacked website and recover user data, passwords etc. The certificates then need to be blacklisted so that SSL clients (your browser, email client etc) no longer trust them.
The next problem here is that the list is just too big. Every SSL client can't carry a list of 60% of the sites on the internet. Just for practical purposes the blacklisting needs to be done at a higher level - at the CA level. Rather than just seeing DigiNotar get blacklisted we could see every CA get blacklisted.
Even the CAs at the very top issue end user certificates and will likely have issued enough that they couldn't just be included in a blacklist, so they themselves must be blacklisted.
Blacklist Everything or Insecure Connections... Pick One
Whether we will see this happen or not is another question. Realistically we probably won't see all the root Certificate Authorities be blacklisted. The effects of this would be too widespread and would essentially disable SSL even for sites that aren't affected.
That we won't see this happen though doesn't change the reality of the failure. Most of the sites on the internet are potentially, silently, compromised.
For SSL to recover properly and become as trustworthy as it was before these hacks, it essentially has to be reset.
That we won't see this happen though doesn't change the reality of the failure. Most of the sites on the internet are potentially, silently, compromised.
For SSL to recover properly and become as trustworthy as it was before these hacks, it essentially has to be reset.
Reset SSL? or Upgrade to a blockchain?
SSL has too much momentum to just die overnight and, despite this major failure in its security, there isn't a lot else we can rely on.
Certificate pinning (trusting each certificate individually for a particular website, verifying it through some other means) is a band-aid we might see applied a lot, particularly on high security or high visibility websites but it doesn't scale as a model and still requires the certificate to be initially verified before it can then be required for later use.
At some point over the next few years, if we are bothered at all about the security of our connections we will need to move to something that is either basically SSL but with new CAs (all subject to the same potential failures as the current SSL), or something better, like a blockchain.
Bitcoin's main focus at its inception was to become a new deflationary currency. In my opinion it has done that and done an incredible job in a very short time. But part of its underpinnings is a new construct in computer science - the blockchain.
Put simply, the blockchain allows digital scarcity. It allows a trust-free way to claim ownership of something digital, that everyone knows about, and to publish information about that owned thing only if you have the private keys.
Namecoin is geared towards exploiting exactly this. Namecoin allows you to look up the IP addresses (ultimate locations) of websites on the internet based on their name. DNS currently serves this purpose on the internet but its managed by a central authority. To register a domain you have to pay a company, its propagated up the stack until some organisation at the top says "your websites points to <address>". A simple analogy would be a phone book where you can register a unique name against your phone number, then its published and people can look it up.
The problem is this isn't secure and it doesn't include anything to allow you to verify that the person at the end of that number is who they say they are. This is where SSL takes over, the owner of the name has verified that they own it to a CA and since you trust the CA, you can now trust the website.
Break that trust though and it all falls apart.
Namecoin on the other hand has the ability to do both functions and merge them at the same time. With no central authority a user can register themselves as the owner of a name, point it to their address, but also register a certificate which can be used to establish that the person on the other end of that address is the owner of the name, not just somebody listening in or pretending.
The blockchain is a better system than both DNS and SSL and provides a better trust model than SSL ever did.
Hopefully in the coming years we'll see this recognised and start to see apps and browsers take advantage of it, perhaps eventually even move away from CAs and the SSL trust model altogether and migrate wholesale to it.
Certificate pinning (trusting each certificate individually for a particular website, verifying it through some other means) is a band-aid we might see applied a lot, particularly on high security or high visibility websites but it doesn't scale as a model and still requires the certificate to be initially verified before it can then be required for later use.
At some point over the next few years, if we are bothered at all about the security of our connections we will need to move to something that is either basically SSL but with new CAs (all subject to the same potential failures as the current SSL), or something better, like a blockchain.
Bitcoin's main focus at its inception was to become a new deflationary currency. In my opinion it has done that and done an incredible job in a very short time. But part of its underpinnings is a new construct in computer science - the blockchain.
Put simply, the blockchain allows digital scarcity. It allows a trust-free way to claim ownership of something digital, that everyone knows about, and to publish information about that owned thing only if you have the private keys.
Namecoin is geared towards exploiting exactly this. Namecoin allows you to look up the IP addresses (ultimate locations) of websites on the internet based on their name. DNS currently serves this purpose on the internet but its managed by a central authority. To register a domain you have to pay a company, its propagated up the stack until some organisation at the top says "your websites points to <address>". A simple analogy would be a phone book where you can register a unique name against your phone number, then its published and people can look it up.
The problem is this isn't secure and it doesn't include anything to allow you to verify that the person at the end of that number is who they say they are. This is where SSL takes over, the owner of the name has verified that they own it to a CA and since you trust the CA, you can now trust the website.
Break that trust though and it all falls apart.
Namecoin on the other hand has the ability to do both functions and merge them at the same time. With no central authority a user can register themselves as the owner of a name, point it to their address, but also register a certificate which can be used to establish that the person on the other end of that address is the owner of the name, not just somebody listening in or pretending.
The blockchain is a better system than both DNS and SSL and provides a better trust model than SSL ever did.
Hopefully in the coming years we'll see this recognised and start to see apps and browsers take advantage of it, perhaps eventually even move away from CAs and the SSL trust model altogether and migrate wholesale to it.
RSS Feed
