Is the Web Ready for OCSP Must-Staple?

Taejoong Chung, J. Lok, B. Chandrasekaran, D. Choffnes, Dave Levin, B. Maggs, A. Mislove, John P. Rula, N. Sullivan, Christo Wilson
{"title":"Is the Web Ready for OCSP Must-Staple?","authors":"Taejoong Chung, J. Lok, B. Chandrasekaran, D. Choffnes, Dave Levin, B. Maggs, A. Mislove, John P. Rula, N. Sullivan, Christo Wilson","doi":"10.1145/3278532.3278543","DOIUrl":null,"url":null,"abstract":"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.","PeriodicalId":20640,"journal":{"name":"Proceedings of the Internet Measurement Conference 2018","volume":null,"pages":null},"PeriodicalIF":0.0000,"publicationDate":"2018-10-31","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"36","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"Proceedings of the Internet Measurement Conference 2018","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1145/3278532.3278543","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 36

Abstract

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.
查看原文
分享 分享
微信好友 朋友圈 QQ好友 复制链接
本刊更多论文
网络准备好成为OCSP必备品了吗?
TLS是确保互联网通信安全的事实上的标准协议,它依赖于将名称绑定到公钥的证书层次结构。当然,为了从TLS的安全性中获益,确保通信各方只使用有效的证书是必要的第一步。为此,大多数证书和客户端都支持OCSP,这是一种用于查询证书的撤销状态并确认其仍然有效的协议。然而,不幸的是,OCSP因其缓慢的性能、不可靠性、软故障和隐私问题而受到批评。为了解决这些问题,引入了OCSP Must-Staple证书扩展,它要求web服务器在TLS握手期间向客户端提供OCSP响应,从而降低客户端的吊销检查成本。然而,是否网络PKI中的所有参与者都准备好支持OCSP Must-Staple,仍然是一个悬而未决的问题。在本文中,我们对网络的PKI进行了广泛的研究,并确定是否所有涉及的组件——即证书颁发机构、web服务器管理员和web浏览器——都准备好支持OCSP Must-Staple。我们发现每个组件还没有完全支持OCSP必须订阅:OCSP响应器仍然不完全可靠,大多数主要的web浏览器和web服务器实现都不完全支持OCSP必须订阅。好的一面是,只有少数玩家需要采取行动,使web服务器管理员能够开始依赖OCSP Must-Staple证书。因此,我们相信更广泛地部署OCSP必备品是一个现实的、可以实现的目标。
本文章由计算机程序翻译,如有差异,请以英文原文为准。
求助全文
约1分钟内获得全文 去求助
来源期刊
自引率
0.00%
发文量
0
期刊最新文献
Reducing Permission Requests in Mobile Apps A Look at the ECS Behavior of DNS Resolvers RPKI is Coming of Age: A Longitudinal Study of RPKI Deployment and Invalid Route Origins Scanning the Scanners: Sensing the Internet from a Massively Distributed Network Telescope Learning Regexes to Extract Router Names from Hostnames
×
引用
GB/T 7714-2015
复制
MLA
复制
APA
复制
导出至
BibTeX EndNote RefMan NoteFirst NoteExpress
×
×
提示
您的信息不完整,为了账户安全,请先补充。
现在去补充
×
提示
您因"违规操作"
具体请查看互助需知
我知道了
×
提示
现在去查看 取消
×
提示
确定
0
微信
客服QQ
Book学术公众号 扫码关注我们
反馈
×
意见反馈
请填写您的意见或建议
请填写您的手机或邮箱
已复制链接
已复制链接
快去分享给好友吧!
我知道了
×
扫码分享
扫码分享
Book学术官方微信
Book学术文献互助
Book学术文献互助群
群 号:481959085
Book学术
文献互助 智能选刊 最新文献 互助须知 联系我们:info@booksci.cn
Book学术提供免费学术资源搜索服务,方便国内外学者检索中英文文献。致力于提供最便捷和优质的服务体验。
Copyright © 2023 Book学术 All rights reserved.
ghs 京公网安备 11010802042870号 京ICP备2023020795号-1