Hacker News Reader

Comment by epistasis | Hacker News Reader

The black list of malware is called Xprotect and dates back to 2009. This check for revoked certificates is a different security layer.

The second check of an app is necessary to check for revocation: for a developer that decides that they've been compromised and wants to stop execution of their software. The alternative would be to use certificate revocation lists instead of OCSP. CRL lists can get long, so OCSP is often preferred to CRLs.

View on HN

Probably it's not necessary to check for revocation that often though. It could even be argued that it's only needed when the binary is updated.

And it's absolutely not normal to fail if that revocation check doesn't succeed anyway.

I've been wondering why CRL couldn't be used if the OCSP goes down or no reply is received. That way you get the benefits of both. Any reason why this would be a bad idea?

Also are CRLs really that bad in practice? I know it would be a bad idea on a smartphone but is it really an issue on a laptop?

The other main issue is bandwidth. For a CRL, Apple has to serve the full list of revoked serial numbers (or some shard of it), even if 90% of users don’t have 90% of the revoked apps installed. I can’t remember where I read this, but I recall that after the Heartbleed disclosure one CA saw their CRL traffic grow by some number in the gigabits per second. Bandwidth is relatively cheap, but still not free (without even considering the argument of “do I need to know that the cert for an app that I will never use is revoked?”).

They have the bandwidth for some pretty big firmware/OS updates, though. This would be a fraction of that size. They download blacklists already for their inbuilt AV. Also if they use something like Git then only the changes will be downloaded rather than the entire CRL.

I can’t help but feel that the issue is something else, not bandwidth.

Reply on news.ycombinator.com