9

OCSP stapling decreases the load on a PKI infrastructure's OCSP server by attaching a signed OCSP response to the target in a TLS connection. In addition it creates a more secure/private session since the CA doesn't know that your browser is accessing a given site. Some people have compared this behavior to Kerberos.

Question

  • What web browsers support OCSP stapling?

  • Are there any implementation considerations among different browsers that need to be addressed to maintain uniform privacy and performance benefits?

||improve this question
  • 1
    As a note - in a regular SSL session, the CA does not know the browser is accessing the site. There is nothing in the SSL protocol that involves the browser talking to the CA in anyway. Nor is OCSP required. I would not, in fact, call it "more secure" as some systems see having a fresh made-for-you OCSP response as the better security implementation. – bethlakshmi May 1 '12 at 19:24
  • @bethlakshmi SSL has this revocation problem. CRLs get longer and longer. OCSP is a solution for that but it has the privacy (and soft fail) problem. Both can be solved with OCSP stabling (and must staple extension). – eckes Oct 17 '14 at 19:22
  • @bethlakshmi I'm new to this, but doesn't SSL require browsers to ping the revocation lists from the CA? – JosiahYoder-deactive except.. Sep 2 '16 at 18:53
  • No, it does not. In the SSL/TLS handshake the server must provide a credential, and the type of acceptable credential can be specified by the client, but the credential is not required to be a PKI certificate, nor is the client required to verify the credential via CRL or OCSP. Most browsers implement a trusted cert store, check that the cert is not expired, and check that the cert includes the hostname of the targeted URL request. Most commercial browsers today don't check status unless a plug in or other addition is set. – bethlakshmi Sep 12 '16 at 20:54
9

My impression is that OCSP stapling is not well supported on the client side, but it's possible my information might be out of date.

Firefox apparently supports OCSP stapling, as of Firefox 26. (Thanks to Jan Schejbal for this information.)

Chrome supports OCSP stapling on Windows, Linux, and ChromeOS. (Thanks to Kit Sunde for this information.) (The Chrome team has decided that they plan to remove CRL and regular OCSP checks, but they haven't disabled OCSP stapling.)

I've read one report that most browsers support OCSP stapling on Windows.

Here is some more information on browser support for OCSP (but not OCSP stapling, unfortunately).

||improve this answer
  • Firefox 26 now includes OCSP stapling support as per an announcement on mozilla.dev.security.policy. – Jan Schejbal Dec 13 '13 at 4:56
  • Thanks, @JanSchejbal! I've updated the answer accordingly. I appreciate it. – D.W. Dec 13 '13 at 5:01
  • Chrome hasn't disabled OCSP stapling. Only CRL and regular OCSP checks. code.google.com/p/chromium/issues/detail?id=361230#c8 – Kit Sunde Jul 5 '14 at 23:06
  • Thank you, @KitSunde, for the correction! I've updated the answer accordingly -- many thanks. – D.W. Jul 6 '14 at 1:27
  • What do they mean by "but an attacker close to the server can get certificates issued from many CAs and deploy different certificates as needed." in the Blog? – goodguys_activate Jul 6 '14 at 1:49
6

You can test OCSP stapling support in Your browser on http://www.vpnhosting.cz/ocsp.

It is in Czech language, if You can see OCSP_stapling_disabled, OCSP stapling is disabled, OCSP_stapling_enabled means, that OCSP stapling works.

||improve this answer
  • looks like Opera 12.01 on Linux does support it, nice – Hubert Kario Sep 25 '12 at 11:34
3

IE has supported it since Vista, Chrome supports it on Windows via CryptoAPI and on other platforms via patches to NSS it made that Firefox has not accepted, Opera has also supported it for several years. Firefox has the worst revocation behavior of any browser on a number of fronts its lack of support of OCSP stapling being the smallest example. Also Chrome will continue to support OCSP and OCSP stapling in enterprise scenarios they have provided their own revocation checking mechanism for a variety of reasons.

||improve this answer
0

Even with OCSP stapling, the act of verifying the OCSP signature may expose personal information to the OCSP signing root. Additionally the OCSP singing root can be a 3rd party to the entire infrastructure as shown here:

PKI hierarchy with two roots

source

Although there are security benefits to validating the signing OCSP signature, if privacy concerns outweigh security the following extension disables the signing functionality szOID_PKIX_OCSP_NOCHECK (1.3.6.1.5.5.7.48.1.5) (note it is up to the CA to implement this extension)

If you want to use CRL instead of OCSP, you can set the following setting to 1 or zero on a Windows machine

 HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\ChainEngine\Config\CryptnetCachedOcspSwitchToCrlCount
||improve this answer
  • Isn't this the case only when you want to check the validity of intermediate CA certificates in OCSP responder certificate and the OCSP stapled response doesn't have them already? In other words, it is a security hole but lot smaller than not checking revocation at all? – Hubert Kario Jul 12 '12 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.