The use of domain names and TLS certificates that include your organisation’s brand or product name is a common way to make links in phishing emails appear legitimate. Keeping an eye on DNS and certificate registrations can help you gauge whether attackers have begun targeting your customers. This article in the “Fighting Back against Phishing and Fraud” series examines certificate transparency and how it can help alert you to fraudulently registered TLS certificates. If you missed Part 1, click here.
Why Do We Need to Monitor Domains and Certificates?
In the spirit of “it’s not a bug, it’s a feature,” today’s public key infrastructure (PKI) lets us create a TLS certificate for a domain name we control from any certificate authority (CA). By way of an example, this means that DigiCert, Comodo, and Let’s Encrypt, to name just three popular CAs, are all able to create a certificate for paypal.com. This flexibility encourages competition among CAs to offer more features and lower prices to consumers. But it also makes the system prone to abuse—and confusing for website visitors. Should I, for example, trust the paypal.com certificate that was created by DigiCert or Let’s Encrypt? Both are cryptographically signed and, therefore, both are totally legitimate. My browser certainly won’t complain about either one.
Aside from the confusion this can cause, poor security practises and attacks against CAs themselves have led to situations in which fraudulent certificates are created for domains that look every bit as authentic as a genuine one. In August 2011, it was discovered that Dutch certificate authority DigiNotar suffered a breach, and attackers were able to fraudulently generate a wildcard certificate for *.google.com.1 This allowed the attackers to impersonate virtually any Google property without web browsers displaying the usual warnings about invalid certificates.
In fact, due to security breaches, a long list of certificate authorities have been ejected from the list of CAs trusted by web browsers, with Symantec being one of the latest casualties.1 Figure 2 shows the number of significant breaches related to PKI and root certificates2 that have occurred over the past two decades.
And with so many root and intermediate certificate authorities, it’s hardly surprising we have occasional problems. The Mozilla-managed Common CA Database lists 142 root certificate authorities and over 2,200 intermediate certificate authorities.1 All of which are permitted to sign a certificate for any site.
Clearly, we, as an industry, need to better monitor these certificate authorities. Organisations need to be made aware if a CA has mistakenly or maliciously created a certificate without the express permission of the owner of that domain. If such a certificate has been created, it may be used to impersonate genuine websites, carry out man-in-the-middle attacks, and facilitate phishing attacks.
What is Certificate Transparency?
Certificate Transparency (CT) is a method for publicly logging, auditing, and monitoring the creation of new SSL/TLS (digital) certificates. Originally a concept from Google, CT is now an open standard under RFC 6962, albeit still an experimental one.1 Originally designed to enhance the veracity of Extended Validation (EV) certificates, many certificate authorities now voluntarily log all certificates, even Domain Validation (DV) ones. (Far more common, DV certificates verify only the domain name and therefore provide a lower level of trust than EV certificates, which verify the existence and location of the entity requesting the cert and that the entity controls the domain.)
Using cryptographic hashing, similar to cryptocurrency's blockchain protocols, CT creates a ledger of all created or observed certificates. While the logs are not distributed, as with many blockchain protocols, they are made public, allowing anyone to query for the existence and validity of a certificate. Web browsers can query CT logs in real time to determine if the site they are connecting to has a certificate that exists in the log. Organisations can monitor logs to spot the creation of certificates that contain their domain or brand name. Finally, security researchers can use it to monitor for fraud and phishing sites.
The CT infrastructure is made up from three building blocks. Certificate log services, which log the creation of new certificates, and Merkle hash trees to provide cryptographic proofs. Certificate monitors are services which can query log services for specific logs or search for any containing specific names. Finally, the auditors. These are the clients, typically web browsers, that ask for and verify the signed proof that the certificate it is receiving exists in a CT log. Each represents a discrete service that is usually operated by different entities.
As shown in Figure 5, here’s how the CT process works:
- A website operator requests a new certificate from a certificate authority.
- A CA creates a preliminary certificate and asks the log service to verify its validity and provide it with a signed certificate timestamp (SCT).
- The log service records the new certificate into the Merkle tree and sends back the SCT.
- With the SCT, the CA sends back the newly created certificate to the website operator.
- Customers visit the website as usual and, at this point, have a number of means of verifying the existence of the certificate in the CT logs.
- The website operator, or any organisation with a vested interest, may query log servers at any time to discover the creation of new certificates.
As new certificates are requested by web site operators, the CA inserts a new entry into the append-only log. According to the official CT list, there are currently 74 log servers being run by 19 different operators, including Google, DigiCert, Let's Encrypt, Cloudflare, and many more.1
Certificate monitors look for suspicious activity in logs, including unauthorised certificates and certs generated with suspicious extensions such as “certificate authority” certificates, (for example, “root”).
Certificate auditors use cryptographic methods to ensure that certificates are only ever added to the logs and that deletions from the log are detected.
Thanks to Certificate Transparency, it’s possible to quickly search for certificates that have a specific property, such as a well-recognised brand name in their Common Name field. A quick search on censys.io shows over 6,600 certificates with “paypal” contained within them. It’s safe to say that the overwhelming majority of these are not official and are being used for fraudulent purposes.
When first created by Google, CT was only used to log and monitor Extended Validation (EV) certificates. Because EV certs provide the highest level of assurance (as mentioned earlier, EV requires verification of location and domain ownership), they were viewed as the most important to protect. In fact, Google's Chrome web browser marks a site as insecure if an EV certificate is presented by a web server that does not exist in the CT logs.
Today, however, many certificate authorities, including Let’s Encrypt, choose to publish all their Domain Validation (DV) certs into the CT logs. This is fortunate news since Let’s Encrypt is so often used by attackers to create short-lived certs for fraudulent domains.
How Do I Know if a Website Is Using Certificate Transparency?
CT is designed to be invisible to the end user, but should you want to investigate whether a particular site uses it, a simple way to check is to head over to the excellent ssllabs.com Server Test tool.1 There are three supported methods for delivery of the signed certificate timestamp (SCT). A new certificate can be created with the SCT embedded into it. This is arguably the least disruptive option, albeit potentially the most expensive. Alternatively, the SCT can be delivered via an extension to the TLS handshake, or it can be sent from the webserver as part of the OSCP stapling response.
The results of the Server Test page will not only show you whether CT is being delivered by TLS extension, OCSP response, or whether it has been embedded in the certificate. A look at the result for f5.com shows that the certificate has CT information embedded within the certificate.
While the TLS extension and OCSP methods are preferred as they allow existing certs to use CT without reissuing, embedding the signed certificate timestamp into the certificate is technically an easier solution since there is no dependency on support from the webserver.
How to Get Started with Certificate Transparency
CT is still an experimental protocol, albeit a promising one. As a result, getting started has a fairly steep learning curve. Anyone can create their CT monitoring service but, if your interest is simply to use the protocol to help protect your brand, by far the easiest approach is to make use of a public tool that performs constant certificate monitoring on your behalf.
Google and Facebook both have free web-based tools that you can use to monitor and get alerted to new certificates that have been created using your domain name.1, 2 The Facebook tool, in particular, has a nice feature that allows you to subscribe to alerts for a domain that you would like to monitor. The major caveat is that there is currently no method to query these tools for the appearance of your brand name anywhere in the certificate name. While the tools will look for new subdomains off your primary domain, your domain must be the at the top level. For example, you can monitor the logs for example.com or another.example.com but not example.com.badguy.com.
For organisations that need to monitor CT logs for any inclusion of their domain or brand name, there are a few choices. Those with teams big enough to monitor CT manually can make use of Censys.io, although there will be considerable effort to parse out false positives.3 Enterprise customers of sslmate.com can sign up to a monitoring service which allows use of regular expressions. The example in Figure 7 creates a watch list that searches for ‘yourbrandname’ and ignores character case.
Conclusion
The addition of Certificate Transparency to your proactive monitoring tool bag adds a significant capability in the fight against phishing. However, it's important to recognise what CT can't do. If scammers are making use of obfuscated domains with purposeful typos, it is currently very hard to use CT logs to identify these. Creating your own tools to query CT monitors with complex regex expressions may be the only option.
Additionally, CT cannot prevent rogue certificates from being generated in the first place. The relatively new “CAA” DNS record can help stop unauthorised CAs from generated certificates for your domain. We'll be looking at CAA records in our next article.
For a more detailed read on the cryptography and architecture behind Certificate Transparency, head over to the official Google-maintained CT site: https://www.certificate-transparency.org/how-ct-works.
