3 ms·

Let's Encrypt to end OCSP support in 2025

25 points by janandonly 2y ago

deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
numberless 2y ago
Wouldn't it be a better idea to use the original blog post direct from Lets Encrypt[1]? [1] https://letsencrypt.org/2024/12/05/ending-ocsp/ https://letsencrypt.org/2024/12/05/ending-ocsp/?
- tptacek 2y ago
  No, this post is more, and differently, informative.
wkat4242 2y ago
> What do we do if the OCSP Responder is down? Well, it turns out, clients don't really care and they just skip the check and accept the certificate anyway, making the whole thing pointless. OCSP checking add no security! Don't agree with this statement. It's only adding no security when the CA is down. In case a Cert is revoked and the OCSP is up, it will be blocked. But I understand their reasons to drop it.
- ameliaquining 2y ago
  The purpose of HTTPS is to defend again MITM attacks. An MITM attacker can effectively make the OCSP responder be down, by detecting and blocking traffic to it. So, no security.
  - wkat4242 2y ago
    I can think of cases where an attacker can do one or not the other (in particular where they're intercepting traffic near the web server end, not the client). In those cases there is a benefit. Because the CA is not hosted by the server itself, the routing path is very different and only converges near the end user. I know it's less likely but to say that there is no security at all is not true in my opinion.
    - ameliaquining 2y ago
      If the attacker is between the server and the rest of the internet, they can pass a CA validation challenge and get a new certificate that way.
OptionOfT 2y ago
I went through a similar journey when trying to figure out how to revoke JWTs, i.e. forcefully sign out everywhere. We ended up on the following: Either you accept the fact that once signed, it has a life on its own until it expires, or the issuer becomes the single point of failure. Another issue we dealt with was validating that the person doing the request with a JWT was the owner of the JWT, and not someone who stole it. A possible fix? Distribute private keys to clients, and have them sign the JWTs on the fly. How do you check for revoked private keys? Catch-22.
gnabgib 2y ago
Discussion (422 points, 5 months ago, 108 comments) https://news.ycombinator.com/item?id=41046956 https://news.ycombinator.com/item?id=41046956

25 points by janandonly 2y ago

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

numberless 2y ago

Wouldn't it be a better idea to use the original blog post direct from Lets Encrypt[1]? [1] https://letsencrypt.org/2024/12/05/ending-ocsp/ https://letsencrypt.org/2024/12/05/ending-ocsp/?

tptacek 2y ago
No, this post is more, and differently, informative.

wkat4242 2y ago

> What do we do if the OCSP Responder is down? Well, it turns out, clients don't really care and they just skip the check and accept the certificate anyway, making the whole thing pointless. OCSP checking add no security! Don't agree with this statement. It's only adding no security when the CA is down. In case a Cert is revoked and the OCSP is up, it will be blocked. But I understand their reasons to drop it.

ameliaquining 2y ago
The purpose of HTTPS is to defend again MITM attacks. An MITM attacker can effectively make the OCSP responder be down, by detecting and blocking traffic to it. So, no security.
- wkat4242 2y ago
  I can think of cases where an attacker can do one or not the other (in particular where they're intercepting traffic near the web server end, not the client). In those cases there is a benefit. Because the CA is not hosted by the server itself, the routing path is very different and only converges near the end user. I know it's less likely but to say that there is no security at all is not true in my opinion.
  - ameliaquining 2y ago
    If the attacker is between the server and the rest of the internet, they can pass a CA validation challenge and get a new certificate that way.

OptionOfT 2y ago

I went through a similar journey when trying to figure out how to revoke JWTs, i.e. forcefully sign out everywhere. We ended up on the following: Either you accept the fact that once signed, it has a life on its own until it expires, or the issuer becomes the single point of failure. Another issue we dealt with was validating that the person doing the request with a JWT was the owner of the JWT, and not someone who stole it. A possible fix? Distribute private keys to clients, and have them sign the JWTs on the fly. How do you check for revoked private keys? Catch-22.

gnabgib 2y ago

Discussion (422 points, 5 months ago, 108 comments) https://news.ycombinator.com/item?id=41046956 https://news.ycombinator.com/item?id=41046956