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

31–40 of 72 posts

Re: A New Life for Certificate Revocation Lists

#31

Post by JohnFen »

TheSpiceIsLife wrote: post #26
frankjr wrote: post #25

> This means that they’re often very large – easily the size of a whole movie. Couldn't they just use actual units? This says absolutely nothing.

One Olympic swimming football bus tree worth of data. When I was reading the thread the other day about a trees worth of oxygen from the MOXIE experiment, I couldn't help thinking: why not just use a term everyone is familiar with, litres per minute air . Enough oxygen to sustain an adult at rest for x minutes. I'm beginning to suspect there's an in-joke with science / tech writers about strained analogies. And I'm n…

> I'm beginning to suspect there's an in-joke with science / tech writers about strained analogies.

Which has been going on for longer than I've been alive. The idea (I assume) is to take a large number that's hard to conceive and turn it into something everyone can relate to.

But inevitably, they choose things that few can actually relate to, or things that are so vague/variable to be meaningless. It just adds more confusion all around.

It has to be an intentional joke.

Re: A New Life for Certificate Revocation Lists

#32

Post by GauntletWizard »

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…

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.

Re: A New Life for Certificate Revocation Lists

#33

Post by WorldMaker »

frankjr wrote: post #25

> This means that they’re often very large – easily the size of a whole movie. Couldn't they just use actual units? This says absolutely nothing.

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.

Re: A New Life for Certificate Revocation Lists

#34

Post by WorldMaker »

michaelt wrote: post #30
tinus_hn wrote: post #2

Is certificate revocation really so common a crl of a normal authority is gigabyte sized?

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.

Re: A New Life for Certificate Revocation Lists

#35

Post by OrvalWintermute »

Lots of this information is completely bogus.

> But because OCSP infrastructure has to be running constantly and can suffer downtime just like any other web service, most browsers treat getting no response at all as equivalent to getting a “not revoked” response. This means that attackers can prevent you from discovering that a certificate has been revoked simply by blocking all of your requests for OCSP information.

This is false. Non-nonce OCSP is inherently cachable, and replayable. That means you can have your own HA setups with HA OCSP clients talking to HA OCSP servers (repeaters & responders) backed up by caching in commercial CDNs, and local caching servers like bluecoats.

Likewise, OCSP stapling helps remove much of the performance and privacy issues, pushing it to the serving webserver.

Beyond this, you can just use squid or localized HA OCSP services, and do some DNS rewriting to support it even more HA.

Nonced OCSP is the rare beast that needs to be online, but there are HA OCSP with smart OCSP clients.

> To help reduce load on a CA’s OCSP services, OCSP responses are valid and can be cached for about a week. But this means that clients don’t retrieve updates very frequently, and often continue to trust certificates for a week after they’re revoked.

Trust Stores are inherently manageable. The lag around revocation completely depends on CRL/OCSP publishing, and client update requests.

> And perhaps worst of all: because your browser makes an OCSP request for every website you visit, a malicious (or legally compelled) CA could track your browsing behavior by keeping track of what sites you request OCSP for.

This is why we advocate OCSP Stapling and use of CDNs for OCSP & CRL cache hits. Furthermore, localized OCSP mentioned above decentralizes this even further.

> So both of the existing solutions don’t really work: CRLs are so inefficient that most browsers don’t check them, and OCSP is so unreliable that most browsers don’t check it. We need something better.

CRLs & OCSP work pretty well when actually supported.

When Diginotar happened I polled every single publicly available commercial CA - strangely, a ton of them were not producing any CRL/OCSP at all, putting clients into a fail-open mode.

Lesson of the story: don't blame a protocol for lazy CAs, bad implementations, or the lack of operational excellence from many vendors.

Re: A New Life for Certificate Revocation Lists

#36

Post by coffee-- »

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.coffee/2020/12/01/crlite-part-4-infrast... )

Re: A New Life for Certificate Revocation Lists

#37

Post by OrvalWintermute »

er4hn wrote: post #23
tinus_hn wrote: post #2

Is certificate revocation really so common a crl of a normal authority is gigabyte sized?

The DoD uses x509, and CRLs, in those Common Access Cards (CAC) everyone in the org has. Since this covers most of the armed forces, that's fairly large. As of 2012[1] this was around 200 MB of CRLs and was only expected to get larger over time. [1] https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/pdf/uncl... - Pg 7, under Local Cache

As mentioned above, DoD uses smart strategies around certificate validation.

CDNs + Localized OCSP + Tactical OCSP + Smart OCSP Clients + Network caching + OCSP & CRLs on the filesystem, just to name a few (not including delta CRLs and other solutions).

The DoD OCSP Responders are configured to share hash sets with downstream OCSP Responders & Repeaters, which makes promulgation particularly easy.

Re: A New Life for Certificate Revocation Lists

#38

Post by OrvalWintermute »

GauntletWizard wrote: post #32
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…

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

Re: A New Life for Certificate Revocation Lists

#39

Post by agwa »

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

Re: A New Life for Certificate Revocation Lists

#40

Post by OrvalWintermute »

WorldMaker wrote: post #33
frankjr wrote: post #25

> This means that they’re often very large – easily the size of a whole movie. Couldn't they just use actual units? This says absolutely nothing.

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)
Post reply on HN