When people lose their keys or buy a new home, they change their locks and switch to using a new key. Similarly, when website operators lose their cryptographic keys or buy a new domain name, they acquire a new web certificate (a Transport Layer Security (TLS) certificate) to prevent impersonation of their domain and interception of their encrypted HTTP over TLS (HTTPS) connections.
Unlike replacing physical locks and keys, though, disowned cryptographic keys often continue to function. This blog post discusses why this happens and how it can lead to potential security issues.
Stale TLS Certificates: A Caching Problem
To get a TLS certificate, a website operator must prove to a certificate authority (CA) that they control their domain’s web server via a challenge-response exchange.
Once control has been established, the CA issues a signed TLS certificate that links the web server’s domain name to its public cryptographic key. To avoid constant re-verification of web server control, certificates are assigned a validity period or cache duration that indicates how long the domain-to-key mapping is valid.
If the validity period of the certificate is too short, CAs incur additional operational costs from re-verifying web server control and re-issuing certificates. If it is too long, a certificate can become stale–no longer representing the real-world domain-to-key mapping–and allow an adversary to impersonate someone else’s domain.
Discover how popular enabling technologies such as TLS1.3, DNSSEC, and HTTP/3 are becoming globally.
HTTPS Website Spoofing
Let’s look at HTTPS, the web’s primary security protocol, to understand how stale certificates can be problematic. HTTPS uses TLS certificates to authenticate web servers and detect when third parties try to spoof a website. In other words, only the actual operator of example.com should be recognized by a browser as https://example.com.
Stale certificates can break HTTPS server authentication by enabling a third party to spoof a TLS connection for someone else’s domain. Here’s one example of how this can happen:
- Mallory acquires the domain foo.com
- Mallory acquires a certificate for foo.com that is valid for one year.
- Mallory immediately transfers/sells the domain to someone else. Mallory can now impersonate foo.com while her certificate is valid.
My colleagues and I at Oregon State University, Georgia Institute of Technology, and Stanford University recently investigated three forms of third-party staleness — see our paper.
We found that over the last ten years, more than 4 million domains (>1,000 per day) had stale third-party certificates. These domains comprise popular (61 in the Alexa Top 1K websites) and unpopular domains, and the number of stale certificates has grown yearly.
While we could not infer whether these vulnerable domains were actively exploited, the magnitude of exposure highlights the importance of mitigating third-party stale TLS certificates.
| Date Range | # Certs / day | # Fully Qualified Domain Names/day | #Second-Level Domains/day | |
|---|---|---|---|---|
| Key compromise | 2021-2023 | 493 | 787 | 347 |
| Domain owner change | 2013-2021 | 2,593 | 2,807 | 1,214 |
| Managed TLS change | 2022 | 9,495 | 18,833 | 7,722 |
Potential Mitigations
The seemingly obvious way to mitigate stale certificates is to invalidate them through revocation. However, this runs into several obstacles, including:
- Not all HTTPS clients (for example, command line utilities and mobile applications) support revocation.
- Some revocation support is limited in scope (for example, Chrome/Chromium CRLSets) or leads to soft fails, which renders revocation useless against an intercepting attacker.
- Revocation is poorly used since it is ineffective and/or difficult to manage.
Coordinating with TLS participants to overcome these challenges could significantly reduce the prevalence of stale certificates. But a more accessible option is to shorten certificate validity periods.
The CA/browser community has been moving in this direction: maximum certificate lifetimes decreased to 825 days in 2017 and 398 days in 2020. Despite this security improvement, stale third-party certificates (and affected domains) have multiplied since 2017.
Reducing maximum lifetimes to 90 days, which several major CAs (for example, Let’s Encrypt) already self-enforce, could eliminate up to 75% of third-party staleness.
Figure 2 – Reducing the maximum certificate validity to 90 days would eliminate 75%+ of third-party staleness.
Taking a longer view, the root cause of certificate staleness is the current design of certificate-based website authentication, which attempts to bridge independent domains, web servers, and certificate lifecycles. A more fundamental solution is to decrease the network dependency chain between domain names and their corresponding cryptographic keys, thus reducing unintentional or malicious dependency fracturing opportunities.
Proposals such as DNS-Based Authentication of Named Entities (DANE), Content-Centric Networking (CCN), and Named Data Networking (NDN) align cryptographic keys with the authoritative source for name information, thus empowering name operators and minimizing authentication caching concerns.
To learn more, read our paper ‘Stale TLS Certificates.’
Zane Ma is an assistant professor at Oregon State University. He researches Internet security, focusing on user, web client, and server authentication.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of the Internet Society.