Occasionally, it raises its head when you visit a website and your browser notifies you that a certificate is not trusted for some reason or another. Actually, certificate based authentication and encryption is not that difficult to get your head around. When a server wants to encrypt traffic between itself and a client application such as a browser, it usually makes use of a signed digital certificate.
No ad to show here.
The certificate contains bits of information that the client application can inspect to determine whether or not it will trust the server and the encryption being used. Perhaps the most important part of the certificate is its CA, or Certificate Authority, responsible for signing the certificate. The CA is usually a third-party that the client application trusts to have verified that the server presenting the certificate is correct. Usually, you don’t need to know much about these guys as an end user, because the developers of your client application will often simply select the CAs that they think are trustworthy on your behalf.
There is big money in certificate signing. Widely recognised CAs like Verisign and Thawte can charge a couple of hundred dollars for a single singed certificate that will expire in a year. A certificate like this is usually tied to a single domain name, so you tend to need to buy a certificate for each domain name that you want to use. That means that if you have a web server that you are securing at www.example.com and an FTP server at ftp.example.com, you are going to need two separate certificates. You can get around this by buying a wildcard certificate, but the cost jumps up pretty quickly.
So as a provider of a secure service on the Internet, you pay a CA to sign your certificate to say that they have checked that you are who you say you are and that your certificate belongs to you. Usually, this is done fairly simply by email, and occassionally a telephone callback will be used to double-check the details that you have provided to get your certificate signed.
It doesn’t sound particularly secure from the start, but up until recently the large majority of Internet users have been happy accepting that this is the way things are done. The problem with all of this is that we really don’t know if we can trust any CA.
The recent attacks on a number of CAs have highlighted that their own infrastructure has to be completely impermeable in order to prevent false certificates being issued, and that is simply not plausible for any internet connected service provider. To make matters worse, once a false certificate has been issued, it is impossible to fully revoke it as this would require every software vendor that accepts the breached CA’s signatures to update their software and ensure that every end-user is in turn updated as well.
In actual fact, anybody can be a CA and can sign their own certificates. The problem, of course, is that client applications need to know about you in order to trust your certificates, and this is really why certificates are so expensive.
Recognised CAs spend time and money convincing developers and product vendors that they are trustworthy enough to have their stamp of approval bundled with released software. Most applications that use SSL or TLS provide a means for the end-user to update their own CAs. That can be useful to protect yourself from CAs that you know have been compromised, since you can remove the CA certificate from your application. The downside is that removing the certificate for a larger CA that has signed millions of certificates is more than likely going to make it impossible to use your application with the millions of domains using those certificates.
When DigiNotar was compromised recently, browser vendors like Mozilla were relatively quick to remove their CA certificate from future releases of Firefox, because DigiNotar is a relatively small player in the CA world. When Comodo was compromised in March, however, and certificates for domains such as Google and Yahoo were signed falsely, the major software vendors generally tried to turn a blind eye as the impact of removing Comodo as a CA would affect too many sites.
But on the same note, the fact that you can manipulate which CAs your software trusts, means that it is fairly trivial to write a virus that simply installs a bunch of dodgy CA certificates onto your machine and then deletes itself.
Once those are in place, your software will trust certificates issued by the same CAs and you will be none the wiser. Of course, there are much more radical approaches to fooling applications and even users into believing that they are communicating securely with a trusted source.
If anything can convince you that our whole approach to security using certificates is flawed, you should watch Moxie Marlinspike’s DefCon 2009 presentation More Tricks for Defeating SSL.
Two years ago, Marlinspike presented some tremendous attack vectors that, in my opinion, completely undermine the idea that communication over SSL is genuinely secure. If you’re into blackhat activity, or are genuinely interested in security, you can download his SSLStrip application from his website and you will never want to bank online again.
The fact that CAs are under attack now is hardly surprising. We have become so blindly accepting of SSL as our Internet security blanket that we don’t even try to understand how simple it is to strip it of any integrity. As long as we continue to ignore how the security that is meant to be core to SSL is rapidly being undermined, the Internet will continue to become a dangerous place to store personal information or engage in any kind of business. Meanwhile, a billion dollar industry will continue to sell us certificates that belong to the ghost of security past.
