HTTPS, which uses SSL, provides identity verification and security, so you know you’re connected to the correct website and no one can eavesdrop on you. That’s the theory, anyway. In practice, SSL on the web is kind of a mess.
This doesn’t mean that HTTPS and SSL encryption are worthless, as they’re definitely much better than using unencrypted HTTP connections. Even in a worst case scenario, a compromised HTTPS connection will only be as insecure as an HTTP connection.
The Sheer Number of Certificate Authorities
Your browser has a built-in list of trusted certificate authorities. Browsers only trust certificates issued by these certificate authorities. If you visited https://example.com, the web server at example.com would present an SSL certificate to you and your browser would check to make sure the website’s SSL certificate was issued for example.com by a trusted certificate authority. If the certificate was issued for another domain or if it wasn’t issued by a trusted certificate authority, you’d see a serious warning in your browser.
One major problem is that there are so many certificate authorities, so problems with one certificate authority can affect everyone. For example, you might get an SSL certificate for your domain from VeriSign, but someone could compromise or trick another certificate authority and get a certificate for your domain, too.
Certificate Authorities Haven’t Always Inspired Confidence
Studies have found that some certificate authorities have failed to do even minimal due diligence when issuing certificates. They’ve issued SSL certificates for types of addresses that should never require a certificate, such as “localhost,” which always represents the local computer. In 2011, the EFF found over 2000 certificates for “localhost” issued by legitimate, trusted certificate authorities.
If trusted certificate authorities have issued so many certificates without verifying that the addresses are even valid in the first place, it’s only natural to wonder what other mistakes they’ve made. Perhaps they’ve also issued unauthorized certificates for other people’s websites to attackers.
Extended Validation certificates, or EV certificates, attempt to solve this problem. We’ve covered the problems with SSL certificates and how EV certificates attempt to solve them.
Certificate Authorities Could Be Compelled to Issue Fake Certificates
Because there are so many certificate authorities, they’re all around the world, and any certificate authority can issue a certificate for any website, governments could compel certificate authorities to issue them an SSL certificate for a site they want to impersonate.
This probably happened recently in France, where Google discovered a rogue certificate for google.com had been issued by French certificate authority ANSSI. The authority would have allowed the French government or whoever else had it to impersonate Google’s website, easily performing man-in-the-middle attacks. ANSSI claimed the certificate was only used on a private network to snoop on the network’s own users, not by the French government. Even if this were true, it would be a violation of ANSSI’s own policies when issuing certificates.
Perfect Forward Secrecy Isn’t Used Everywhere
Many sites don’t use “perfect forward secrecy,” a technique that would make encryption more difficult to crack. Without perfect forward secrecy, an attacker could capture a large amount of encrypted data and decrypt it all with a single secret key. We know that the NSA and other state security agencies around the world are capturing this data. If they discover the encryption key used by a website years later, they can use it to decrypt all the encrypted data that they’ve collected between that website and everyone who’s connected to it.
Perfect forward secrecy helps protect against this by generating a unique key for each session. In other words, each session is encrypted with a different secret key, so they can’t all be unlocked with a single key. This prevents someone from decrypting a huge amount of encrypted data all at once. Because very few websites use this security feature, it’s more likely that state security agencies could decrypt all this data in the future.
Man in The Middle Attacks and Unicode Characters
Sadly, man-in-the-middle attacks are still possible with SSL. In theory, it should be safe to connect to a public Wi-Fi network and access your bank’s site. You know that the connection is secure because it’s over HTTPS, and the HTTPS connection also helps you verify that you are actually connected to your bank.
In practice, it could be dangerous to connect to your bank’s website on a public Wi-Fi network. There are off-the-shelf solutions that can have a malicious hotspot perform man-in-the-middle attacks on people who connect to it. For example, a Wi-Fi hotspot might connect to the bank on your behalf, sending data back and forth and sitting in the middle. It could sneakily redirect you to an HTTP page and connect to the bank with HTTPS on your behalf.
It could also use a “homograph-similar HTTPS address.” This is an address that looks identical to your bank’s on the screen, but which actually uses special Unicode characters so it’s different. This last and scariest type of attack is known as an internationalized domain name homograph attack. Examine the Unicode character set and you’ll find characters that look basically identical to the 26 characters used in the Latin alphabet. Maybe the o’s in the google.com you’re connected to aren’t actually o’s, but are other characters.
We covered this in more detail when we looked at the dangers of using a public Wi-Fi hotspot.
Of course, HTTPS works fine most of the time. It’s unlikely that you’ll encounter such a clever man-in-the-middle attack when you visit a coffee shop and connect to their Wi-Fi. The real point is that HTTPS has some serious problems. Most people trust it and aren’t aware of these problems, but it’s nowhere near perfect.
Image Credit: Sarah Joy