3 ms·

Context: WebPKI revocation is broken. It didn't have to be [0], but it always has been, and likely always will be, now that the industry is moving to short-live

by mholt 1y ago

Context: WebPKI revocation is broken. It didn't have to be [0], but it always has been, and likely always will be, now that the industry is moving to short-lived certificates. Let's Encrypt is now offering a profile for 6-day certificates: https://letsencrypt.org/docs/profiles/#shortlived https://letsencrypt.org/docs/profiles/#shortlived With such short-lived certificates, revocation effectively becomes a non-issue. [0]: OCSP Stapling (esp. with Must-Staple) is actually pretty effective at distributing revocation information in a timely, secure, private manner. There were no real downsides to the spec, which is why Caddy has supported automatic OCSP stapling since, gosh, I think 2016 or so. The problem is that most other web servers didn't -- and still don't -- implement it well [1], making OCSP (without the stapling) a persistent privacy problem. Additionally, many client vendors want to choose what certificates count as "revoked" now, so they use their own CRLs, making OCSP entirely useless, since they only check their own CRLs. [1]: https://gist.github.com/sleevi/5efe9ef98961ecfb4da8 https://gist.github.com/sleevi/5efe9ef98961ecfb4da8 -- most servers have such a bad implementation of OCSP stapling that it makes sites less reliable, not more.

strcat 1y ago
Other web servers have a reliable implementation of OCSP stapling via their support for loading the OCSP response from an external file. It isn't as convenient as having it built-in but it works well. GrapheneOS used https://github.com/tomwassenberg/certbot-ocsp-fetcher https://github.com/tomwassenberg/certbot-ocsp-fetcher for years to provide reliable OCSP stapling for nginx prior to Let's Encrypt dropping OCSP support. We used Must-Staple through that for years. TLS ticket key rotation also generally needs to be handled externally in a noswap tmpfs to avoid the keys being lost when restarting service, especially if syncing them across multiple nodes providing the same service is desired. Syncing them across nodes also allows preserving them across reboots while still only having them in-memory. > Let's Encrypt is now offering a profile for 6-day certificates: https://letsencrypt.org/docs/profiles/#shortlived https://letsencrypt.org/docs/profiles/#shortlived Only the default classic and opt-in tlsserver profiles are available. The allowlist mentioned there doesn't really seem to exist yet. The tlsserver profile has the same changes as shortlived without dropping 90 days to 160 hours. Both tlsserver and shortlived drop support for clients without SNI support which are unfortunately still very common for non-web usage. We found we can't deploy tlsserver for our SMTP federation (port 25) or SUPL server without having a fallback certificate for clients without SNI support. Since shortlived drops non-SNI client support, not everyone will be able to use it. It would be nice if there were 2 variants of it instead since client functionality is typically not within the control of servers. Let's Encrypt dropped OCSP support before they had the replacement of short-lived certificates deployed. It would have been nice if OCSP support was only dropped after shortlived was enabled for production usage, but it's too late for that now. If it was possible to start using shortlived today, we would.

by mholt 1y ago

strcat 1y ago

Other web servers have a reliable implementation of OCSP stapling via their support for loading the OCSP response from an external file. It isn't as convenient as having it built-in but it works well. GrapheneOS used https://github.com/tomwassenberg/certbot-ocsp-fetcher https://github.com/tomwassenberg/certbot-ocsp-fetcher for years to provide reliable OCSP stapling for nginx prior to Let's Encrypt dropping OCSP support. We used Must-Staple through that for years. TLS ticket key rotation also generally needs to be handled externally in a noswap tmpfs to avoid the keys being lost when restarting service, especially if syncing them across multiple nodes providing the same service is desired. Syncing them across nodes also allows preserving them across reboots while still only having them in-memory. > Let's Encrypt is now offering a profile for 6-day certificates: https://letsencrypt.org/docs/profiles/#shortlived https://letsencrypt.org/docs/profiles/#shortlived Only the default classic and opt-in tlsserver profiles are available. The allowlist mentioned there doesn't really seem to exist yet. The tlsserver profile has the same changes as shortlived without dropping 90 days to 160 hours. Both tlsserver and shortlived drop support for clients without SNI support which are unfortunately still very common for non-web usage. We found we can't deploy tlsserver for our SMTP federation (port 25) or SUPL server without having a fallback certificate for clients without SNI support. Since shortlived drops non-SNI client support, not everyone will be able to use it. It would be nice if there were 2 variants of it instead since client functionality is typically not within the control of servers. Let's Encrypt dropped OCSP support before they had the replacement of short-lived certificates deployed. It would have been nice if OCSP support was only dropped after shortlived was enabled for production usage, but it's too late for that now. If it was possible to start using shortlived today, we would.