This is the blog version of my DEFCON 26 talk Lost and Found Certificates: dealing with residual certificates for pre-owned domains, which I co-presented with Dylan Ayrey.
You can learn more about BygoneSSL and see a demo at insecure.design.
The Problem
A Certificate can outlive the ownership of a domain.
If the domain is then re-registered by someone else, this leaves with the first owner with a valid SSL certificate for the domain now owned by someone else.
The above diagram illustrates an example where Alice registers foo.com for 1 year, and gets a 3 year SSL certificate from a trusted Certificate Authority. Alice then decides not to renew the domain (or possibly forgets) and after one year the domain expires. Some time later Bob registers foo.com and because Bob is on top of all the latest security trends, he also gets a SSL certificate to protect the traffic to his new domain. Little does he know, that Alice, malicious or not, still has a valid SSL certificate for what is now Bob’s domain. This is a problem we are calling BygoneSSL.
What can Bob do?
Until recently it was not even possible for Bob to determine if there exists prior certificates for his domain. However, now we have Certificate Transparency.
Certificate Transparency
Certificate Transparency (CT) was designed to catch bad or misbehaving Certificate Authorities (CAs). Anyone can run a CT Log server, which is a publicly auditable log of certificates that anyone can submit to. At the time of writing there are about 1/2 billion certificates in public CT logs and growing.
CT is required for all certificates issued after April 2018 to be trusted. Many certificates issued before April are also in the logs, but is is not requires.
For more information on Certificate Transparency, see my CertGraph post or the Certificate Transparency site.
Finding Pre-existing Certificates
Knowing the registration date of a domain, you can search CT logs for certificates issued before the registration date, and valid after. However there is no guarantee that all Certificates issued before April 2018 will be found. So you may not have a complete picture, but it is as close as we can get.
An Example: stripe.com
stripe.com is an excellent example of this. Stripe is a major online payment processor. They acquired their domain name in 2010 from a domain parking service. However there exists a certificate issued in 2009 that is valid until 2011, over a year into Stripe’s ownership of stripe.com.
Why is this a problem?
Well, aside from the fact that the previous domain owner could Man-in-the-Middle the new domain owner’s SSL traffic for that domain, if there are any domains that share alt-names with the domain, they can be revoked, potentially causing a Denial-of-Service if they are still in use. More on this below.
BygoneSSL Definition
noun A SSL certificate created before and supersedes its domains’ current registration date.
BygoneSSL Man in the Middle
If a company acquires a previously owned domain, the previous owner could still have a valid certificates, which could allow them to MitM the SSL connection with their prior certificate.
The above stripe.com is an example of a potential BygoneSSL Man in the Middle.
BygoneSSL Denial of Service
If a certificate has a subject alt-name for a domain no longer owned by the certificate user. It is possible to revoke the certificate that has both the vulnerable alt-name and other domains. You can DoS the service if the shared certificate is still in use!
Revoking
The CA/Browser Forum, which sets the rules by which Certificate Authorities and Browsers should operate, states that if any information in a certificate becomes incorrect or inaccurate, it should be revoked. Additionally if the domain registrant has failed to renew their domain, the CA should revoke the certificate within 24 hours.
DoS example: do.com
do.com has had many owners in the past few years, some of which added the domain to their SSL certificates. However in this particular case, the certificate hosting salesforce.com listed do.com as an alt-name. Even after do.com was transferred to another owner.
Due to the regulations set by the CA/B forum, this certificate could be revoked, causing downtime for the users of salesforce.com.
The above screenshot is of CertGraph, a tool I wrote to identify related domains through linked certificate alt-names; showing how salesforce.com is linked to squarespace.com through the do.com alt-name in the certificate past Salesforce’s ownership of the domain.
How big is this issue?
In order to get an idea of how many BygoneSSL certificates might still be out there We performed an analysis on over 3 million random domains and their 7.7 million SSL certificates. This sample makes up about 1% of the internet’s domains.
To determine if a domain has been transferred, We searched historical WHOIS, Name Servers, and the WayBack Machine. Since there are many reasons a domain’s WHOIS, Name Servers, or site may change, We intentionally weighted the algorithm to favor false negatives over false positives. It is not perfect, there are MANY false negatives and quite a few false positives, but it does give a glimpse into the scale of the problem.
Domains Directly Affected (MitM)
A domain is directly affected if there exists a certificate that was created before its registration date, and valid after. In the random sampling of domains studied, We found that 0.45% meet this criteria. This might seem like a small number, but the internet is huge which puts this at around 1.5 Million domains. Of the certificates sampled that are affected, 25% are still valid and can be used today by the prior domain owner.
Domains Affected by Alt-Names (Dos)
A domain is affected by an alt-name if it shared a certificate with a domain that is directly affected. These domains can be Denial of Serviced like the above do.com example. Of the domains studied, 2.05% are affected by sharing a certificate with an alt-name. This is represents 7 Million domains on the entire internet, a 4x increase over the previous MitM finding. Of the certificates affected, 41% are still valid. Meaning they can be revoked and if still in use will cause breakage!
What should be done about this?
If you find a certificate that is still in use that has an alt-name that is no longer under control of the certificate owner you should notify them. Bonus points if they have a bug bounty and you mention BygoneSSL. If not, how much notice should you give? The CAs should revoke in under 24 hours of being notified; however many of them take up to weeks, so it is best to give as much notice as possible to prevent being disruptive.
Protecting your own Domains
First search CT for BygoneSSL certificates for your domains. If you find any, reach out to the issuing CA’s and request that they be revoked. If the certificates have alt-names that are still in use, you should give the other domain owners a heads up as well in case they are still using the certificates.
Next you should setup your servers to use the Expect-CT header in enforce mode to prevent any SSL certificates that are not in CT from being valid for your domains. Unfortunately this will only work for visitors whose first connection to your site is not MitM. Next you need to continue monitoring CT logs in case an older cert gets added later. Certificates can be added to CT logs at any time, not just when they are issued. Be sure to check for alt-names as well. You don’t want someone sitting on a certificate to start using it once they submit it years later. We’ve written a few tools to help you do this mentioned in the next section.
Fixing the problem for the Internet
It would be great if domain registrars did not issue certificates valid for longer than the current domain’s registration. If you could not get a SSL certificate for longer than your domain registration this problem is drastically reduced, excluding transfers, which the new domain owner should expect that the prior owner may have a pre-existing certificate.
CA’s should only issue short-lived certificates. We are making progress on this. New 10 and 5 year certificates are no longer valid. The current maximum life for a certificate is 825 days, which is just over 2 years. There is ongoing work to reduce this even further, with Let’s Encrypt leading the way with 90 day certificates!
Domain registrars could show you pre-existing valid certificates logged in CT when registering or transferring a domain. This gives the domain owner visibility into the potential BygoneSSL certificates that may exist before they could do any damage.
Tools
CertGraph
CertGraph can also be used to detect BygoneSSL MitM and Dos. For MitM use certgraph normally and look for cases where your graph of domains reached domains or certificates that you do not control.
For DoS, use certgraph with the following options:
certgraph -depth 1 -driver google -ct-subdomains -cdn [DOMAIN]...
A future version of CertGraph will include a -bygonessl flag to automate this and add more features, such as domain availability checks.
CertSpotter
CertSpotter is a free and open source Certificate Transparency Log Monitor by SSLMate. I’ve added support for detecting BygoneSSL certificates and got it merged upstream. It works the same, but you can add a valid_at date to the watch-list.
For example, the following watch-list would find the BygoneSSL certificate for insecure.design registered on April 18th 2018.
insecure.design valid_at:2018-04-18
defcon.org valid_at:1993-06-21
wikipedia.org valid_at:2001-01-13
toorcon.net valid_at:2012-03-13
Since this is a full Certificate Transparency Log Monitor. It will take some time to go through the backlog of certificates on the remote logs on its first run.
BygoneSSL Facebook Search Tool
Dylan also wrote a similar tool to search Facebook’s Certificate Transparency Monitor. It requires Facebook OAuth, but is much faster because it does not need to inspect an entire log. You can find it here: https://github.com/dxa4481/bygonessl.
