So, you use HTTPS to encrypt communication with your customers. Maybe you use the latest encryption ciphers and algorithms. But you may still have a very big issue in your setup. In this first blog post about HTTPS security, I’ll show that trust is at least important as encryption while securing communication. Furthermore, I’ll show how untrustworthy the current Certificate Authority infrastructure is.
Preface about SSL/TLS terminology
Mostly when talking about SSL (Secure Sockets Layer), one should use the term TLS (Transport Layer Security), since SSL stands for the predecessor of TLS. While every expert knows this, most people still use SSL when talking about TLS.
My intention with this blog post series is not fight for a terminology, but to reach as many people as possible. So I’ve decided to use the term SSL.
Encrypt everything!?
So, everybody knows, it’s a good idea to encrypt sensitive data when transporting them between computers. Some might even say it’s a good idea to encrypt everything nowadays. But there’s a fundamental security hole by design in the SSL hierarchy:
Theoretically, everybody can create his own SSL certificate and encrypt his webserver traffic. But this doesn’t stop me as an evil hacker to play man-in-the-middle:
Your customer ask for your website, but I’ll intercept the request and ask for your website for my own. Your website and I negotiate an encrypted SSL connection. Now I can observe/change the traffic and send the content unencrypted to your customer. The customer now uses HTTP all the time, while I’ll use HTTPS in communication with your server. I’ll guess he wouldn’t even notice that he’s not in an encrypted session.
A further approach is that I could use my own SSL certificate to re-encrypt the data before sending to the customer. Everything is encrypted with the hardest algorithms, so that must sufficient, right?
No. Encryption means nothing if you can’t distinguish a third party from the original sender.
To make this clear:
Encryption is not sufficient if you can’t identify the sender!
So the inventors of SSL established a hierarchical structure of trust: Some few authorities should be responsible to check your domain ownership and verify your certificate. This right of verification can even be delegated to other sub-authorities whose can delegate this right to the next, and so on. Your customer’s browser trusts those authorities, so it trusts your verified certificate.
So far, so good:
But a CA is trustworthy!
Only because a company says “Hey everybody! I’m honest, so please trust me as Certificate Authority (CA)”, maybe you shouldn’t. To show how ridiculous this is, somebody requested Mozilla to add the fictitious “Honest Achmed” as Certificate Authority.
Although most current CAs take their job serious and have a strong (and expensive) process of identity verification, there are always a few black sheep. The fact that each Root-CA can delegate its trust to other companies without telling anybody, doesn’t make things better. A research project of EFF showed that currently 6000 different certificates for the domain “localhost” are verified by a trusted CA.
To make this clear: Even if you choose a really trustworthy CA for your certificate, any other CA can give out certificates for your domain and you won’t even realize it!
Real world examples for SSL man-in-the-middle incidents
You think these are some theoretical issues? I’ve collected some incidents that happened before and some are still ongoing. But even if they were a one-time-thing, nobody can prevent this from happening again to you until you use proper techniques I’ll show you in this blog series.
1) Your internet provider plays man-in-the-middle
Some internet providers are big enough and have their own CA. From a technical point of view it’s no problem for them to install a SSL Interception Proxy (e.g. from bluecoat, the biggest player in this business) and eavesdrop or change your data.
In August 2014, Chinese Authorities intercepted SSL traffic from the Chinese Education and Research Network (CERNET) to Google, where it was still unblocked. Although they didn’t use verified certificates, it wouldn’t be any problem to do so: There are enough CAs companies which are under government control.
(Analysis of the attack)In January 2015, a Google engineer discovered that the in-flight wifi service is delivering fake certificates to intercept SSL traffic. The provider “Gogo Inc.” is the leader in in-flight connectivity services and has many big customers like American Airlines or Delta Air Lines.
(Gogo in-flight wifi serving spoofed SSL certificates)
2) CAs give out trusted certificates to others
Normally, certificate authorities have more or less hard identity check processes to ensure that only a legit organisation is able to get the certificates for its domains. That these processes are not error free will show these incidents in the past:
In September 2015, Google discovered that Symantec had issued a pre-certificate for google.com without its knowledge. Even more surprising was that this certificate was an Extended Validation (EV) one, and therefore was supposed to require extensive verification of the requesting entity’s identity and ownership of the domain. Since Symantec took over Verisign in 2010, it’s the biggest CA in the world.
(Sustaining Digital Certificate Security)In March 2013, a Fininsh man gained a trusted certificate from Commodo for Microsofts finnish live.fi domain. He was able to do this by signing up at live.fi with the username “hostmaster”. Commodo accepts those email addresses as valid identification for a domain.
(Man who obtained Windows Live cert said his warnings went unanswered)In March 2011, a hacker, whose attack traced to an IP address in Iran, compromised a partner account at the respected certificate authority Comodo Group, which he used to request eight SSL certificates for six domains: mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org and login.live.com.
(Hack Obtains 9 Bogus Certificates for Prominent Websites)
3) Your computer comes with a faulty CA root certificate built-in
During October till December 2014, Lenovo installed an adware (“Superfish”) on their devices which installs its own CA root certificate on the device. As if not bad enough, the key for this root cert was the same on every device and hard-coded within the software. An attacker could read this key out and install his own SSL interception proxy which will sign each compromised site with the superfish CA’s root certificate. Every superfished Lenovo laptop would accept these certificates without any warning.
(Wikipedia)ONGOING!!! While installing HPKP for one of our customers, we found out that one of its customers had trouble to connect to the SSL API. We found out that the company installed an SSL interception proxy in the network and their own CA root certificate on the employees’ devices. Even though this behaviour is very frightened, it seems to be common, especially for large enterprises. Even in Germany with its privacy-aware laws, it’s legal to do this, if you inform your employees and maybe you have to disallow private internet usage.
(security.stackexchange.com)Ongoing, but not yet critical. Your local antivirus application might have a feature to check even encrypted web traffic. The only way to do this, is to install its own CA root cert and play man-in-the-middle with SSL interception locally. Hopefully, your antivirus manufacture has done it right and doesn’t use the same certificate or -even worse- the same key on every device, like Superfish did. But the encryption your AV application uses could lower your security in a dramatic way. It could for example ignore the HTTP Public Key Pinning headers (HPKP), I’ll introduce in the upcoming blog posts of this series.
(How Kaspersky makes you vulnerable to the FREAK attack and other ways Antivirus software lowers your HTTPS security)
(Man-in-the-Middle Interfering with Increased Security)
4) Own experience
- In January 2016, an American email provider with high focus on security were recommended to friends of mine. I’ll should check for them how secure this provider is and realized that the username “administrator” is still available for registration. I was curious: Would it still be possible to obtain a valid and signed certificate with just an email address? To take one step further, I’ve chosen RapidSSL/GeoTrust as CA, which is the same CA that signed this domain originally.
So I spent $18 for a certificate and 5 minutes later I was in possession of a signed certificate for a domain that I don’t own from a CA that knows that I’m not the owner! 6 hours later, they were somehow informed about the additional signing and revoked it. But there may be enough clients out there, which still would accept my certificate because of outdated revocation lists…
To make this clear: I don’t blame the email provider for letting me register “administrator@domain.tld”. It’s not their fault that any CA gives out certificates by trusting a simple email address. Even if they prevent users from register one of
- admin@domain.tld
- administrator@domain.tld
- hostmaster@domain.tld
- postmaster@domain.tld
- webmaster@domain.tld
- every email address that’s in the whois record for domain.tld
there could still be an french sub-sub-authority out there which accepts “administrateur@domain.tld”…
Conclusion (tl;dr)
The biggest security hole in SSL lays not in the encryption (although some ciphers shouldn’t be used anymore). The biggest security hole is to trust hundreds of companies that not one of them runs riot regardless of by accident or by governmental force.
Some might say, this would not happen, because otherwise they will get banned from your browsers or your operating systems list of root CAs. Currently, all of the mentioned CAs are still in your list of trustworthy root CAs. One reason for this could be, that a CA could get too big to fail when they’ve issued enough certificates.
But there is something you can do:
- Strictly use SSL via HTTP Strict Transport Security (HSTS)
- Pin your certificate, or which CA you trust by using HTTP Public Key Pinning (HPKP)
In the next two posts I’ll introduce these techniques and show you how you can implement them in your webserver.
Kommentare