4 ms·

I was kind of surprised that OCSP stapling didn't get any mention at all. I thought that was a major improvement in both resource cost and privacy? Since the ti

by xoa 4y ago

I was kind of surprised that OCSP stapling didn't get any mention at all. I thought that was a major improvement in both resource cost and privacy? Since the time stamped response is proxied by the site operator rather then going directly to the CA, the load is almost entirely switched to the site itself, and the site itself is the only one who knows a given IP is asking for it, which is fine because obviously the site knows a given browser is connecting to it anyway. It's decentralized again. I vaguely remember at one point there was a major limitation of only supporting a single OCSP response at a time but I thought that was dealt with via a later RFC and then entirely obviated as an issue by TLS 1.3. Did something happen there or some other significant issue get discovered? I'm curious why the move back to CRLs (albeit improved) vs must-staple. It seemed like a reasonable elegant and straight forward solution that fit the web pretty well.

champtar 4y ago
I also love OCSP stapling but there are some limitations: - webserver need to implement it - admin need to enable it - webserver need internet access Maybe they saw with some telemetry that very few website actually enable OCSP stampling and decided to implement a fix that cover all certs and can really be deployed
- coffee-- 4y ago
  Firefox Telemetry shows Beta 104 users encountered stapling on 13.95% of TLS handshakes. [1] The stapling telemetry is no longer turned on in Release [2], and even if it were, you have to do special things to look at Release data, but some years back (~2018 maybe?) I remember Release stapling was substantially lower than the more tech-savvy Beta and Nightly populations. Which is pretty normal, as tech-oriented sites are more likely to turn on advanced features. [1] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2022-08-18&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=beta%252F104&measure=SSL_OCSP_STAPLING&min_channel_version=nightly%252F55&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2022-07-25&table=0&trim=1&use_submission_date=0 https://telemetry.mozilla.org/new-pipeline/dist.html#!cumula... [2] "prerelease" https://probes.telemetry.mozilla.org/?search=stapl&view=detail&probeId=histogram%2FSSL_OCSP_STAPLING https://probes.telemetry.mozilla.org/?search=stapl&view=deta...
mcpherrinm 4y ago
must-staple requires additional effort from server operators, which is very challenging to roll out. This new scheme can be implemented by the browsers and CAs together, which is vastly simpler than having every webserver in the world turn on OCSP stapling. There isn’t any particular force driving for OCSP stapling: Browsers can’t turn it on until it is ubiquitous. CAs don’t want to enforce must-staple because their users will need enormous amount of help rolling it out. Site operators don’t care if browsers are fetching OCSP (especially since Chrome and Edge don’t)
mholt 4y ago
Yes, I noticed this too and asked the author about it [0]. IMO, OCSP stapling is the best overall solution until certificate lifetimes are shorter (< 7 days). As a server developer I'm worried that the focus on independent CRLs will make it difficult to automate certificates in the face of revocation. Currently, Caddy staples OCSP for all certificates by default, caches the staples, and refreshes them halfway through their lifetime. Works great. Every server should do this. And when an OCSP response is discovered to be Revoked, Caddy automatically replaces the certificate. Works great. Every server should do this. If every browser is independently going to decide which certificates to distrust, now I am not sure of a good, authoritative way to determine "revoked" and then replace certificates automatically. I'm worried this will hurt the TLS ecosystem unless we answer those questions first. Actually, let's just shorten certificate lifetimes and be done with it already. Main blockers to short cert lifetimes: - CA's uptime determines Web's uptime. Main solution: - Multiple redundant ACME CAs. If one goes down, try another. (This is what Caddy already does.) [0]: https://twitter.com/mholt6/status/1567559325949763588 https://twitter.com/mholt6/status/1567559325949763588
- xoa 4y ago
  Replying to this as it's on top, and first thanks for the reply (and sibling replies as well). The challenges of getting servers to update and implement being a practical roadblock makes sense, I was more surprised just to not see it mentioned at all. I'd have been fully prepared for a few sentences along the lines of "this would be ideal if doing it from scratch but it'd be hard to get everyone to go along now, the reverse perils of decentralization". What you write is also interesting.
- OrvalWintermute 4y ago
  I too found this troubling. Mainly because we are not talking about validation performance, and OCSP stapling is an excellent performance fix. Not to mention all the privacy issues that OCSP stapling really fixes.
- coffee-- 4y ago
  Another tool in the toolbox is ARI. https://datatracker.ietf.org/doc/draft-acme-ari/ https://datatracker.ietf.org/doc/draft-acme-ari/
aaomidi 4y ago
OCSP stapling increases how large the first response from the server is, increasing the time to first useful byte.
- mholt 4y ago
  It's on the order of a few hundred bytes, only happens on the first connection, and is still orders of magnitude faster and more effective than the alternative (no stapling, which requires the client to make separate round-trips to a third party service which has all sorts of other problems). OCSP stapling is temporary, anyway: just until we get certificate lifetimes short enough to make revocation irrelevant.* * This is how it should be, but the industry seems to be going the direction of keeping cert lifetimes longer.
  - aaomidi 4y ago
    A few hundred bytes is a ton data for something that a lot of people don’t particularly care about, and is still broken despite OCSP stapling. People don’t have low latency, clean internet all over the world and adding something like this on top of an already pretty bloated negotiation doesn’t help. As for the alternative not a single browser out there validates OCSP out of the box on the hot path (e.g actually waits for OCSP before proceeding)
    - OrvalWintermute 4y ago
      This is a brower problem, but it is configurable.
  - OrvalWintermute 4y ago
    Speaking from a PKI perspective you may head towards shorter lived certificates in many use-cases, NPE / automatable re-keying being examples of that. However, for strong PKI on a consumer or enterprise encryption/decryption device, e.g. smartcards, there is big costs associated with shortening lifetimes. Not going to fly there.
GauntletWizard 4y ago
OCSP Stapling is incredibly stupid. OSCP Stapling is either ignored because it's not present, or it's effectively just an override for the NotBefore and NotAfter fields. There's never a reason as a server operator to present an invalid NotAfter, and it represents a substantial surface area for client libraries to respect them, in the area that's already most prone to mistakes (the recursive descent to find a certificate chain) It's much saner to issue a new, shorter-lived cert. Reduce certificate lifetimes to match whatever you'd use OCSP stapling for. Continue to use ACME. Figure out rotation lifetimes such that I can sleep at night (i.e. they need to be at least 2 days, so that if the rotation fails I've still got time to wake up and start working). Work on building client and server tooling to make it easy to accept rotated certificates (i.e. reload your client certificates on SIGHUP). The advantage of CRLs isn't that they can be used offline, it's that it allows your security team to burn certificates rather than waiting for the CA to do so. You should always subscribe to your CA's CRL too, but you should have a CRL for your own internal use, too.
- OrvalWintermute 4y ago
  > The advantage of CRLs isn't that they can be used offline, it's that it allows your security team to burn certificates rather than waiting for the CA to do so. You should always subscribe to your CA's CRL too, but you should have a CRL for your own internal use, too. This is incorrect conventionally CRLs are signed by the Originating CA in the conventional trust model. Most CAs won't give you a certificate with the ability to generate your own CRL sharing the same trust, because it can be weaponized to cause a denial of service. This then brings up non-conventional trust models, and Validation Authority as Co-equal to CA situations for validity which can be significantly more challenging, and requiring VA certificate insertion into every Relying Party, just to name a few things, not to mention all the security concerns.
  - GauntletWizard 4y ago
    I'm aware. That trust model is inherently broken, and it's not followed anyway. In practice, any CA you trust can sign a revocation for any certificate (the serial numbers are all grouped together) - And that's the way it should be. You should not wait for the issuing CA to get it's act together, you should burn a certificate as soon as anyone distrusts it, and if you have a rogue CA that starts burning Google.com and other important sites, it's better that they burn them (and take you offline) than that they issue false certs (and leak all your data); It's also far more obvious. https://www.imperialviolet.org/2014/04/19/revchecking.html https://www.imperialviolet.org/2014/04/19/revchecking.html Revocation checking is useful for your security team to blacklist site. That's the only useful use.

by xoa 4y ago

champtar 4y ago

I also love OCSP stapling but there are some limitations: - webserver need to implement it - admin need to enable it - webserver need internet access Maybe they saw with some telemetry that very few website actually enable OCSP stampling and decided to implement a fix that cover all certs and can really be deployed

coffee-- 4y ago
Firefox Telemetry shows Beta 104 users encountered stapling on 13.95% of TLS handshakes. [1] The stapling telemetry is no longer turned on in Release [2], and even if it were, you have to do special things to look at Release data, but some years back (~2018 maybe?) I remember Release stapling was substantially lower than the more tech-savvy Beta and Nightly populations. Which is pretty normal, as tech-oriented sites are more likely to turn on advanced features. [1] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2022-08-18&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=beta%252F104&measure=SSL_OCSP_STAPLING&min_channel_version=nightly%252F55&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2022-07-25&table=0&trim=1&use_submission_date=0 https://telemetry.mozilla.org/new-pipeline/dist.html#!cumula... [2] "prerelease" https://probes.telemetry.mozilla.org/?search=stapl&view=detail&probeId=histogram%2FSSL_OCSP_STAPLING https://probes.telemetry.mozilla.org/?search=stapl&view=deta...

mcpherrinm 4y ago

must-staple requires additional effort from server operators, which is very challenging to roll out. This new scheme can be implemented by the browsers and CAs together, which is vastly simpler than having every webserver in the world turn on OCSP stapling. There isn’t any particular force driving for OCSP stapling: Browsers can’t turn it on until it is ubiquitous. CAs don’t want to enforce must-staple because their users will need enormous amount of help rolling it out. Site operators don’t care if browsers are fetching OCSP (especially since Chrome and Edge don’t)

mholt 4y ago

Yes, I noticed this too and asked the author about it [0]. IMO, OCSP stapling is the best overall solution until certificate lifetimes are shorter (< 7 days). As a server developer I'm worried that the focus on independent CRLs will make it difficult to automate certificates in the face of revocation. Currently, Caddy staples OCSP for all certificates by default, caches the staples, and refreshes them halfway through their lifetime. Works great. Every server should do this. And when an OCSP response is discovered to be Revoked, Caddy automatically replaces the certificate. Works great. Every server should do this. If every browser is independently going to decide which certificates to distrust, now I am not sure of a good, authoritative way to determine "revoked" and then replace certificates automatically. I'm worried this will hurt the TLS ecosystem unless we answer those questions first. Actually, let's just shorten certificate lifetimes and be done with it already. Main blockers to short cert lifetimes: - CA's uptime determines Web's uptime. Main solution: - Multiple redundant ACME CAs. If one goes down, try another. (This is what Caddy already does.) [0]: https://twitter.com/mholt6/status/1567559325949763588 https://twitter.com/mholt6/status/1567559325949763588

xoa 4y ago
Replying to this as it's on top, and first thanks for the reply (and sibling replies as well). The challenges of getting servers to update and implement being a practical roadblock makes sense, I was more surprised just to not see it mentioned at all. I'd have been fully prepared for a few sentences along the lines of "this would be ideal if doing it from scratch but it'd be hard to get everyone to go along now, the reverse perils of decentralization". What you write is also interesting.
OrvalWintermute 4y ago
I too found this troubling. Mainly because we are not talking about validation performance, and OCSP stapling is an excellent performance fix. Not to mention all the privacy issues that OCSP stapling really fixes.
coffee-- 4y ago
Another tool in the toolbox is ARI. https://datatracker.ietf.org/doc/draft-acme-ari/ https://datatracker.ietf.org/doc/draft-acme-ari/

aaomidi 4y ago

OCSP stapling increases how large the first response from the server is, increasing the time to first useful byte.

mholt 4y ago
It's on the order of a few hundred bytes, only happens on the first connection, and is still orders of magnitude faster and more effective than the alternative (no stapling, which requires the client to make separate round-trips to a third party service which has all sorts of other problems). OCSP stapling is temporary, anyway: just until we get certificate lifetimes short enough to make revocation irrelevant.* * This is how it should be, but the industry seems to be going the direction of keeping cert lifetimes longer.
- aaomidi 4y ago
  A few hundred bytes is a ton data for something that a lot of people don’t particularly care about, and is still broken despite OCSP stapling. People don’t have low latency, clean internet all over the world and adding something like this on top of an already pretty bloated negotiation doesn’t help. As for the alternative not a single browser out there validates OCSP out of the box on the hot path (e.g actually waits for OCSP before proceeding)
  - OrvalWintermute 4y ago
    This is a brower problem, but it is configurable.
- OrvalWintermute 4y ago
  Speaking from a PKI perspective you may head towards shorter lived certificates in many use-cases, NPE / automatable re-keying being examples of that. However, for strong PKI on a consumer or enterprise encryption/decryption device, e.g. smartcards, there is big costs associated with shortening lifetimes. Not going to fly there.

GauntletWizard 4y ago

OCSP Stapling is incredibly stupid. OSCP Stapling is either ignored because it's not present, or it's effectively just an override for the NotBefore and NotAfter fields. There's never a reason as a server operator to present an invalid NotAfter, and it represents a substantial surface area for client libraries to respect them, in the area that's already most prone to mistakes (the recursive descent to find a certificate chain) It's much saner to issue a new, shorter-lived cert. Reduce certificate lifetimes to match whatever you'd use OCSP stapling for. Continue to use ACME. Figure out rotation lifetimes such that I can sleep at night (i.e. they need to be at least 2 days, so that if the rotation fails I've still got time to wake up and start working). Work on building client and server tooling to make it easy to accept rotated certificates (i.e. reload your client certificates on SIGHUP). The advantage of CRLs isn't that they can be used offline, it's that it allows your security team to burn certificates rather than waiting for the CA to do so. You should always subscribe to your CA's CRL too, but you should have a CRL for your own internal use, too.

OrvalWintermute 4y ago
> The advantage of CRLs isn't that they can be used offline, it's that it allows your security team to burn certificates rather than waiting for the CA to do so. You should always subscribe to your CA's CRL too, but you should have a CRL for your own internal use, too. This is incorrect conventionally CRLs are signed by the Originating CA in the conventional trust model. Most CAs won't give you a certificate with the ability to generate your own CRL sharing the same trust, because it can be weaponized to cause a denial of service. This then brings up non-conventional trust models, and Validation Authority as Co-equal to CA situations for validity which can be significantly more challenging, and requiring VA certificate insertion into every Relying Party, just to name a few things, not to mention all the security concerns.
- GauntletWizard 4y ago
  I'm aware. That trust model is inherently broken, and it's not followed anyway. In practice, any CA you trust can sign a revocation for any certificate (the serial numbers are all grouped together) - And that's the way it should be. You should not wait for the issuing CA to get it's act together, you should burn a certificate as soon as anyone distrusts it, and if you have a rogue CA that starts burning Google.com and other important sites, it's better that they burn them (and take you offline) than that they issue false certs (and leak all your data); It's also far more obvious. https://www.imperialviolet.org/2014/04/19/revchecking.html https://www.imperialviolet.org/2014/04/19/revchecking.html Revocation checking is useful for your security team to blacklist site. That's the only useful use.