10-21, 14:00–14:25 (US/Eastern), ENG 103
The web public key infrastructure is used to secure HTTPS connections between browsers and websites using certificates. Today, when something goes wrong, browsers can't reliably find out those certificates have been revoked. We examine past and future solutions to this problem, and how we can make progress on fixing revocation.
This talk covers the history of the protocols used to communicate web pki revocation, including CRLs and OCSP, discusses why they have been ineffective. Then goes over future improvements that are ongoing now to make certificate lifetimes shorter, revive CRLs with new distribution and compression mechanisms. It discusses why new solutions might work where previous attempts like OCSP stapling failed.
- Introduction and Background
- What is the web PKI, how we use certificates, and what it means to revoke them
- Introduce central problem with revocation
- Websites serve a certificate, and they choose which CA to get it from.
- Clients need an out-of-band check for revocation
- That can be a privacy problem.
- Certificate Revocation Lists (CRLs)
- Explain what CRLs are: A public list of revoked certs
- Operational issues: Clients need to download and store too much data
- Privacy analysis: Requires IP connection, doesn’t (usually) leak which certificates you’re interested in
- Adoption: Largely not used by browsers today.
- Online Certificate Status Protocol
- Explain what OCSP is: API to ask CA if a certificate is valid
- Operational issues: High uptime requirements, many signatures needed, most implementations forced to fail-open
- Privacy analysis: It’s bad. Reveals exactly what certificates a client is interested in
- Adoption: Some browsers, not all, primarily due to privacy concerns.
- OCSP Stapling
- Explain what OCSP Stapling is: TLS handshake includes OCSP response “stapled” on
- Operational issues: Requires server operators to participate. Explain why that’s hard.
- Privacy analysis: Fixes nearly everything wrong with OCSP privacy. It’s great.
- Adoption: Low. “Must-staple” making this mandatory is near zero. Explain why nearly nobody uses this.
- Browser-vendor revocation information services
- Explain how browsers may have proprietary services that distribute revocation information
- Mozilla’s CRLite uses Certificate Transparency and bloom filters to create compact data structures that can be pushed to browsers.
- Other browsers may be working on something similar, but not very publicly yet.
- Operational issues: Requires a new player, the Browser or OS vendor, to participate.
- Privacy analysis: Requires phoning home to the browser vendor. But leaks no additional information to the CA. Pretty good.
- Adoption: This is the up-and-coming option some browser vendors are working on now. Will likely be very high soon.
- Explain how browsers may have proprietary services that distribute revocation information
- Short-lived Certificates
- Explain what makes a certificate “short lived” and why we want that
- Operational issues: Server operators need to renew certificates automatically and continuously. CAs need to support much higher certificate volumes.
- Go into a bit more detail here about how fast the options above are, and how simply reducing certificate lifetime can be comparable
- Privacy analysis: Great. No online service needed.
- Adoption: Minimal, though CA/Browser forum ballot from Chrome to increase adoption.
- Explain how this can be combined with other options above to improve them, by reducing how long certs stay expired.
- Conclusion
- Past solutions were not adopted due to privacy or efficiency concerns, decreasing security
- This is still a problem that isn’t fully solved, and requires more engineering
- Future solutions are on the horizion, but have adoption problems
