Is the Web Ready for OCSP Must-Staple?

Taejoong Chung, Jay Lok, Balakrishnan Chandrasekaran, David Choffnes, Dave Levin,
Bruce Maggs, Alan Mislove, John Rula, Nick Sullivan, Christo Wilson

Paper Overview

TLS, the de facto standard protocol for securing communications over the Internet, relies on a hierarchy of certificates that bind names to public keys. Naturally, ensuring that the communicating parties are using only valid certificates is a necessary first step in order to benefit from the security of TLS. To this end, most certificates and clients support OCSP, a protocol for querying a certificate's revocation status and confirming that it is still valid.
Unfortunately, however, OCSP has been criticized for its slow performance, unreliability, soft-failures, and privacy issues. To address these issues, the OCSP Must-Staple certificate extension was introduced, which requires web servers to provide OCSP responses to clients during the TLS handshake, making revocation checks low-cost for clients. Whether all of the players in the web's PKI are ready to support OCSP Must-Staple, however, remains still an open question. In this paper, we take a broad look at the web's PKI and determine if all components involved---namely, certificate authorities, web server administrators, and web browsers---are ready to support OCSP Must-Staple. We find that each component does not yet fully support OCSP Must-Staple: OCSP responders are still not fully reliable, and most major web browsers and web server implementations do not fully support OCSP Must-Staple.
On the bright side, only a few players need to take action to make it possible for web server administrators to begin relying on certificates with OCSP Must-Staple. Thus, we believe a much wider deployment of OCSP Must-Staple is an realistic and achievable goal.

This paper was published at IMC'2018 (Internet Measurement Conference) and you can download our paper here

OCSP Dataset

Our goal is to understand how reliable CAs' OCSP responders are today. To do so, we first extracted all valid certificates from the Censys. After that we proceed as follows.
  1. We obtain (a) OCSP responders actively used today and (b) at most 50 certificates that are served from each of the OCSP responders.
  2. we issued OCSP requests using the HTTP POST method for all of the selected certificates (i.e., we performed an OCSP lookup for each certificate against its corresponding OCSP responder) every hour from April 25, 2018 to November 1, 2018
  3. We deployed our measurement client in six different vantage points around the world - Oregon, Virginia, Sao-paulo, Paris, Sydney, and Seoul (Amazon Web Services)
The dataset structure is a json format where the keys are self-explanatory.
We are still measuring OCSP responders by updating (unexpired) certificates on a monthly basis. If you are interested in collaborating with us, please contact our team.
Name (Vantage point) Type Size SHA-256 Hash (Uncompressed)
Oregon Json (tar.xz) 15 GB 3bec837ec1a68c9e0dec86808dc7a4ee4d5360ef6ff95932ca06e41701f71406
Virginia Json (tar.xz) 15 GB adeacad7321fee4394bdbaec639b9571940467f6049b4955e61431b83258d0ac
Sao-Paulo Json (tar.xz) 15 GB 2f9d4bd79f6797227de439cc50a4e00a0716979cb66ba580e0cd390ba1d566ab
Paris Json (tar.xz) 15 GB 3a6df50f0b06530569a28e5ad08ea7af239416dd15d3b026101c09c86c64f078
Sydney Json (tar.xz) 15 GB ab1893406903b8298682340f5ee8054cb925835d422d1bec73044532a9e93abf
Seoul Json (tar.xz) 15 GB d522b6f1d888ed0655ba336b9ab1ae072972f35659987c84cf1dfadec36a2cd8

Contact

Do you have any questions, comments or concern? Feel free to send us an email to Taejoong Chung