There are over 10 billion HTTPS certificates on the Internet. These certificates help keep your activities online private.
Anyone can make a certificate for a website, but that ease and accessibility isn’t necessarily a good thing. What if I’m a bad actor and I want to pretend I’m a famous website? I would be able to do that. But it is very likely that my device wouldn’t fall for it.
Here is why:
When you visit www.example.com, your device looks up the IP address. A bad actor would have to hack your device to forward the requests to their IP address instead. Because this post is about HTTPS, let’s say they are successful in doing this.
The first thing your device does is check the certificate to ensure it is trusted. Since the attacker generated the certificate manually, the device is going to freak out and not go any further. Why is this?
Certificates need to be signed by a Certificate Authority. The Certificate Authority is responsible for verifying that the person requesting the new certificate actually owns the domain. It is usually done through DNS or file verification. Someone who has control of the DNS or the website can verify the domain. Since a bad actor doesn’t have control of this infrastructure, they wouldn’t be able to get a certificate. But what happens if there is a bad Certificate Authority who doesn’t verify correctly?
Meet Certificate Transparency
The idea is that, in a perfect world, any certificate generated would also generate a log that is publicly available. This log is designed to be tamper proof. So if a bad actor did generate a certificate for your site, or Bob from accounting wanted to make his own company subdomain without approval, IT can listen to the logs and react if needed. A company can know within hours that something is wrong, instead of days or weeks.
A really important aspect of the log is that it is public. That puts more pressure on the Certificate Authorities to get it right. People can look for patterns of abuse and actions can be taken to minimize risk to users.