4 ms·

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 securi

by bitL 6y ago

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.

Someone1234 6y ago
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).
- pydry 6y ago
  Differential downloads are a solved problem : https://docs.microsoft.com/en-us/windows/deployment/update/psfxwhitepaper https://docs.microsoft.com/en-us/windows/deployment/update/p...
- loeg 6y ago
  > 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.
  - rbrtl 6y ago
    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.
- kstrauser 6y ago
  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.
  - saagarjha 6y ago
    That still tells people what you’re running, though.
    - kstrauser 6y ago
      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.
      - nickodell 6y ago
        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?
        kstrauser 6y ago
        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.
- ehsankia 6y ago
  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.
- aftbit 6y ago
  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.
  - kelnos 6y ago
    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.
deleted 6y ago
[deleted]
epistasis 6y ago
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.
- als0 6y ago
  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?
  - marksomnian 6y ago
    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?”).
    - als0 6y ago
      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.
- benhurmarcel 6y ago
  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.
deleted 6y ago
[deleted]
rbrtl 6y ago
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...

by bitL 6y ago

Someone1234 6y ago

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

pydry 6y ago
Differential downloads are a solved problem : https://docs.microsoft.com/en-us/windows/deployment/update/psfxwhitepaper https://docs.microsoft.com/en-us/windows/deployment/update/p...
loeg 6y ago
> 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.
- rbrtl 6y ago
  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.
kstrauser 6y ago
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.
- saagarjha 6y ago
  That still tells people what you’re running, though.
  - kstrauser 6y ago
    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.
    - nickodell 6y ago
      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?
      - kstrauser 6y ago
        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.
ehsankia 6y ago
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.
aftbit 6y ago
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.
- kelnos 6y ago
  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.

deleted 6y ago

[deleted]

epistasis 6y ago

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.

als0 6y ago
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?
- marksomnian 6y ago
  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?”).
  - als0 6y ago
    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.
benhurmarcel 6y ago
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.

deleted 6y ago

[deleted]

rbrtl 6y ago

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