When you deploy HTTPS, you’ll typically need to get an SSL certificate signed by a commonly trusted certificate authority. Certificates and authorities come at many different pricing levels with many different validation depths. A common misconception is that more expensive certificates provide better security. In reality, your choice of vendor rarely matters, and more expensive certificates do not make your website safer.
A basic introduction to certificate trust
A proper deployment of HTTPS typically offers two features: it means an encrypted connection is set up between client and server, and the identity of the server is verified. The latter is just as essential as the former: the fact that you have an encrypted connection does not guarantee anything about who you’re sending that encrypted data to. Without verification of server identity, a man in the middle is still simple. So how does a browser verify the identity of the server?
Certificate authorities (CAs) exist to tackle this problem. Operating systems and browsers include a long list of certificate authorities they trust. These CAs promise that they will thoroughly check before signing a certificate. Mozilla currently trusts just under four hundred CAs. We often call these CAs “root CAs”, as they are the trust root. Users can change the list of trusted CAs, but they rarely do.
If I would like to request a certificate for api.example.com, that browsers will trust, I have to convince one of these CAs that I am the owner of that domain. Having done that, they will sign my certificate for a fee, typically ranging from € 10 to € 1000. E-mail validation is quite common for this. Many CAs also offer signing certificates with more data, like company names and addresses, or even extended validation certificates, with more rigorous checks.
Once one of it’s trusted root CAs has signed my certificate, the browser will trust that the certificate really belongs to my domain. This can involve intermediary certificates, as long as in the end, the chain of trust is signed by a known CA:
The blue certificate, the one I have for my domain, is different from the other two: it is configured such that it can not sign other certificates itself. This is an important security measure: if I could use my certificate to sign others, I could build a working chain of trust for any domain. The root CAs are of course configured to allow them to sign other certificates.
Why expensive certificates are not safer
Pricing varies widely, but the misconception is that higher prices result in safer websites. Note carefully what I said about trust: if any of the 377 CAs have signed my certificate, Firefox will trust it. Let’s say you pay € 1000 for your certificate, and that CA advertises itself as having the most rigorous procedures against issuing illegitimate false certificates. Perhaps they will even insure you against security breaches caused by them signing an illegitimate certificate for your domain. However, I don’t need that specific CA: if I trick any of the other 376 CAs into giving me an illegitimate € 10 certificate, the browser won’t show the difference.
In other words, as soon as there is one commonly trusted CA that provides illegitimate certificates, every single SSL website is at risk for man in the middle attacks. Regardless of which CA that website may have used, how much it cost or how rigorously the legitimate certificate was checked.
This is often misunderstood when a CA is badly compromised. In 2011, it was revealed DigiNotar had issued fraudulent certificates. Many Dutch government websites used their certificates, so there was a lot of media attention. The almost universal misconception was that HTTPS websites with certificates signed by DigiNotar were considered insecure. But that’s incomplete: with DigiNotar issuing fraudulent certificates, every HTTPS website in the world was at the same risk. The only concern specific to DigiNotar-signed certificates was to quickly replace the certificate, as this compromised CA was quickly removed from the trusted lists of operating systems and browsers.
What about extended validation?
Extended validation means users see the familiar green address bar, usually with the company name in it. They are considerably more expensive, and involve a lot of extra paperwork. EV can be a little different my argument, because the difference between EV and non-EV is visible to the user. If the compromised/sloppy CA would be issuing fraudulent EV certificates, that would not make a difference, but that’s a lot less likely. So EV would be a useful addition, if users would notice that the site that previously used EV no longer uses it (because an attacker is performing a man in the middle attack on them with a simple certificate).
In 2006, researchers at Stanford University and Microsoft Research conducted a study of phishing and EV, using Internet Explorer 7. They concluded that “participants who received no training in browser security features did not notice the extended validation indicator and did not outperform the control group”, and “participants who were asked to read the Internet Explorer help file were more likely to classify both real and fake sites as legitimate”.
In other words, extended validation typically adds no security compared to cheap certificates, because anyone who obtains a non-EV certificate can do a man in the middle attack, without ordinary users noticing the difference.
The only value I could imagine would be that users have more trust in a website with EV. Although a common claim by those selling EV certificates, I haven’t found any research on this.
Extended validation on Heroku
I only know of a single case where EV has actually provided additional security. Heroku, a common hosting platform, uses EV to distinguish between official Heroku apps and user-hosted apps. This means it’s instantly obvious whether a Heroku customer is entering their password in an official Heroku app, or something built by a random user. This is a good way to distinguish this, while still offering everyone HTTPS. However, the audience is rather different: this audience is actively informed what to deduce from the presence or absence of EV, and is rather tech savvy overall.
Update: as Jacob clarifies on twitter, this is actually more a remedy of the mistake of hosting customer apps on *.heroku.com. Had they been hosted on *.herokuapps.com or something like that, this kind of confusion would have been prevented from the start.
More expensive certificates are not more secure, because browsers will trust the certificate as long as it is issued by any known CA. It doesn’t have to be the same CA. This means a single compromised or sloppy CA puts every HTTPS website at risk of man in the middle attacks.
Extended validation certificates are often sold with the claim to provide additional security, but research has shown that users are unlikely to notice if the EV suddenly disappears, meaning they are no safer than regular cheap certificates.
Personally, I get all my certificates from Xolphin (Dutch only), which has a streamlined process and fast support. I always buy the cheapest certificate available, for € 10 per year.