5 ms·

Seems rather problematic that a cert that appears to have been revoked 5 days ago isn’t recognized as revoked by virtually any browser. Is this an OCSP-related

Seems rather problematic that a cert that appears to have been revoked 5 days ago isn’t recognized as revoked by virtually any browser. Is this an OCSP-related issue or do browsers actually do a bad job at checking for revocation?

deleted 1y ago
[deleted]
- deleted 1y ago
  [deleted]
Dylan16807 1y ago
If you don't do a job at all, have you done a bad job?
redleader55 1y ago
Checking for revocation doesn't scale and has serious privacy implications. There are two ways to do revocation: CRL and OCSP. CRL is a list that becomes huge over time - hosting it would require massive amounts of bandwidth and clients would need to download a lot of extra data. OSCP is more like a query API - did this cert expire? The problem is you need to make that query for each visit and you leak your IP address when you do that query. The hoster would need to provide capacity to run those queries and serve the result. For each visit you'd need to pay a few round-trips worth of delay before showing the content, sometimes while part of the content is downloaded: you download example.com, which has some CSS which is hosted at static.example.com, and the website redirects you to m.example.com which is the mobile version after running some JavaScript which detects the browser capabilities.
- zephyreon 1y ago
  So the answer then is just much shorter-lived certs? I could definitely still see the need for an immediate revocation to be recognized near-instantaneously. Or in practice is that ultimately not necessary?
  - xyzzy_plugh 1y ago
    Yes, I think short-lived certs are ultimately where we're headed. We're starting to see adoption for O(days) now but I imagine that the lifetime will continue to decrease to some minimum O(hours) in the years to come.
    - zephyreon 1y ago
      Ironically this ends up putting a ton more load on the issuers, which some others have pointed out is why revocation doesn’t scale well (other than privacy concerns, which are valid).
    - toast0 1y ago
      I dread supporting O(hours). Clients often have wrong clocks. I've seen some client systems that enforced 'Not Before' and interpreted the datetime as local time and there were many users of that platform in the Americas; and my CA at the time insisted that Not Before was the time of issuance... lots of fun deciding how long to keep using a revoked certificate to balance the users with working revocation vs the users with broken Not Before checking. The client system I'm aware of is very dead, but maybe other systems managed similar.
- sugarpimpdorsey 1y ago
  > CRL is a list that becomes huge over time - hosting it would require massive amounts of bandwidth and clients would need to download a lot of extra data. Compared to what? 12MB JavaScript bundles and autoplay videos? Do CDNs still exist? There's a finite number of CAs and browsers can be expected to perform caching. Delta CRLs also exist and the CAs can decline to include expired leaf certs. This sounds like a made up problem that was solved 25 years ago.
  - redleader55 1y ago
    If you cache the revocation list, you lose all the benefits of instant revocation making the whole process pointless.
    - sugarpimpdorsey 1y ago
      OCSP is dead. We don't have that luxury anymore. By caching I meant for 12-24 hrs.
      - redleader55 1y ago
        Again, if you need to revoke a certificate, it means something terrible happened - someone compromised your server and your website has a good chance to be impersonated by 3rd parties. In all the other cases, you just let the old cert expire. You likely don't want people finding out about the revocation 12-24 hours later.
        robertlagrant 1y ago
        OCSP-stapling seemed to be fine with 24-48 hour client-side caching, though.
- tjoff 1y ago
  You could of course cache the list, only download whatever was new from a specific date. Short-lived certs would vastly reduce the list as well. Not really sure how big of a problem a list could be?
  - pmontra 1y ago
    Let's see. I can cache the information that example.com is valid up to May 31 2026, but then how do I know that it gets revoked on any day before that date? And if I cache the information that it is revoked, how do I know that it's allowed again? I could check, let's say one time per day even if I don't access that site. In any case I'm still leaking which domains I browse and I keep trusting cached certificates until the next check. On the other side, with short lived certificates I would be trusting a certificate for a longer time, until it expires. Downloading a list of all certificates and their status from every CAs is probably unfeasible. It seems that we can't escape a tradeoff between privacy and security.
    - tjoff 1y ago
      You cache the revocation list, no? If it is in the list it is revoked... How do you know it is allowed again? Because it responds with a new certificate, that isn't revoked... You are not leaking anything. You are just downloading a list of revoked domains. Regardless of whether you are visiting them or not.
- goalieca 1y ago
  > CRL is a list that becomes huge over time IETF will be gradually reducing maximum length of public certs to 47 days. I expect this will help some of the issue since expired certs can be removed from the list.
Ayesh 1y ago
I was a big fan of OCSP-stapling and must-staple. Both of which are slowly being discouraged; LetsEncrypt refuses to issue must-staple certificates since a few months ago, and I think they are shutting down OCSP servers, if not shut down already. The idea with OCSP-stapling is that the webserver fetches the OCSP data, caches it for TTL ~24 hours, and staples it to the HTTPS handshake. That way, the browser does not need to query the issuer's OCSP servers, avoiding both performance and privacy concerns. Revoked certificates will continue to work for up to 24 hours, but that, IMO, is within an accepted range compared to CRL that can take a lot longer. The downside is that the HTTPS handshakes now contain a bit more data, and we want to keep this as minimal as possible.
- yegle 1y ago
  I wonder if any free certificate issuers still support Must-Staple?
  - Ayesh 1y ago
    I don't think so. - Let's Encrypt: doesn't support it since May 7 this year - Buy Pass: No longer offers free certificates, probably didn't have must-staple either - Zero SSL, I didn't find any public links to check if they sign CSRs with it. - Google Trust Services: Same as above - Amazon Trust: Same as above, but it probably does.
- thayne 1y ago
  I don't think any browsers still support OCSP. The problem with OCSP stapling is that it either the client has to fall back to doing OCSP checking itself if the server doesn't staple the signature, which has its own problems[1], or enough servers need to support ocsp stapling that the client can just reject connections that don't include it. And unfortunately, there was never a significant uptake for servers, partly because there wasn't really any incentive to implement OCSP stapling. Maybe if there was a TLS 2.0 (or some other standard) that required OCSP stapling and had other benefits as well, it could work. [1]: the biggest problem with non-stapled OCSP is what to do if you don't get a response for the ocsp request. If you fail open, an attacker can intercept the request to prevent you from knowing the cert is revoked, but if you fail closed, then any issue with the connection to the ocsp server results in loss of service. And then there are also issues with additional latency to wait for the ocsp response, privacy leaks from the ocsp requests, etc.

deleted 1y ago

[deleted]

deleted 1y ago
[deleted]

Dylan16807 1y ago

If you don't do a job at all, have you done a bad job?

redleader55 1y ago

Checking for revocation doesn't scale and has serious privacy implications. There are two ways to do revocation: CRL and OCSP. CRL is a list that becomes huge over time - hosting it would require massive amounts of bandwidth and clients would need to download a lot of extra data. OSCP is more like a query API - did this cert expire? The problem is you need to make that query for each visit and you leak your IP address when you do that query. The hoster would need to provide capacity to run those queries and serve the result. For each visit you'd need to pay a few round-trips worth of delay before showing the content, sometimes while part of the content is downloaded: you download example.com, which has some CSS which is hosted at static.example.com, and the website redirects you to m.example.com which is the mobile version after running some JavaScript which detects the browser capabilities.

zephyreon 1y ago
So the answer then is just much shorter-lived certs? I could definitely still see the need for an immediate revocation to be recognized near-instantaneously. Or in practice is that ultimately not necessary?
- xyzzy_plugh 1y ago
  Yes, I think short-lived certs are ultimately where we're headed. We're starting to see adoption for O(days) now but I imagine that the lifetime will continue to decrease to some minimum O(hours) in the years to come.
  - zephyreon 1y ago
    Ironically this ends up putting a ton more load on the issuers, which some others have pointed out is why revocation doesn’t scale well (other than privacy concerns, which are valid).
  - toast0 1y ago
    I dread supporting O(hours). Clients often have wrong clocks. I've seen some client systems that enforced 'Not Before' and interpreted the datetime as local time and there were many users of that platform in the Americas; and my CA at the time insisted that Not Before was the time of issuance... lots of fun deciding how long to keep using a revoked certificate to balance the users with working revocation vs the users with broken Not Before checking. The client system I'm aware of is very dead, but maybe other systems managed similar.
sugarpimpdorsey 1y ago
> CRL is a list that becomes huge over time - hosting it would require massive amounts of bandwidth and clients would need to download a lot of extra data. Compared to what? 12MB JavaScript bundles and autoplay videos? Do CDNs still exist? There's a finite number of CAs and browsers can be expected to perform caching. Delta CRLs also exist and the CAs can decline to include expired leaf certs. This sounds like a made up problem that was solved 25 years ago.
- redleader55 1y ago
  If you cache the revocation list, you lose all the benefits of instant revocation making the whole process pointless.
  - sugarpimpdorsey 1y ago
    OCSP is dead. We don't have that luxury anymore. By caching I meant for 12-24 hrs.
    - redleader55 1y ago
      Again, if you need to revoke a certificate, it means something terrible happened - someone compromised your server and your website has a good chance to be impersonated by 3rd parties. In all the other cases, you just let the old cert expire. You likely don't want people finding out about the revocation 12-24 hours later.
      - robertlagrant 1y ago
        OCSP-stapling seemed to be fine with 24-48 hour client-side caching, though.
tjoff 1y ago
You could of course cache the list, only download whatever was new from a specific date. Short-lived certs would vastly reduce the list as well. Not really sure how big of a problem a list could be?
- pmontra 1y ago
  Let's see. I can cache the information that example.com is valid up to May 31 2026, but then how do I know that it gets revoked on any day before that date? And if I cache the information that it is revoked, how do I know that it's allowed again? I could check, let's say one time per day even if I don't access that site. In any case I'm still leaking which domains I browse and I keep trusting cached certificates until the next check. On the other side, with short lived certificates I would be trusting a certificate for a longer time, until it expires. Downloading a list of all certificates and their status from every CAs is probably unfeasible. It seems that we can't escape a tradeoff between privacy and security.
  - tjoff 1y ago
    You cache the revocation list, no? If it is in the list it is revoked... How do you know it is allowed again? Because it responds with a new certificate, that isn't revoked... You are not leaking anything. You are just downloading a list of revoked domains. Regardless of whether you are visiting them or not.
goalieca 1y ago
> CRL is a list that becomes huge over time IETF will be gradually reducing maximum length of public certs to 47 days. I expect this will help some of the issue since expired certs can be removed from the list.

Ayesh 1y ago

I was a big fan of OCSP-stapling and must-staple. Both of which are slowly being discouraged; LetsEncrypt refuses to issue must-staple certificates since a few months ago, and I think they are shutting down OCSP servers, if not shut down already. The idea with OCSP-stapling is that the webserver fetches the OCSP data, caches it for TTL ~24 hours, and staples it to the HTTPS handshake. That way, the browser does not need to query the issuer's OCSP servers, avoiding both performance and privacy concerns. Revoked certificates will continue to work for up to 24 hours, but that, IMO, is within an accepted range compared to CRL that can take a lot longer. The downside is that the HTTPS handshakes now contain a bit more data, and we want to keep this as minimal as possible.

yegle 1y ago
I wonder if any free certificate issuers still support Must-Staple?
- Ayesh 1y ago
  I don't think so. - Let's Encrypt: doesn't support it since May 7 this year - Buy Pass: No longer offers free certificates, probably didn't have must-staple either - Zero SSL, I didn't find any public links to check if they sign CSRs with it. - Google Trust Services: Same as above - Amazon Trust: Same as above, but it probably does.
thayne 1y ago
I don't think any browsers still support OCSP. The problem with OCSP stapling is that it either the client has to fall back to doing OCSP checking itself if the server doesn't staple the signature, which has its own problems[1], or enough servers need to support ocsp stapling that the client can just reject connections that don't include it. And unfortunately, there was never a significant uptake for servers, partly because there wasn't really any incentive to implement OCSP stapling. Maybe if there was a TLS 2.0 (or some other standard) that required OCSP stapling and had other benefits as well, it could work. [1]: the biggest problem with non-stapled OCSP is what to do if you don't get a response for the ocsp request. If you fail open, an attacker can intercept the request to prevent you from knowing the cert is revoked, but if you fail closed, then any issue with the connection to the ocsp server results in loss of service. And then there are also issues with additional latency to wait for the ocsp response, privacy leaks from the ocsp requests, etc.