Hacker News Reader

Comment by chrisshroba | Hacker News Reader

Since Bloom filters allow for false positives, wouldn’t that make them inappropriate here? You wouldn’t want a valid certificate to be perceived as revoked. (I recognize that I’m probably wrong, given that Mozilla is doing this - where is my mistake in logic?)

View on HN

Mozilla's solution to this is to run every single certificate in the CT log through the filter, and remedy any false positives with an extra layer. The filter also has a date attached, so potential false positives that are newer than the filter can be checked with OCSP.

https://blog.mozilla.org/security/2020/01/09/crlite-part-2-e...

That would be better than what we have here, though, where every application launch gets checked. The fallback with a Bloom filter is that you check a few apps, not all of them.

It’s better with a trade off. It removes the call-home to Apple, but adds the possibility of false positives for certificate revocation.

Is this in fact the trade-off we’re considering, or am I misunderstanding?

I think the idea is that false positives (cert revoked) result in a call home to Apple for an actual check.

The other idea is that because Apple knows all existing certificates, they could conceivably construct filters that have no false positives for those existing certificates... sort of like construction of a perfect hash.

You are misunderstanding. The bloom filter is only a preliminary check; if it indicates a revoked certificate, you then verify that it's a true positive the traditional way.

Oh of course. Thank you for clearing that up for me.

It’s just a precheck filter, where the bloom filter negative is the majority path, cutting out (the vast majority of) the leak.

The bloom filter positives still get normal checks.

Technically that's also possible with cryptographic hashing functions, but we still use them.

Reply on news.ycombinator.com