Following the announcement to end OCSP in favour of CRL, we've been following the various discussions.
We develop and manage Captive Portals. These are web sites that are shown to users that join WiFi networks prior to being granted broader network access - typically before the user's device has an internet connection. Think of a coffee shop or hotel WiFi hotspot.
OCSP stapling has therefore been a really important part of our solution allowing the end devices to trust the captive portal site without needed to reach out to the web.
Many of our solutions also run in a bandwidth constrained environment such as planes, trains etc. Even if we did manage firewalls to allow CRL traffic (not ideal at all), the resources in question can be large. This makes the site sluggish for the user or even in extreme cases just not work.
Finally, there is also an airline use case. Passenger devices are set to flight mode and join the local network for accessing movies etc. Stapling is crucial here because the device is effectively offline.
We wanted to highlight our use cases and to get some opinions.
I think it's useful here to define the (perceived) requirements, so that your question is clearer. As I understand it, your line of thinking is like this:
As a browser developer, I want to ensure my users security by checking that the certificate is not revoked. I can do so via CRL and/or OCSP, and Let's Encrypt currently offers OCSP -> so the browser checks via OCSP. If Let's Encrypt no longer offers OCSP, the browser will fetch CRLs instead.
As a captive portal developer, I want to limit access to third party sites. OCSP and CRL are both such third party sites. But, with OCSP stapling, I can bypass the third party, fulfilling the browser's requirements without the third party.
The assumption is that if Let's Encrypt "goes back" to CRL from OCSP, browsers will have to contact a third party again, which contradicts my requirement as a captive portal developer.
I think the assumptions made here are probably slightly incorrect, or do not match the expected future. Currently, no major browser fetches CRLs directly. I do know of implementations that fetch CRLs (e.g. Microsoft's schannel does), but not the browsers themselves.
What the browsers do instead, they fetch CRLs out-of-band and distribute compressed versions of them via (existing) browser update channels. For Firefox this is CRLite, for Chrome CRLSets. Therefore, in a future world where Let's Encrypt has abandoned OCSP, the browser will not fall back to fetching CRLs directly: This process is migrated into a vendor-specific process that is independent of the browser itself, and does not cause any significant network traffic for your captive portal. If necessary, the browser can simply update its local CRL list once outside the plane/train/hotel/whatever. This is all part of the browser's regular self-scheduled maintenance.
Thus, as a captive portal developer, there won't be much third-party traffic to CRL services from users browsers, even without OCSP. Of course if you intend to support non-browser clients that do currently fetch CRLs, then yes I understand your concern. I believe Let's Encrypt currently hopes that more clients migrate to this out-of-band CRL fetching such that when Let's Encrypt shuts down OCSP, the problem will already be solved.
I think our understanding of how browsers are now handling CRLs was a little out of date.
The only remaining concern was that Captive Portals are typically handled by "non-standard" browsers. For example, for Apple they use the "Captive Network Assistant". This isn't Safari and Apple provide very little documentation on this "micro" browser.
Does the community have knowledge on whether these browsers behave in similar ways with regards to out of band CRL handling? Thanks again
and there will be Short-lived (max 10 days, same as OCSP lifetime) Certificates that doesn't include any revocation support, so you can use those if really needed