你不在意的HTTPS证书吊销机制
|
在2015年，Firefox 37开始，针对中级证书的检测，Mozilla也启用了自研的证书吊销状况检查机制OneCRL来代替OCSP机制，目的还是想解决CRL、OCSP机制的缺点。而中级证书是不能采用OCSP stapling方式，不允许被缓存的。所以…还有，RFC 6961 defines a mechanism for stapling OCSP responses for CA certificates. Since FIrefox does not rely on OCSP to validate intermediate certificates, we have no plans to implement support for this. Firefox 官方短期内并无支持Multi-staple的打算。 域名证书的吊销状态验证 在Firefox的官方WIKI上，提到针对域名证书的吊销验证分为如下5个方案：方案一：Short-Lived Certificates，默认情况下，针对有效期少于10天的证书，直接跳过验证，认为不安全。可以在security.pki.cert_short_lifetime_in_days参数里配置。方案二：OCSP Stapling，跟RFC规范一样。如果security.OCSP.enabled的值为0，则忽略OCSP response。方案三：OCSP Must-staple，跟RFC规范一样。可以通过设置security.ssl.enable_ocsp_must_staple或security.ssl.enable_ocsp_stapling 参数来禁用。 方案四：OCSP，跟RFC规范一样。如果OCSP的响应在2秒(EV证书是10秒)内没返回，则直接忽略。 方案五：CRLite，类似Chrome CRLSets的一种检测机制，用于OCSP、OCSP stapling失败后的机制。Firefox的官方计划把这种机制作来代替CRL方式作为主要的检测机制(OCSPOCSP stapling失败后)。 4. Chrome 2012年，Chrome禁用了CRLs、OCSP检测: Google Chrome Will No Longer Check for Revoked SSL Certificates Online ，使用了自行设计的证书校验机制 CRLSets 那么，Chrome这么选择的理由是什么呢?显然，通过上面CRL跟OCSP两种验证方式的比较来看，前者时效性不行，后者影响性能。那么，google Chrome就决定自建证书吊销状态验证系统。Chrome的安全工程师Adam Langley在他的BLOG上写了一篇文章：《Revocation checking and Chrome’s CRL》，对于Chrome的HTTPS证书验证这块，Adam Langley可是非常有看法的，非常反对使用CRL、OCSP的方式来校验证书吊销状态，连续写了好几篇关于证书吊销状态检测的文章，同时，也在chromium的开发者主页上的安全板块有提到【What’s the story with certificate revocation?】：Chrome’s primary mechanism for checking the revocation status of HTTPS certificates is CRLsets.Chrome also supports Online Certificate Status Protocol (OCSP). However, the effectiveness of OCSP is is essentially 0 unless the client fails hard (refuses to connect) if it cannot get a live, valid OCSP response. No browser has OCSP set to hard-fail by default, for good reasons explained by Adam Langley (see [Revocation still doesn’t work](No, don’t enable revocation checking) and https://www.imperialviolet.org/2014/04/19/revchecking.html). Stapled OCSP with the Must Staple option (hard-fail if a valid OCSP response is not stapled to the certificate) is a much better solution to the revocation problem than non-stapled OCSP. CAs and browsers are working toward that solution (see the Internet-Draft: http://tools.ietf.org/html/draft-hallambaker-tlssecuritypolicy-03). Additionally, non-stapled OCSP poses a privacy problem: in order to check the status of a certificate, the client must query an OCSP responder for the status of the certificate, thus exposing a user’s HTTPS browsing history to the responder (a third party). That said, you can use enterprise policies to enable soft-fail OCSP (http://www.chromium.org/administrators/policy-list-3#EnableOnlineRevocationChecks) and hard-fail OCSP for local trust anchors (http://www.chromium.org/administrators/policy-list-3#RequireOnlineRevocationChecksForLocalAnchors). Chrome performs online checking for Extended Validation certificates if it does not already have a non-expired CRLSet entry covering the domain. If Chrome does not get a response, it simply downgrades the security indicator to Domain Validated. See also this bug for more discussion of the user-facing UX: https://crbug.com/361820. 但这也不是完美解决了这个问题，来自【An Evaluation of the Effectiveness of Chrome’s CRLSets】： This means that Chrome’s CRLSet, which currently lists the serial numbers of 24,206 revoked certificates, reflects only 1.08% of the revoked certificates collected by Websense in one hour. （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
