Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A New Life for Certificate Revocation Lists

letsencrypt.org

Post reply on HN
Print view View original

41–50 of 72 posts

Re: A New Life for Certificate Revocation Lists

#41

Post by OrvalWintermute »

mholt wrote: post #7
xoa wrote: post #4

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 si…

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 ( 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 lif…

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.

Re: A New Life for Certificate Revocation Lists

#42

Post by GauntletWizard »

OrvalWintermute wrote: post #38
GauntletWizard wrote: post #32

Earlier quoted context omitted.

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 certific…

> 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…

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

Revocation checking is useful for your security team to blacklist site. That's the only useful use.

Re: A New Life for Certificate Revocation Lists

#43

Post by coffee-- »

champtar wrote: post #6
xoa wrote: post #4

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 si…

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

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#!cumula...

[2] "prerelease" https://probes.telemetry.mozilla.org/?search=stapl&view=deta...

Re: A New Life for Certificate Revocation Lists

#44

Post by tialaramex »

shallichange wrote: post #20
mholt wrote: post #15

Earlier quoted context omitted.

It's a good question, if I read you rightly. There is no "handful" of intermediate certificates -- there are precisely 4 (for Let's Encrypt [0]) and they are essentially on-line root certificates. And if those certificates aren't even compromised, revoking them would only harm the ecosystem. [0]: https://letsencrypt.org/certificates/

According to the link you posted, there are intermediate CAs. Those could be revoked and effectively revoke all the end entity certificates.

When they write "essentially on-line root certificates" they don't mean that they're literally on-line root certificates, because that's prohibited.

They're essentially on-line root certificates because they serve most of the function that such roots would serve if they were allowed. There aren't a bunch more available to replace them, so this means recovery now requires a key ceremony, figure on a week to a month to arrange that.

Whereas if you're able to "just" revoke 10 million end entity certificates you can recover immediately.

Re: A New Life for Certificate Revocation Lists

#45

Post by WorldMaker »

OrvalWintermute wrote: post #40
WorldMaker wrote: post #33

Earlier quoted context omitted.

The article does later state Lets Encrypt's own expected worst case is 8 GBs in one CRL file in the hopefully unlikely scenario that every unexpired certificate they manage was revoked.

Merkle Hash Trees are the well-known solution for this, whenever they decide to update the protocols (was software patent encumbered til 2017)

It sounds close to what the article suggests Let's Encrypt is using internally to store/generate the CRL files, though the article doesn't get into a lot of technical details to tell exactly if that is the case.

Re: A New Life for Certificate Revocation Lists

#46

Post by tialaramex »

agwa wrote: post #39
phlip9 wrote: post #29

I can't wait for some big site certs to false positive in a CRL bloom filter and cause a big outage : )

J.C. has already answered for Firefox; for Apple's system (valid.apple.com), if there's a bloom filter hit, the client double checks via OCSP before failing the connection. Source: a WWDC 2017 talk which unfortunately I can't find online anymore

A concern is: Does it fail closed? It's easy to imagine an Apple engineer finds this fails sometimes for crap-CA whose OCSP server is kinda-sorta maybe working, in Bremen at least, usually, although not on weekends, and they go "Oh, I can fix this, just ignore if it fails" and now we've got our old friend the "Seatbelt that snaps when you crash" back.

Mozilla's choice here avoids that problem coming up which means nobody needs to push back when it gets "solved" in this regressive way.

Re: A New Life for Certificate Revocation Lists

#47

Post by agwa »

tialaramex wrote: post #46
agwa wrote: post #39

Earlier quoted context omitted.

J.C. has already answered for Firefox; for Apple's system (valid.apple.com), if there's a bloom filter hit, the client double checks via OCSP before failing the connection. Source: a WWDC 2017 talk which unfortunately I can't find online anymore

A concern is: Does it fail closed? It's easy to imagine an Apple engineer finds this fails sometimes for crap-CA whose OCSP server is kinda-sorta maybe working, in Bremen at least, usually, although not on weekends, and they go "Oh, I can fix this, just ignore if it fails" and now we've got our old friend the "Seatbelt that snaps when you crash" back. Mozilla's choice here avoids that problem coming up which means no…

That is a very good question and I don't know the answer, but if you want to go source code spelunking, you can probably find the answer on https://opensource.apple.com/

Re: A New Life for Certificate Revocation Lists

#48

Post by tialaramex »

WorldMaker wrote: post #34
michaelt wrote: post #30

Earlier quoted context omitted.

According to [1] "On a typical Monday, we would expect to see a total of around 22,000-30,000 SSL certificates being revoked over the course of the day." i.e. ~8 million per year. [3] meanwhile says "1.8 million certificates are revoked per year" Looking at a random CRL [2] it's 41 bytes per revoked certificate. 8 million records at 41 bytes per record would be 300+ Megabytes. And a cautious CA might keep revoked cer…

> And a cautious CA might keep revoked certificates in their CRL for more than a year. A CA does need to keep the revoked certificate in the CRL until at least the natural expiration date on the certificate, so for the CAs that give certificates out with 5 years out or more expiration dates, they may need to keep CRLs for much longer than just a year just naturally by nature of their expiration dates.

This CRL rule is about the Web PKI, for which currently policy requires new certificates expire after no more than 398 days.

The previous status was the certificates could last up to 825 days, however that policy changed at the end of August 2020, so there are no extant certificates under those rules which expire after this year. And before that the policy was 39 months, but the last such certificate expired in 2021. Before that the policy was 5 years, but that policy changed in 2015 and so such certificates are long expired.

Re: A New Life for Certificate Revocation Lists

#49

Post by coffee-- »

mholt wrote: post #7
xoa wrote: post #4

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 si…

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 ( 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 lif…

Another tool in the toolbox is ARI. https://datatracker.ietf.org/doc/draft-acme-ari/

Re: A New Life for Certificate Revocation Lists

#50

Post by phlip9 »

coffee-- wrote: post #36
phlip9 wrote: post #29

I can't wait for some big site certs to false positive in a CRL bloom filter and cause a big outage : )

CRLite builds a cascade of Bloom filters to ensure no false positives. For Firefox end users, a certificate only gets tested against the filter cascade if it is known to have been included in its creation (by examining the embedded SCT timestamps). If it's not definite that the certificate was used to generate the filter, then Firefox reverts to OCSP. (I'm one of the authors of CRLite in Firefox: https://insufficient…

Ahh thanks for the link and sorry for the snark; the finite universe optimization is cool! [0]

  # Why is CRLite able to compress so much data?
  
  Bloom filters are probabilistic data structures with an error rate due to data collisions. However, if you know the whole range of data that might be tested against the filter, you can compute all the false positives and build another layer to resolve those. Then you keep going until there are no more false positives. In practice, this happens in 25 to 30 layers, which results in substantial compression.
EDIT: Is there any risk of filter blow up (think 1000's of layers) if a CA did a mass revocation (maybe some root key leak)?

[0] https://github.com/mozilla/crlite/wiki#why-is-crlite-able-to...

Post reply on HN