The Evolving Landscape of Certificate Revocation
AI created, human edited.
In a recent episode of Security Now, hosts Steve Gibson and Leo Laporte delved deep into the complex and evolving world of certificate revocation. Their discussion shed light on the ongoing challenges faced by the web security community in managing compromised or untrusted SSL/TLS certificates.
The conversation kicked off with Gibson recounting his experiment with the "revokedgrc.com" website, which he used to demonstrate the effectiveness (or lack thereof) of current certificate revocation methods. This practical example set the stage for a broader examination of how certificate revocation has evolved over the past decade.
Gibson explained the concept of OCSP (Online Certificate Status Protocol) stapling, a method introduced to improve upon earlier revocation checking systems. With OCSP stapling, web servers attach (or "staple") a recent, signed OCSP response from the certificate authority to the certificate they serve. This approach addresses several issues:
Reduced latency for clients
Improved privacy by eliminating the need for clients to query OCSP servers directly
Decreased load on certificate authorities' OCSP servers
However, as Gibson's experiment revealed, OCSP stapling isn't a perfect solution. The cached OCSP responses typically have a lifespan of about a week, meaning that a revoked certificate could potentially be trusted for up to seven days after revocation.
The hosts then discussed a recent announcement from Let's Encrypt, the certificate authority responsible for nearly 60% of web certificates. Let's Encrypt declared its intent to end OCSP support in favor of Certificate Revocation Lists (CRLs). This move marks a significant shift in the industry, potentially affecting millions of websites.
Let's Encrypt cited several reasons for this change:
Privacy concerns associated with OCSP
Resource intensiveness of maintaining OCSP services
The emergence of browser-specific CRL implementations
Interestingly, the industry appears to be coming full circle, returning to CRLs after years of favoring OCSP. However, this isn't a simple regression. Modern browsers are implementing proprietary CRL systems that aim to address the shortcomings of traditional CRLs:
Centralized downloading and processing of CRLs by browser vendors
Compression of CRL data (e.g., using Bloom filters)
Frequent updates pushed to browsers (as often as every six hours)
Gibson and Laporte discussed how these new approaches, combined with shorter certificate lifetimes and increased bandwidth availability, could make CRLs more viable than they were a decade ago.
Despite these advancements, both hosts acknowledged that certificate revocation remains a complex issue. The transition back to CRLs imposes new burdens on browser vendors, who must now collect and merge CRLs from numerous certificate authorities.
Gibson expressed interest in revisiting his "revokedgrc.com" experiment in the future to test the effectiveness of these new revocation systems. Meanwhile, Laporte emphasized the ongoing nature of this "tough computer science problem," highlighting that there's no easy answer in sight.
The discussion on Security Now underscores the dynamic nature of web security. As the internet evolves, so too must our approaches to maintaining its safety and integrity. The shift from OCSP back to modernized CRLs represents just one chapter in the ongoing story of how the tech community strives to balance security, privacy, and performance in an ever-changing digital landscape.
As we move forward, it's clear that certificate revocation will remain a critical topic in web security discussions. Whether the new CRL-based approaches will prove more effective than their predecessors remains to be seen, but one thing is certain: the quest for a perfect revocation system continues.
Subscribe to Security Now and keep independent tech journalism alive!
