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.