TY - GEN
T1 - Is the Web Ready for OCSP Must-Staple?
AU - Chung, Taejoong
AU - Lok, Jay
AU - Chandrasekaran, Balakrishnan
AU - Choffnes, David
AU - Levin, Dave
AU - Maggs, Bruce M.
AU - Mislove, Alan
AU - Rula, John
AU - Sullivan, Nick
AU - Wilson, Christo
PY - 2018
Y1 - 2018
N2 - 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.
AB - 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.
KW - Public Key Infrastructure
KW - PKI
KW - HTTPS
KW - OCSP
U2 - 10.1145/3278532.3278543
DO - 10.1145/3278532.3278543
M3 - Conference contribution
SN - 9781450356190
T3 - IMC '18
SP - 105
EP - 118
BT - Proceedings of the Internet Measurement Conference 2018
PB - Association for Computing Machinery
CY - New York, NY, USA
ER -