对于证书吊销,存在着哪些方面的矛盾?
发布日期:2019-06-19对于证书的有效期,在两方面存在着矛盾,那就是人们既希望减少管理的成本又需要证书可以提供更多的更新信息。理论上来讲,在被认为可信之前,每张证书都需要检查吊销信息。但是在实际中,存在着大量的问题使得证书吊销变得很困难。
客户端支持不足
可以这样说,对于证书吊销的最大问题在于客户端的支持不足。你要么根本不需要证书吊销, 要么严重依赖它,这使得情况变得更加糟糕。因为这样一来,总是可以“推迟”对它的处理。
我们很难了解到浏览器在处理吊销的时候做了哪些事情,包括什么时候检查吊销以及如何检 查。因为没有文档,只能依赖挖掘邮件列表、bug报告以及阅读源代码来理解究竟发生了什么。 例如,有轶事证据表明浏览器不会对中间证书进行吊销检查。在很长的时间里,我们并不清楚很 多浏览器并不使用CRL(证书吊销列表)。对于新特性(例如OCSP stapling)的支持也是缓慢的。 总结起来,这个领域就是一个大黑盒。通过测试也许可以得到一些答案,但是这只在某个时间点 有效,对于某个产品的下个版本是否还是会有相同的行为则无法保证。
除了浏览器之外,命令行工具仍然深陷证书验证的泥潭,更无暇估计吊销的问题。并且因为大多数的SSL库默认不使用吊销检查,开发人员一般也就不会关心它了。
最后总结起来,就是由于这样或那样的原因,证书吊销没有起到应起的作用。 这种情况在2011年变得异常明显,当时有几个CA遭到入侵。在每个案例中,唯一有效的吊销欺诈证书的方法就是使用黑名单,但不是通过CRL或者OCSP。相反,所有的浏览器厂商通过 发布补丁版本来解决问题,这些版本中包含对于欺诈证书的硬编码信息。Chrome、Firefox和 Microsoft使用了特殊的机制来向浏览器推送证书黑名单,而不需要用户进行软件升级。
吊销检查标准的主要问题
从高层次来看,CRL和OCSP两者均存在设计上的缺陷,这使得它们的用处变得不大。这里主要有以下三个问题。
一、证书与查询之间不关联
CRL和OCSP基于序列号来查找证书,这些序列号就是CA随意分配的一些数字。这很不幸, 因为你无法确保你查询的证书就是CA所查询的证书。这种情况可以在CA遭受攻击之后被 利用来创建伪造的证书,并让此伪造的证书包含一个现有的有效证书的序列号。
二、黑名单而不是白名单
从定义上来讲,CRL是一个黑名单,不能是其他东西。诞生于CRL之后的OCSP,在CRL框架之上被设计出来,目的是更加容易使用。早些年,OCSP响应程序通过添加CRL中存在的信息来进行工作。这错失了一次从黑名单切换到白名单的机会,包括检查证书是否有效,而不仅仅是检查是否吊销。 对于黑名单的关注最终引起反响的是将“正常”的OCSP响应状态视为“未吊销”这一实践, 即使在服务器并不知道序列号问题的情况下。在2013年8月,CAB论坛禁止了这一实践。 这听起来有一些区别,但是这个设计上的缺陷的确在DigiNotar事件期间造成了一个真正的问题。因为这个CA被完全攻破了,没有任何关于哪些欺诈证书被签发了的记录。这样一来,这个CA的证书无法被单独吊销。虽然最终DigiNotar的根证书被所有的浏览器移除, 作为一种短期的处理方法,他们的OCSP响应程序被配置成了向所有他们的证书返回“已吊销”。
三、 隐私
CRL和OCSP都遭受到隐私问题的困扰:当你向一个CA获取吊销信息的时候,你向它暴露了关于你的浏览习惯的一些信息。在CRL情况下泄露信息的可能性比较小,因为CRL通常 都含有大量的证书。 对于OCSP,隐私问题是真实存在的,导致了很多其他的问题。如果一个强有力的攻击者希望观察所有人的浏览习惯,将很容易地通过对一些或者几个主流的OCSP响应程序的观察来实现,而不需要窃听整个世界的真正流量。
为了解决这个问题,网站应该部署OCSP stapling,这是一种让网站可以响应OCSP的机制。 使用这种方法,用户不再需要与CA交互,也就没有了信息的泄露。
内容摘自《HTTPS权威指南》,如有侵权请联系删除。
相关内容
沃通作为国内领先的SSL证书签发CA,早在2014年就已经开始了采用国密算法签发SM2 SSL证书的研究,并取得了可喜的研究成果。我们充分认识到国密SSL证书要达到实用和大量部署使用还需要相关系统的支持,如浏览器和服务器软件。同时,还要考虑到其通用性与全球性,即网站用户可能使用各种不同的浏览器和用户来自世界各地。所以,我们一直在持续研究基于国密算法实现https网站加密的完整解决方案。
国密浏览器需要遵循国密SSL协议规范GM/T 0024-2014。 GM/T 0024-2014没有单独规范 SSL协议的文件,而是在SSL VPN技术规范中定义了国密SSL协议。国密SSL协议(SSL VPN协议)包括握手协议、密码规格变更协议、报警协议、网关到网关协议和记录层协议。