I was a big fan of OCSP-stapling and must-staple. Both of which are slowly being discouraged; LetsEncrypt refuses to issue must-staple certificates since a few months ago, and I think they are shutting down OCSP servers, if not shut down already.

The idea with OCSP-stapling is that the webserver fetches the OCSP data, caches it for TTL ~24 hours, and staples it to the HTTPS handshake. That way, the browser does not need to query the issuer's OCSP servers, avoiding both performance and privacy concerns. Revoked certificates will continue to work for up to 24 hours, but that, IMO, is within an accepted range compared to CRL that can take a lot longer.

The downside is that the HTTPS handshakes now contain a bit more data, and we want to keep this as minimal as possible.

▲

thayne 2 days ago | parent | next [-]

I don't think any browsers still support OCSP.

The problem with OCSP stapling is that it either the client has to fall back to doing OCSP checking itself if the server doesn't staple the signature, which has its own problems[1], or enough servers need to support ocsp stapling that the client can just reject connections that don't include it. And unfortunately, there was never a significant uptake for servers, partly because there wasn't really any incentive to implement OCSP stapling. Maybe if there was a TLS 2.0 (or some other standard) that required OCSP stapling and had other benefits as well, it could work.

[1]: the biggest problem with non-stapled OCSP is what to do if you don't get a response for the ocsp request. If you fail open, an attacker can intercept the request to prevent you from knowing the cert is revoked, but if you fail closed, then any issue with the connection to the ocsp server results in loss of service. And then there are also issues with additional latency to wait for the ocsp response, privacy leaks from the ocsp requests, etc.

▲

Ayesh 2 days ago | parent [-]

If the certificate was issued with must-staple flag, then the server can refuse to connect if the handshake did not include an OCSP response.

web servers can refresh OCSP responses in the background and cache valid responses to add some tolerance against temporarily downtimes in the OCSP server.

▲

thayne 2 days ago | parent [-]

Right, but the vast majoriry of servers don't use must-staple certs. So browsers would need to do something (even if that something is not checking revocations) for all the other connections anyway.

It's really a chicken and egg problem. Browsers don't want to support must-staple because not enough servers use it. And servers don't use it, because browsers don't require it (or even implement it). And now CAs don't support it, because hardly anyone was using it.

Now if CAs started requiring must-staple, that might push it into widespread use. But that would cause a lot of disruption.

	▲	Dylan16807 a day ago \| parent [-]
		If you're willing to put in the effort to implement OCSP in the first place, why not take the couple percent extra time to add must-staple support? This seems like it would have been a very easy to solve chicken and egg problem.

▲

yegle 2 days ago | parent | prev | next [-]

I wonder if any free certificate issuers still support Must-Staple?

	▲	Ayesh 2 days ago \| parent [-]
		I don't think so. - Let's Encrypt: doesn't support it since May 7 this year - Buy Pass: No longer offers free certificates, probably didn't have must-staple either - Zero SSL, I didn't find any public links to check if they sign CSRs with it. - Google Trust Services: Same as above - Amazon Trust: Same as above, but it probably does.

▲

saurik 2 days ago | parent | prev [-]

How is this actually better (or conceptually even different) than just having the issuer's servers issue new certificates that only last 24 hours?

	▲	Ayesh a day ago \| parent [-]
		It's not better. Short lived certificates are definitely the better way forward. 24 hour certificates will add a significantly more load on CAs, a lot more than maintaining an OCSP responder.