Certificate Transparency Logs —What you need to know

ACM.247 Be aware of data exposed in Certificate Transparency Logs

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: Application Security | Secure Code | DNS | TLS

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post I automated the second step of validating a TLS Certificate deployed with CloudFormation so you can automate the whole process.

I skipped over the Certificate Transparency Logs in the CloudFormation template because It warrants a longer discussion.

What are Certificate Transparency Logs and why do they exist?

The problem starts with certificate authorities trying to make sure they do not issue invalid certificates. In 2011, a hacker broke into Comodo and issuesd a number of invalid certificates for GMail, Hotmail, and Yahoo!

In order to combat this problem, Google came up with the concept of Certificate Transparency Logs. You can read their initial documentation on the Wayback Machine but this might take a while to load.

One of the problems is that there is currently no easy or effective way to audit or monitor SSL certificates in real time, so when these missteps happen (malicious or otherwise), the suspect certificates aren’t usually detected and revoked for weeks or even months. What’s more, these types of SSL missteps are occurring with increasing frequency. Over the past few years there have been numerous instances of misissued certificates being used to spoof legitimate sites, and, in some case, install malicious software or spy on unsuspecting users.

Certificate Transparency Logs are an append-only log that tracks issue of certificates, especially for public certificate authorities (CAs). Public certificate authorities are those that issue certificates such as the one I deployed in my last two posts — for websites and applications that need to prove they are legitimate and encrypt data in transit.

When I say “prove they are legitimate” I’m not talking about whether momandpopshop.com is going to sell you bogus products. I am referring to the fact that when you visit a google.com website you are getting to a Google server — not one controlled by an Iranian hacker. The public certificate authority allows a web browser to see if the certificate for the web site you are visiting is valid. A TLS certificate validates that you are getting to the correct web server for the site you are trying to visit and encrypts the data in transit — unless the certificate is compromised in some way.

Now an established specification exists for Certificate Transparency Logs which you can read if you want to get into the nitty gritty of how these logs work.

Some browsers require certificate transparency logs as explained on Wikipedia. You can check the references in this document if you want to validate the information on this page.

So if you are using a public facing website you’re likely going to want Certificate Transparency Logging enabled in most cases.

The downside of Certificate Transparency Logging

In the past you used to be able to look up the name and contact information of anyone who owned a web domain. For example

For example, you can go look up 2ndsightlab.com at ICANN:

Here you can see the name servers for the 2ndsightlab.com domain:

Scroll down and you used to be able to get the name of the owner of the domain and their contact information. Now that is hidden by any domain registration service worth using. Don’t tell anyone, but I own 2ndsightlab.com — my terribly out of date web site which maybe I’ll update after all this is said and done.

Since people can’t find out information that way anymore, some have turned to looking at Certificate Transparency Logs to find useful information that can help them gather information about domains for potential attacks.

I’m not promoting this site because I know nothing about it, but it allows you to view certificate transparency logs for a domain. I just found it using a Google Search:

You can see here that I’ve entered my new domain created in prior posts. Since AWS enables certificate transparency logs by default there are already some entries here, and they cannot be removed. Certificate transparency logs are write-once-read-only (WORM) type logs.

Well, my email is still not in there so that’s good. But what else can we do with these logs? Let’s enter rainierrhododendrons.com instead and check the box for subdomains:

Now I can get all the subdomains related to that domain as well via the certificate transparency logs! If you are working on a new super secret project and deployed a subdomain and a public certificate, an attacker may be able to discover it by using these logs. So there are some circumstances where you might think you want to turn them off. But remember, browsers require them. So if you plan on doing that make sure you it works for your use case.

What does AWS say about Certificate Transparency Logs?

Enable them! They are required by some browsers so it is a best practice.

As of April 30 2018, Google Chrome no longer trusts public SSL/TLS certificates that are not recorded in a certificate transparency log. Therefore, beginning April 24 2018, the Amazon CA began publishing all new certificates and renewals to at least two public logs. Once a certificate has been logged, it cannot be removed.

They are enabled by default.

Logging is performed automatically when you request a certificate or when a certificate is renewed, but you can choose to opt out. Common reasons for doing so include concerns about security and privacy. For example, logging internal host domain names gives potential attackers information about internal networks that would otherwise not be public. In addition, logging could leak the names of new or unreleased products and websites.

I did find a post on the AWS blog suggesting you should disable them. I recommend you do not do that unless you really know what you are doing. It opens the door for attacks as explained at the top.

If you are really concerned about subdomains being exposed, you could register a completely separate domain name for internal use only. I wrote about that in my prior post in this series on a static website on AWS S3.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab