Hacker News Reader

Comment by 001sky | Hacker News Reader

According to Paul Mutton, a security consultant at the Web services company Netcraft. Checking a site’s identity will take vastly longer.
“If a certificate authority has to revoke 10,000 certificates, that entry will have 10,000 certificates on it,” Mutton said. “And if browsers have to download that . . . we’re talking hundreds of megabytes.”

It’s roughly the equivalent of having to download 30 minutes’ worth of standard-definition video just to view a single Web page.

> is this accurate?

View on HN

I don't know much about how CRLs work, or what the "authoritative" clearinghouse for the CRL list is (if any) but ideally your browser only needs to download the bulk list once, then based on checksums or timestamps should just download diffs since the last version it had.

Basically we need a git repo for CLRs.

It's not accurate: They are making the same mistake as in other recent HN articles, that the entire certificate (1k-2k) is listed on the CRL.

It's not. It's serial number, a timestamp, maybe one or two other things. 10,000 certs is maybe 40,000 bytes on a RL.

No, you won't have to re-download the revocation list every time you open a web page. That would be ridiculous.

But if you want to be really secure, you might want to check the revocation list every time you see a new certificate.

Would it be possible to use a probabilistic data structure (e.g. Bloom filter) to create a privacy-enabled CRL as a service?

I don't see why not, especially because you already have the old key signature/fingerprint to use when pushing it into the Bloom filter. Seems like a perfect case for it, actually.

You could distrust any certificate that was signed before April 7 (or some slightly later date). It might be easier to do that and whitelist the good "pre-apocalypse" certificates. The nice thing about doing this is that your whitelist will inherently go to zero as certificates time out and get renewed (typically 1-3 years?).

The hard thing would be to generate an accurate whitelist.

We had certs that were only used and present on machines that were not vulnerable, and therefore did not replace or revoke them. Please don't do this.

Furthermore servers that weren't even using OpenSSL or the particular version(s) that were susceptible. What is the actual percentage of servers that needed to react to this?

I dunno... Probably worth it from a netsec point of view.

Doesn't work, since rekeyed certificates are often (mostly?) backdated to have the same valid-from date as the old certificate.

I updated my key and certificate, and for the browser-visible certificate metadata only the fingerprint changed.

For all that you've heard about the disaster side, there's also a huge number of sites that weren't affected. Whitelisting wouldn't help much.

Reply on news.ycombinator.com