We may not want to use OCSP stapling in our web servers

January 13, 2020

Not too long ago, I was modernizing some of our Apache TLS settings. As I usually do, I went to the Mozilla SSL configuration generator (which is what I think you should do) and more or less accepted its recommendations for our Apache and OpenSSL version. These days, that includes OCSP stapling. I didn't really think much about this. Then some things happened recently, and today my co-workers asked more or less if we should be doing OCSP stapling at all. Unfortunately, the more I think about that question, the more I think that we should probably not configure OCSP stapling in our web servers.

One big motivation for OCSP stapling was OCSP must-staple, but that seems basically dead; I can find people talking about it, but I can't find any site actually using it, including people who set it up once upon a time. I'm not surprised by this, because OCSP must-staple can easily break your website if anything goes wrong with OCSP stapling and people generally don't like that sort of 'feature'. People may try it out, but sooner or later something explodes and then they stop. We're certainly never going to use OCSP must-staple unless it becomes a hard requirement in a popular browser.

If you're not using OCSP must-staple, the major thing that OCSP stapling means is that browsers that make OCSP checks can save some time when they connect to you. Desktop Firefox definitely does OCSP checks by default (although I believe mobile Firefox only does it for EV certificates), and Chrome definitely doesn't. I'm not sure about the state of Safari, either on iOS or OS X (although see this ssl.com article). Unfortunately, Firefox is no longer a major desktop browser, so how much OCSP stapling matters likely depends mostly on how Safari behaves.

(Currently, Apple appears to use OCSP stapling information under some circumstances, but it's not the only way to provide what they want.)

Pragmatically, a lot of sites that I would have expected to use OCSP stapling don't actually do so. None of Mozilla, Let's Encrypt, Twitter, Facebook, or Apple use OCSP stapling, although Apple's support site currently does, as does Amazon (and Amazon Canada). Infrequent use of OCSP stapling (and OCSP stapled data) matters, because the less it's used (in Apache and elsewhere), the more chances there are for all of the code related to it to have issues, especially in Apache.

On the whole, the more I look at the combination of the benefits of OCSP stapling, the potential hazards, and the limited use I can see out in the field (even and especially from places that I'd expect to support it), the less I feel like we should be using OCSP stapling. OCSP stapling seems to be at least a little bit bleeding edge, not well established practice, and there's no need for us to live out there.


Comments on this page:

By sam at 2020-01-14 09:23:58:

I reached much the same conclusion on OCSP stapling after looking into it - too many moving parts and rough edges for not enough gain. An attacker who's able to get a certificate can presumably also immediately get an OCSP response to staple to it, so they have a few days to exploit the misissuance anyway.

Firefox is experimenting with a different revocation mechanism, CRLite, which takes advantage of Certificate Transparency providing a list of all domains on the public web and then creating a (relatively) really small collection of alternating inclusion-exclusion Bloom filters to exactly describe the revoked set. It's not deployed yet, but the idea makes sense to me, and once it's turned on (and once Let's Encrypt starts publishing a CRL) I'll benefit from at-least-as-prompt-as-OCSP revocations without any further work on my end, or having to care about OCSP server uptime or any other new operational worries.

Written on 13 January 2020.
« Link: Mercurial's Journey to and Reflections on Python 3
Stopping udev from renaming your VLAN interfaces to bad names »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Mon Jan 13 22:22:37 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.