Hacker News Reader

Comment by Someone1234 | Hacker News Reader

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

View on HN

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.

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.

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

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

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.

Reply on news.ycombinator.com