Certificate Transparency Does More Harm Than Good - Here's Why

With Google’s recent decision to change the lock icon, I’ve been spending a lot of time thinking about TLS/SSL - and certificate transparency in general. 

Certificate transparency (CT) mandates the inclusion of TLS/SSL certificates in a global, public registry. First introduced in 2013 by researchers from Google, Certificate transparency (CT) was proposed after the researchers observed that the traditional Certificate Authority model, which relied on a few trusted third-party CAs, such as Comodo and DigiNotar to issue certificates, was susceptible to various types of attacks. 

Since its introduction, CT has been adopted by major browser vendors, including Google Chrome, Mozilla Firefox, and Apple Safari.

While CT offers benefits such as enhancing transparency and preventing certain types of attacks, there are also concerns about its impact on privacy and unexpected sharing of information. 

In fact, I’m starting to wonder if Certificate Transparency may be a net negative for security.

In this blog post, I’ll explore both how Certificate Transparency is helpful and the downsides, including the way it shares users' information and the rise of beg bounties.

The Good: Enhancing Security

Certificate Transparency (CT) is a system that was designed to increase online security by mandating the inclusion of TLS/SSL certificates in a global, public registry. 

Certificate transparency logs primarily defend against two types of attacks: 

1. Mis-issued certificates, which could be used by an attacker to impersonate a legitimate website, thereby stealing sensitive information.
2. Rogue certificate authorities, which prevents attackers from creating their own certificates and using them to carry out phishing attacks or other malicious activities. In essence, these logs could hypothetically be used to detect when a certificate is issued to the wrong entity. 

CT also allows domain owners to monitor and track certificate activity related to their domains. By monitoring these logs, domain owners can detect and investigate any unauthorized certificate issuance, which can prevent security incidents before they happen.

The Bad: Surprising End Users

So what’s the problem? (This is the controversial part.)

The core issue with Certificate Transparency is that it surprises end users and shares their information in a way they don’t expect. Most users are unaware that getting a certificate results in a global broadcast of the host and certificate details. In fact, I’ve not found a single developer who made the connection between asking for a certificate and inviting a scan. It’s just not expected. 

To illustrate this point, consider a hypothetical situation where every driver's license issued was added to a live, searchable database, including personal information like names and addresses.

This has the security property that anyone can check if there is a mis-issued driver's license and for rogue actors malicious issuing drivers licenses. But it’s still the wrong thing to do. While driver's licenses are already shared in various contexts, there is a difference between limited exposure and making that information globally available. 

Like the hypothetical drivers license, you cannot opt out of transparency logs, and all information becomes immediately available to attackers. Further, certificate transparency doesn’t solve common networking scenarios like getting a certificate for an internal server like dev.internal.mydomain.com. 

I don’t recommend google’s hack here of issuing wildcard certificates like ‘*.internal.mydomain.com’ to the host, and RFC-6125 agrees and specifically advises against wildcard certificates. Why? A compromised wildcard certificate would allow an attacker to impersonate ALL hosts on your network, while the damage from a compromised normal certificate is a single hostname.

The Ugly: The Rise of “Beg Bounties”

How are attackers using certificate transparency logs in practice? A very annoying real example is the rise of “beg bounty” hunters, who use transparency logs to fuel their scans. They monitor the log, run a trivial scan to find some trivial issue, and then ask for money.

It’s a distraction from true security research and authorized bug bounty programs. And if beg bounties are doing this, imagine what real attackers are doing with the information. 

Try CT Yourself

Try it yourself. Go to crt.sh (no affiliation), and enter in interesting domain names like your companies, banks, and school. I’m constantly surprised at what I see.

So do we need transparency logs? 

I do like the security properties. And transparency in general isn’t bad, when it’s useful to the end user.

But I think there are better ways we could do this. In the meantime, it seems like we’re using a bazooka to hammer a nail. The nail gets pounded, but with a lot of collateral damage.

Mayhem:

Developer-First Security Testing

Mayhem is application security built by professional hackers. Every result is real and actionable for immediate triage and rapid remediation.

Get Mayhem Free Request A Demo