3 ms·

There is also the third option, via must-staple, where OCSP responses are attached to the TLS handshake. This resolves the privacy issue [because otherwise clie

by ivanr 3y ago

There is also the third option, via must-staple, where OCSP responses are attached to the TLS handshake. This resolves the privacy issue [because otherwise clients have to talk directly to CAs and reveal what sites they're visiting]. All (big) browsers have mechanisms functionally similar to CRLite. Apple has "valid" (not sure if that's the official name) and Google has CRLSets.

mcpherrinm 3y ago
Google's CRLSets don't cover nearly the full set of revocations (AFAIK). I don't know the details of how "valid" works, but as the Apple root program has recently required CAs to publish full CRLs, I assume they're planning something similar. I mostly cite CRLite as it's well-documented. I don't think OCSP must-staple is deployable. It requires code changes to effectively every webserver in the world, and that doesn't seem to be happening. I think it is stuck in a spiral of non-adoption, where there's no incentive for anyone to make progress. I believe short-lived certs (7 days) are more deployable in the ecosystem today than ocsp must-staple, with similar security properties. Certificate automation is already desirable, and it's not as big a leap once flows are automated. This isn't going to happen overnight at least. Years, probably many. But it's happening.
- tptacek 3y ago
  "The spiral of non-adoption" is an interesting blog post someone should write. I bet there are a couple more examples besides the obvious one.
  - pvg 3y ago
    It could also be a festival/performance site for unadopted technologies. Sunday, Sunday, key signing ceremony at Non-adoption Spiral!
- ivanr 3y ago
  I think you're right about CRLSets. IMO, Mozilla really wanted to solve the problem, whereas Chrome just wanted to have a solution that they could use for emergency revocation of certificates of high-profile sites (and intermediates/roots). Small-time sites won't be in CRLSets, although if you know the right people and make enough noise you may be added to their list. As for Apple, no one knows what's going on because they don't like to share :) OCSP must-staple doesn't require code changes. It's a "flag" you set on a certificate. Maybe what you mean is that OCSP stapling is not enabled by default on many installations, and that's true. IIS got it right, and Caddy (obviously, the only platform that got everything right). Again, we're in this place only because browsers don't care about revocation. If they pushed for it, things would fall into place very quickly. But they're going in the opposite direction. Short-lived certificates are great, assuming you're fine with a 3.5 day (on average) window of opportunity for exploitation. There's a potentially major problem with clock skew, as many clients have inaccurate clocks. Personally, I recommend that certificates are obtained at least a week before they're deployed; a month would be better. Then rotated a month before they expire. That's how you minimise the problems due to clock skew.
  - e12e 3y ago
    As far as I can figure out, most ocsp staples are valid for 7 days, so short lived certificates would be equivalent, but simpler?
    - ivanr 3y ago
      Indeed, you're right. Must-staple and short-lived certificates have the same problem with clock skew.
  - agwa 3y ago
    Apple shared the details of valid.apple.com in a WWDC talk: https://devstreaming-cdn.apple.com/videos/wwdc/2017/701jvytnoey2yc7222/701/701_hd_your_apps_and_evolving_network_security_standards.mp4?dl=1 https://devstreaming-cdn.apple.com/videos/wwdc/2017/701jvytn... Slides: https://devstreaming-cdn.apple.com/videos/wwdc/2017/701jvytnoey2yc7222/701/701_your_apps_and_evolving_network_security_standards.pdf https://devstreaming-cdn.apple.com/videos/wwdc/2017/701jvytn... You can also find the client-side code if you dig around under https://opensource.apple.com/source/Security/ https://opensource.apple.com/source/Security/ It aims to cover all certificates, similar to Mozilla's CRLite.

by ivanr 3y ago

mcpherrinm 3y ago

Google's CRLSets don't cover nearly the full set of revocations (AFAIK). I don't know the details of how "valid" works, but as the Apple root program has recently required CAs to publish full CRLs, I assume they're planning something similar. I mostly cite CRLite as it's well-documented. I don't think OCSP must-staple is deployable. It requires code changes to effectively every webserver in the world, and that doesn't seem to be happening. I think it is stuck in a spiral of non-adoption, where there's no incentive for anyone to make progress. I believe short-lived certs (7 days) are more deployable in the ecosystem today than ocsp must-staple, with similar security properties. Certificate automation is already desirable, and it's not as big a leap once flows are automated. This isn't going to happen overnight at least. Years, probably many. But it's happening.

tptacek 3y ago
"The spiral of non-adoption" is an interesting blog post someone should write. I bet there are a couple more examples besides the obvious one.
- pvg 3y ago
  It could also be a festival/performance site for unadopted technologies. Sunday, Sunday, key signing ceremony at Non-adoption Spiral!
ivanr 3y ago
I think you're right about CRLSets. IMO, Mozilla really wanted to solve the problem, whereas Chrome just wanted to have a solution that they could use for emergency revocation of certificates of high-profile sites (and intermediates/roots). Small-time sites won't be in CRLSets, although if you know the right people and make enough noise you may be added to their list. As for Apple, no one knows what's going on because they don't like to share :) OCSP must-staple doesn't require code changes. It's a "flag" you set on a certificate. Maybe what you mean is that OCSP stapling is not enabled by default on many installations, and that's true. IIS got it right, and Caddy (obviously, the only platform that got everything right). Again, we're in this place only because browsers don't care about revocation. If they pushed for it, things would fall into place very quickly. But they're going in the opposite direction. Short-lived certificates are great, assuming you're fine with a 3.5 day (on average) window of opportunity for exploitation. There's a potentially major problem with clock skew, as many clients have inaccurate clocks. Personally, I recommend that certificates are obtained at least a week before they're deployed; a month would be better. Then rotated a month before they expire. That's how you minimise the problems due to clock skew.
- e12e 3y ago
  As far as I can figure out, most ocsp staples are valid for 7 days, so short lived certificates would be equivalent, but simpler?
  - ivanr 3y ago
    Indeed, you're right. Must-staple and short-lived certificates have the same problem with clock skew.
- agwa 3y ago
  Apple shared the details of valid.apple.com in a WWDC talk: https://devstreaming-cdn.apple.com/videos/wwdc/2017/701jvytnoey2yc7222/701/701_hd_your_apps_and_evolving_network_security_standards.mp4?dl=1 https://devstreaming-cdn.apple.com/videos/wwdc/2017/701jvytn... Slides: https://devstreaming-cdn.apple.com/videos/wwdc/2017/701jvytnoey2yc7222/701/701_your_apps_and_evolving_network_security_standards.pdf https://devstreaming-cdn.apple.com/videos/wwdc/2017/701jvytn... You can also find the client-side code if you dig around under https://opensource.apple.com/source/Security/ https://opensource.apple.com/source/Security/ It aims to cover all certificates, similar to Mozilla's CRLite.