Hacker News Reader

Comment by hlieberman | Hacker News Reader

Why not simply add the Must Staple restriction unconditionally to all certificates (aka "status_request")?

That will eliminate privacy concerns -- no compliant TLS implementation should fetch a OCSP ticket given a stapled response -- while still allowing for broad non-browser support.

View on HN

In addition to listed below performance is another concern - OCSP stapling make TLS handshake large and slower. While it removes need for the client to query OCSP server itself in practice it such queries happen infrequently, asynchronously and in some may not happen at all. In theory a clients could include Certificate Status Request into the Client Hello only when a local cache expires but IIRC a few years ago Firefox did request OCSP on every TLS handshake making every handshake large if stapling is enabled on the server.

Many web servers have terrible to nonexistent OCSP stapling implementations.

cough nginx. Nginx would start up and serve TLS on must-staple certs .. before doing the staple setup. ie: any client that validated that a must-staple cert had a stapled ocsp ticket would fail for the first few queries after nginx startup.

I don't know if they've fixed it yet. I doubt it though - they were pretty aggressive in their assertion that violating must-staple wasn't a concern.

Well, this ticket is still open: https://trac.nginx.org/nginx/ticket/812

Yeah, I looked into nginx's stapling implementation almost a decade ago. I fixed some simpler bugs (I submitted a patch which was mostly rewritten and then merged) but fixing the problem you mention would have required major re-architecting. I doubt it has changed.

Apache as well, though mod_md improves on it significantly.

This competes against terrible to nonexistent CRL checking on clients, but there are generally more clients than servers.

Couldn't that be circumvented by just turning OCSP responses an option available only for must-staple certificates?

I don't get the OCSP Stampling protocol: if the server needs / is able to to contact the CA frequently anyway, why not simply use very short-lived certificates?

Issuing a certificate has significantly more overhead (e.g. Certificate Transparency logs) than signing a statement that an existing certificate is still valid.

Which CA's will issue short-lived certificates without negotiating a custom ($$$) contract with them?

Google Trust Services lets you go down to 1 day using ACME. No payment required.

Let's Encrypt, they said a while back they want to allow issuing certs for fewer than 90 days.

That's true, although it's still not possible to actually get one yet.

While it would eliminate privacy concerns, it would also likely break an enormous number of websites which don't implement OCSP stapling, or don't implement it correctly.

I'd suggest making browsers soft-enforce it with e.g. a yellow URL bar, giving server operators a window of time to fix things.

The browsers, generally, are not onboard with improving OCSP and supporting OCSP stapling. Chrome already doesn't check OCSP at all.

Apple and Firefox are all working on out-of-band revocation information based on CRL data. Presumably Chrome and its family are going to go down that path too, but I'm not sure I've heard commitments from them yet.

Firefox has the best documentation on what's happening: https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a...

Firefox does respect must-staple flag and requires a valid stapled response though.

I think with the whole menagerie of green locks, green bars & EV sites replacing/cluttering the address bar (meh [0]), only showing PSL+1 [1] (which actually does help security, but vocal power-users hate [2])...UI/UX designers are probably loathe to mess with it again.

[0]: https://www.troyhunt.com/extended-validation-certificates-ar... [1]: https://blog.chromium.org/2020/08/helping-people-spot-spoofs... [2]: https://www.reddit.com/r/chrome/comments/h11gde/how_do_i_sto... [3]: https://www.wired.com/story/google-chrome-kill-url-first-ste...

Does highlighting the domain name not give the boost in security? I don't mind highlighting. And it's possible to get very aggressive with highlighting.

At the very least it should have a [...] and not completely hide the fact that there is a URL.

You talk about it like there’s a vibrant community of websites out there. There’s streaming sites and social media, and then a bunch of apps that are delivered through the web. All of them are sophisticated web operations.

Let's Encrypt's goal has always been to support the vibrant community of websites, extending TLS to the long tail.

The handful of streaming and social media sites can always go to a big commercial CA and spend a few hundred bucks a year on certs that do whatever they need.

in practice I think you're right, but oof.

The Internet is more than sophisticated big tech companies.

OCSP sounds to me like a really bad idea: certificate expiration is already a significant cause of issues and now we add a whole new way for certificates to break your site?

In practice, nothing breaks if it can't reach OCSP in a lot of cases. But as with most PKI systems, it causes problems sometimes, so we have to do stupid things like add firewall rules to allow secure systems to reach OCSP endpoints to avoid random PKI-dependent stuff coming crashing down.

Reply on news.ycombinator.com