Background
When you use your browser to login to your bank’s website or say Facebook, have you ever wondered:
a) Is this really the bank’s website? Is this really Facebook? Or is it a fake site masquerading as the real deal that will steal my password and destroy my online life?
b) Is the data going between my browser and the web server safe from prying eyes? (Err hmm … not that we have any data worth stealing, Big Government …. but we do like our privacy)
Well, (a) is about authentication, and (b) is about confidentiality. These are largely accomplished by the use of Certificate Authorities (CA) and HTTPS.
HTTPS, in a nutshell, encrypts the communication between the browser and the web server. At the start of communication, your browser will do a “handshake” with the server, and both sides will agree on a set of cipher suite settings that both can support.
If Diffie Hellman (DH) key sharing is used by the cipher suite, you get perfect forward secrecy. If DH is not used, you have a old browser or web server. Perfect forward secrecy means that the communication stays secure even if the server’s certificate private key is stolen/cracked now (or even later, if someone had recorded a copy of your traffic)
Other cipher suite settings include the asymmetric cipher used for authentication. This usually RSA, but Elliptic Curve cryptography (EC) is recommended for the future. Another setting is the symmetric cipher (usually AES 128-bit, though I will sleep a bit better with AES 256-bit….) that is used to do the actual heavy-lifting of traffic encryption.
During the HTTPS handshake, the server presents a signed certificate to prove its identity. This is where CAs come in. CAs generate (and typically sell) signed certificates for websites. The certificate contains the domain, eg, sgwhitehat.com, and the website’s public key. The website holds on to a corresponding secret key for its signed certificate.
CAs makes use of public key infrastructure. A quick check on my browser shows that it comes preloaded with 225 root certificates from various Certificate Authorities companies, from US to Turkey. This is how it works.
These root certificates are “trusted” (Hey I don’t trust them, I don’t even know what most of these CAs are. In this case apparently ownership of the browser had transformed into forced trust in the browser’s certs. A topic for another day ….) The root certificates are used to verify the signed certificates presented during the HTTPS handshake are authentic, with the use of asymmetric ciphers and hash algorithms.
Did I mention the funny fact that while the server need to authenticate itself to the browser, the browser do not need to authenticate itself to the server? This is a shame, because I can think of some security benefits for authenticating your browser to the server (Note: anonymity is not one of them in this case! But, hey, surely you don’t mind authenticating yourself to your bank right?). Some corporate applications do however use client-side certificates for authentication, though not for browsers.
What are the problems in HTTPS here? Below is a list, and they are not speculative threats because they had already happened.
Problems
1. Certificate Authorities can be hacked, or pressured by governments to reveal their root certificate secret keys.
This enables the attacker to generate legitimate server certificates for services such as google, yahoo etc, and execute man-in-the-middle (MITM) or phishing attacks. The difference between man-in-the-middle and phishing is that in MITM, the attacker intercept and possibly modifies your traffic before passing them to the real website, while phishing attacks may completely masquerade as the real website.
It has happened before. A CA in Iran was either hacked, bribed, or pressured by the government.
https://www.f-secure.com/weblog/archives/00002128.html
Another example is a government agency in France that produces “bogus” certificates.
https://blog.mozilla.org/security/2013/12/09/revoking-trust-in-one-anssi-certificate/
You may ask: I live in Singapore or US, who cares if there are a couple of rogue CA root certificates? I am not accessing the google.com from Iran or France. There are two scenarios I can think of:
(a) An attacker who has compromised your home router or your ISP backbone router will be able to carry out the attacks. Home routers are a favorite among botnet hackers nowadays.
(b) This is more for state actor attackers. In today’s internet, most of the internet bandwidth flow through submarine cables or landlines. Your browser traffic may actually be routed through a telecom company in Iran or France, depending on traffic congestion (which can manipulated, by the way. See footnote 1) An attacker who has compromised one of the tier 1 routers will be able to redirect your browser traffic to their masqueraded google.com or yahoo.com, and you will be none the wiser. Thanks to Snowden, we know state-actors like NSA presumably has special programs for compromising such enterprise-grade routers.
2. Cryptography for root certificates can be broken
We trust CA and root certificates because we trust that the cryptography is strong. What if we are wrong in trusting the math? Horrors!
Unfortunately this is indeed what happened.
Windows act as a intermediate CA to sign their Windows update code. The Flame malware successfully broke all the cryptographic components used by the server certificate : (a) crack Window’s 512-bit RSA secret key and (b) forge the MD5 signature. Cracking the certificate server key is usually enough, but Flame had to exploit MD5 to gain further access to Vista and Windows 7 systems. It is used to carry out espionage in the Middle East.
While the target is Windows code instead of browser traffic, the security mechanism compromised is the same one used by CAs everywhere else.
To be fair, 512-bit RSA keys and the MD5 hash is known to be potentially weak for years before the attack is thought to have started. However Flame is still a marvelous piece of engineering.
Why didn’t Windows switch to the stronger 1024-bit RSA and SHA1/SHA2 hash long before? Probably Windows is just a bit slow to improve their security posture.
In another case, there is a targeted attack on high-level executives, mainly in Japan. This also cracks the 512-bit RSA certificate, and the target is now HTTPS traffic. The attackers successfully forged server certificates issues by a Malaysian CA.
https://securelist.com/blog/research/66779/the-darkhotel-apt/
3. Cryptography implementations may contain flaws
We trust CA and root certificates because we trust that the cryptography is strong. But can we trust the software that implements the cryptography? Maybe the core cryptography library is well-audited, but what about the application that calls the library?
Note the recent famous Heartbleed vulnerability and PODDLE vulnerability, which had sent web admins racing to patch (and then patch the patch again because the first patch did not work 100%) ….
In Heartbleed, a (buffer over-read) flaw in the widely used OpenSSL library allows an attacker to obtain leaked information from the web server that contains the server’s secret key. Reconstructing the server key from the leaked information is non-trivial though.
In PODDLE, a man-in-the-middle attacker can cause HTTPS traffic between a browser and server to downgrade from the standard TLS protocol to the weaker SSLv3 protocol. Browsers have been patched to ensure that the downgrade is no longer possible.
4. Outright man-in-the-middle attacks
In one example, the attacker do not even bother to obtain the root certificate key. They simply self generate a server certificate and count on the user to overlook that the server certificate is not legitimate (Most browsers would indicate that there is something wrong with the server certificate. I hope you know where the indicator is).
And the amazing thing is that this works on people! The below case is a company providing in-flight WiFi who wants to do bandwidth control, so it is not malicious (if you count slurping your personal data non-malicious)
http://www.theregister.co.uk/2015/01/06/gogo_ssl/
Analysis of who are the likely attackers for HTTPS
| Problem with HTTPS | Who are the likely attackers |
| CAs can be hacked, bribed, coerced | governments (aka state actors), criminal organisations, hacktivist groups |
| HTTPS cryptography can be mathematically broken | Used to be only state actors, but with relatively cheap cloud computing, I would not rule out criminal organisations |
| Exploiting vulnerabilities in HTTPS implementation | state actors, criminal organisations, hacktivist groups |
| Man-in-the-middle for less savvy users or users | criminal organisations, hacktivist groups,
commerical companies, your friendly neighbour |
Solutions
Two things need to happen for a successful HTTPS attack to take place:
(a) the attacker is able to redirect your traffic to a website of his/her choosing. This can be done by compromising the user computer/device, the routers between user’s browser and the website, or even forging DNS resolution (DNS resolves the url google.com to an IP address).
(b) the server certificate is successfully forged.
Breaking either (a) or (b) will halt the HTTPS attack.
For (a), for now the only things you can do is to keep your routers’ patched to the latest firmware version, and employ the usual defense-in-depth defense for your network and the usual anti-malware for your computer/device. Be suspicious if there is an unusual lag in accessing your usual websites, or if the website looks like a phishing website even though the server certificate checks out.
There are some potential improvements in the future, particularly in the use of DNSSec and a network notary that look for false server certificates and signs of redirected traffic.
https://freedom-to-tinker.com/blog/dwallach/building-better-ca-infrastructure/
For (b), if the CA is hacked or compromised, there isn’t much you can do. Assuming the CA is not compromised, demanding stronger cryptographic settings for your server certificates will help (for a while). EU’s ENISA has some pretty dense recommendations.
In short, just use larger key sizes and newer hash algorithms, ie, key size of 2048 (if you are sticking to RSA and not moving over to the better elliptic curve crypto), use AES-256 in counter mode and employ SHA2 hash in the server certificates.
Google and CIA have invested in quantum computers that can break the asymmetric crypto used by HTTPS or CAs. Quantum computing is still in early stage, but when it happens (which may be 10-20 years down the road), expect some big changes. Just hope that the “Horray! We cracked 2048-bit RSA!” announcement doesn’t happen overnight or else the financial world will probably suffer another meltdown, because no data in the world will be secure anymore.
Leave a comment if you think that there are other potential problems with HTTPS and CAs that I left out. Thanks for reading this long blog post!
Footnote
(1) There was a short period of time when someone accessing US government websites will find their traffic routed via China. This is due to a telecom router misconfiguration in China (officially!)
http://arstechnica.com/security/2010/11/how-china-swallowed-15-of-net-traffic-for-18-minutes/
.
SGWhiteHat 