HTTPS & Certificate Authorities
If you know what Certificate Authorities are, jump down to the section: Trusting the Certificate Authorities
Most websites use HTTPS to serve their users because HTTPS is more secure than plain-old HTTP. In the HTTP world, people sitting on your wifi could snoop and see your personal data and even change the content of the websites you are seeing. Similarly, adversaries could do the same attack by controlling any of the many routers sitting between you and the website. To prevent this, the browsers (and the web community at large) did a lot of work to advocate for the usage of HTTPS.
For example, in 2018 Chrome announced that HTTP websites would be marked insecure by default. Other browsers did similar things to provide incentives for developers to switch to HTTPS.
The basic premise of HTTPS is that it allows your browser to do two things:
- Verify that the data it received was actually sent by the website (which means someone in between was not able to change the message)
- Protect the data that it sends to the website so only the website owners can decrypt the data (to prevent someone in between from seeing your personal data like passwords)
It is kinda crazy that we can do this at all. The internet is an untrusted channel (adversaries can listen and manipulate data traveling across) and yet somehow we can build a trusted channel on top of it. How does that work?
We use a bunch of cool math! The only thing the math requires is that the website owners create a special “key” pair and publish one as the “public” key and keep the other secret as a “private” key. Now whenever someone connects to the website, the website returns the public key and the browser uses that (and the bunch of math) to validate/encrypt the data.
The only problem here is that we are on an untrusted channel! If there is an adversary in the middle, they can just send us a different public key which allows them to see all the data again. We are back to square one!
One solution could be that each website owners send their public key to the browsers in advance and the browsers pre-package these public keys. This potentially could work if there were like 10 well-known websites but we have millions of websites. Browsers don’t want to directly validate the ownership of millions of websites and they don’t want to add gigabytes of prepackaged data to the browser (which would go stale pretty quickly as new websites or public keys are created).
So this problem is more generally solved by delegating the validation work to Certificate Authorities.
Each browser chooses to trust some companies to be Certificate Authorities. These companies verify that a given public key is owned by the same people that own a website and once verified they sign the public key (the signature and the key together are called a certificate). So if a website provides this certificate when a connection is made, the browser can verify the signature and know that the public key can be trusted.
Trusting the Certificate Authorities
HTTPS is critical for safety on the internet. Certificate Authorities are critical to HTTPS.
If a rogue Certificate Authority signs an attacker’s public key for google.com or <your bank>.com then
the attacker can use that key to completely compromise your account. So Certificate Authorities have a lot of power.
So the question is: who should we trust with this power?
- Governments certainly should not be certificate authorities. No matter what claims a government makes, it will eventually abuse this. Maybe it would be to save lives or maybe it would be to identify and kill dissidents. Since you can’t know in advance which it’s going to be, you can’t really go this route.
- Browser owners don’t want this responsibility. Google/Apple/Microsoft are big companies and they don’t want to be in a situation where governments can apply pressure on them to sign invalid keys (whether via legal authority or backchannel threats).
- We probably also want to reduce how much power these giant companies have. So not trusting them to do this at least reduces some of that power.
So that leaves us with private third parties. It’s the practical solution but also the reason why internet safety is so fragile. The safety entirely depends on hundreds of private entities not making mistakes, not being manipulated, and not being malicious. And they don’t have a perfect record.
Symantec (mistakes)
Symantec was one of the bigger Certificate Authorities that made A LOT of mistakes and was eventually distrusted by all trust stores in 2017.
The funniest mistake was that they signed fully valid certificates for 50+ websites in their test environment. At least one of those certs was for www.google.com. This meant that the people that were testing had access to certs that would let them intercept anyone’s connection to www.google.com! These test shenanigans continued from 2009-2015. Even after the initial complaint, Symantec pretended like it was a one-off till Google devs linked them to a whole bunch of other examples published by Symantec.
DigiNotar (manipulated)
DigiNotar was a Dutch Certificate Authority that was hacked in 2011. The hacker used the access to create certificates for all google.com websites. This certificate was then used to maliciously intercept the traffic of hundreds of thousands of Iranian Gmail users. The Iranian government is the likely suspect of this attack. The attack was used to find users’ locations through Google accounts, as well as to hack social media accounts through the email access.
Note that there is no geographic relationship in the impact. It doesn’t matter that the CA was Dutch. The generated certificates could be used anywhere in the world. The attacker can choose to attack any CA anywhere in the world.
The compromised certs were signed in July, the hacked certs were discovered in August and DigiNotar was wholly distrusted soon after. Funnily enough, the Dutch government used DigiNotar as its CA so when the browsers started distrusting DigiNotar, Dutch government websites started having trouble.
A positive note here is that this incident directly led to Certificate Transparency Logs. This requires that Certificate Authorities must publish each certificate that is created to public logs for that certificate to be valid. This way, if a CA does go rogue, it can be identified more quickly.
ICP-Brasil (likely malicious?)
Literally, as I am typing this post, there is a report that ICP-Brasil (which is run by the Brazilian government) issued a certificate for google.com. The CA already had problems in the past so they were never trusted by Chrome/Mozilla/Apple but they are trusted by Microsoft.
This means that Windows and Edge users are at risk all around the world till this CA is untrusted by Microsoft.
If this turns out to not be intentionally malicious, there is still the example of India CCA (which is run by the Indian government) issuing a certificate for google.com and yahoo.com in 2014. Just like ICP-Brasil, this CA was only trusted by Windows. There is no evidence that these certs were used in a large-scale interception of traffic, but targeted use of these certs would not have left any more evidence to be discovered either.
Fragility of The Internet
There are 4 active “trust stores” that everyone relies on: Chrome/Mozilla/Apple/Windows. They each independently decide which CAs they should trust and which CAs they should not. The 4 groups work together on creating rules and expectations that CAs are supposed to follow and they frequently use the same systems to discuss and follow up on issues with CAs.
Some of these discussions can feel pedantic but I think that’s because the stakeholders there understand the fragility of the ecosystem. The scope for harm is significant and if pedantry can help reduce the harm, then I guess I fully support the pedantry. But unfortunately, that doesn’t remove the possibility of harm.
Trust stores are as strong as the weakest Certificate Authority. CT logs make it possible to discover attacks. Distrusting CAs as punishment properly aligns incentives for CAs to do a good job. However, when well-funded adversaries are involved, these mechanisms are likely not enough. For high-risk individuals or businesses, it is worth understanding this risk.