| What actions can a "site operator" take? Not sure what you mean by this. Are you asking what the system administrator of an arbitrary website can do? I'd start with stapling OCSP responses[0] to your TLS handshakes and refreshing them as often as they're updated by the CA. Note that just having the CAs respond to browser checks (CRL and OCSP) is more or less useless as they're very easy to block (as you suggest) and fail open when blocked. What's needed here (for hard fail) is OCSP Must-Staple; however, this is in the early stages of adoption and it'll be a very long time before it can be relied upon. As Mozilla writes[1]: > OCSP responders are not yet reliable enough for us to do hard fail. OCSP stapling will help to make hard-fail possible. Must-Staple will be a way to opt into hard-fail. To answer your question on whether any will warn on soft failure: none that I'm aware of, outside of Firefox declining to provide "EV" treatment in the UI when OCSP fails or is not provided[1]. Note that some CAs, e.g., GlobalSign, are actually removing CRLs entirely from certificates given how useless they have been (and how little modern browsers rely upon). For more nuanced critiques of current revocation options see AGL's writings [2] [3]. The real question here is what the browsers can/should do? Google Chrome has a mechanism called "CRLSets" that they use to push emergency blacklisting of certificates: From https://dev.chromium.org/Home/chromium-security/crlsets:
> CRLSets (background) are primarily a means by which Chrome can quickly block certificates in emergency situations. As a secondary function they can also contain some number of non-emergency revocations. These latter revocations are obtained by crawling CRLs published by CAs. And Mozilla has their "OneCRL"[4]:
> Using OCSP for certificate revocation doesn’t serve users very well. For online revocation checks, either you have a system that fails open or you accept the performance penalty of checks that are more strict (as is the case for EV certificates). OCSP stapling can remove the need for live revocation checks, but currently, only only around 9% of TLS connections use it. OneCRL helps speed up revocation checking by maintaining a centralized list of revoked certificates and pushing it out to browsers. Not sure what other browsers have done — rarely troubleshoot with anything but Chrome or Firefox. Hope this helps. [0] - "RFC 6961: The Transport Layer Security (TLS) Multiple Certificate Status Request Extension" https://tools.ietf.org/html/rfc6961 [1] - "Plan for Improving Revocation Checking in Firefox": https://wiki.mozilla.org/CA:ImprovingRevocation [2] - "No, don't enable revocation checking (19 Apr 2014)": https://www.imperialviolet.org/2014/04/19/revchecking.html [3] - "Revocation still doesn't work (29 Apr 2014)": https://www.imperialviolet.org/2014/04/29/revocationagain.ht... [4] - https://blog.mozilla.org/security/2015/03/03/revoking-interm... |