Hacker News Reader

Comment by bitL | Hacker News Reader

Why can't Apple download all footprints of bad apps locally instead of monitoring every single invocation of apps? Is second execution of an app the same security risk as the first one? That's the design flaw.

View on HN

You mean bad certificates rather than applications.

OCSP can be locally cached, and Apple's implementation does exactly that. But eventually you'll have to refresh the cache and then the implementation needs to be fault tolerant (Apple's wasn't).

OCSP leaks what vendors your installed applications are from. The list of leaked certificates changes daily, so any good implementation is going to check again at least several times a week. If you download the entire database, you're just consuming hundreds of megabytes of bandwidth/storage but aren't removing the need to refresh/expire the cache.

I'd argue the two biggest flaws Apple's system has is bad fault tolerance and also no user accessible opt out (even if just for emergencies).

> OCSP can be locally cached, and Apple's implementation does exactly that.

In the earlier HN thread when the server was offline, it was said that Apple only cached OCSP results for 5 minutes. Is that not true? If it is true, I don't think that's what GP is asking for as far as local caching.

It was changed after the event and is now 12 hours. Which is probably more appropriate considering that most people don't restart their applications every few minutes.

I wonder how hard it'd be to serve this data via DNS, like "dig -t TXT 0xdeadbeef.ocsp.apple.com". Then you get a nice, distributed architecture with lots of built-in cache handling, and since the data is currently served via HTTP, it wouldn't expose any more data to your ISP than already is today. It would also mean that if you have 100 people in the office and a local DNS cache, then each OCSP query would be made exactly once and then its answer shared among everyone else in the office.

That still tells people what you’re running, though.

Imagine you have a shared office DNS resolver (which is pretty common). That resolver would aggregate all of the requests into one shared, cached stream. Then the question becomes "hey Apple, one person of how ever many thousand are behind me would like to know if Adobe's certificate is still valid". That's reasonably anonymized, I think.

Then the question is, "how much do I trust my ISP/DNS provider?"

Those DNS lookups tell your ISP 1) that you use a mac and 2) that you have an application from a specific developer installed.

I think I trust my ISP less than I trust Apple, here. Am I wrong to do so?

Well, back to the state right now where your ISP can see your plaintext HTTP packets if they want to, so it wouldn't be any worse than the current situation. I guess you could get much the same effect by configuring your company Macs to point at a shared Squid server to cache the GET requests from the OCSP server, but in practice almost no one does that.

Apple says they're going to move to an HTTPS based system, so the relevant comparison is between HTTPS and DNS, not HTTP and DNS.

That only helps if you have a shared resolver.

Pretty much everyone has a shared resolver at some point. Almost no one’s running a local resolver on their laptop these days.

Differential downloads are a solved problem : https://docs.microsoft.com/en-us/windows/deployment/update/p...

Just so that I understand this correctly, by caching to you mean the results of a specific check, or as the above was implying, downloading the list of all bad signature and doing the check 100% locally.

The issue from my understanding was half the breakage, but half the fact that Apple was sending back telemetry about what apps you launched.

I doubt the full list of hashes of all revoked certs is 100s of MB, and even if it is, the daily update file surely isn't that big.

Right, and given that those certificates expire after some finite amount of time, this wouldn't be a forever-growing CRL, as expired certs could be dropped from the file periodically.

In answer to the first: Because the information is unreliable without more invasive technologies ensuring that the local file is up to date. To the second: Perhaps not, but if the information on bad actors (app distributors in this instance) you'll continue running a compromised app.

Are you familiar with OCSP conceptually? I have done a reasonable amount of work with signatures and certificates, including OCSP. All my experience is in a commercial, enterprise context but I think these technologies need to start filtering down to the consumer before the capability for security evaporates.

I think it's a consumer-positive direction for Apple to provide this service. I would be interested to hear from someone who holds the view that this is not a service, or disagrees in other ways, but I think this is the right direction for consumers. The alternative, as I see it, is that every person installing an app needs to start searching for CVE notices and headlines in trade papers declaring a compromise.

Apple have applied an enterprise middleware to their infrastructure. I think perhaps they could have been more transparent in the delivery. A lot of the outrage now is driven by people only finding out about the underlying process for the first time. I stand by the right of these companies to choose their business model to disallow (or restrict) execution of apps they believe to be compromised. I also firmly believe in a varied and free market for software, hardware, and infrastructure.

In essence: You can choose to use Apple and do it the Apple way. Equally you can choose to build your computer from components sourced from anywhere, install any free OS, and any apps. Personally I do choose to do it the Apple way, and I am inconvenienced by that from time to time. I curse my computer and its creators on a daily basis. It's part of the relationship we all build with our tools.

got a bit off track towards the end...

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.

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.

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.

Reply on news.ycombinator.com