Presentation Material
Abstract
Certificate revocation is a messy problem; certificate revocation lists and mid-handshake OCSP checks have proven unworkable in practice. The dream of TLS certificate revocation is Must-Staple: an extension in a certificate indicating that it can only be used alongside a stapled OCSP (Online Certificate Status Protocol) response indicating that the certificate hasn’t been revoked. If a Must-Staple certificate is compromised, the attacker can only use it for the short time window until the current OCSP response expires. But is the world ready for Must-Staple yet? Unreliable OCSP servers, buggy stapling implementations, and client and network misconfigurations (from mismatched clocks to MITM proxies) all present challenges. This talk examines the state of the world of OCSP stapling and describes Dropbox’s implementation of OCSP Stapling. To gather real data on the feasibility of deploying OCSP stapling, we will discuss the data we gathered from a Chrome feature called Expect-Staple, which is a report-only version of OCSP Must-Staple that lets us evaluate how well OCSP Must-Staple might work in the real world.
AI Generated Summary
The talk addresses the fundamental problem of certificate revocation on the web, focusing on how to effectively communicate a revoked or compromised certificate to browsers when an attacker possesses a valid certificate for a domain. It outlines the critical threat scenario where a server operator’s private key is stolen, enabling an attacker to impersonate the site, and the subsequent need to revoke the associated certificate.
The presentation critiques existing revocation mechanisms. Certificate Revocation Lists (CRLs) are deemed inefficient due to their large size and the high cost of frequent downloads by clients. The Online Certificate Status Protocol (OCSP) provides per-certificate checks but introduces a network round-trip during connection setup, creating latency, privacy leaks (as the CA learns every site a user visits), and reliability issues where failed requests often result in browsers “failing open” and accepting the certificate anyway.
OCSP stapling is presented as the primary state-of-the-art solution. Here, the server proactively fetches a signed, time-stamped OCSP response from the CA and “staples” it to the TLS handshake. This eliminates the client-side latency and privacy concerns, improves reliability by moving the CA check out of the critical path, and reduces load on CAs. However, stapling is trivial for an attacker to omit if they are using a revoked certificate, rendering it ineffective against active adversaries.
The “Must-Staple” TLS extension is introduced as an enforcement mechanism. It flags a certificate as requiring a valid stapled OCSP response; browsers will reject connections lacking one. The talk emphasizes that widespread Must-Staple deployment is currently hindered by the high risk of operational errors. Misconfigured servers frequently fail to deliver a staple, causing user-facing connection errors that browsers are reluctant to show en masse.
A case study from Dropbox illustrates these deployment challenges. Their experience building an OCSP response fetching service highlighted complexities in ensuring freshness, validity, and high availability across large infrastructures. The talk concludes by describing Chrome’s experimental “Expect-Staple” feature, which allows sites to opt into receiving reports on staple failures without breaking connections. This provides operators with visibility to diagnose and fix issues before mandatory enforcement. The overall takeaway is that while technical solutions like stapling exist, solving web-scale revocation requires overcoming significant operational hurdles to avoid degrading user experience.