7 ms·

> Those who consider that Apple’s current online certificate checks are unnecessary, invasive or controlling should familiarise themselves with how they have co

by JackC 6y ago

> Those who consider that Apple’s current online certificate checks are unnecessary, invasive or controlling should familiarise themselves with how they have come about, and their importance to macOS security. They should also explain how, having enjoyed their benefits for a couple of years, they’ve suddenly decided they were such a bad idea after all, and what should replace them. I agree that anyone critiquing Apple's OCSP design should understand it, and the critique should be more nuanced than "just turn that feature off." Computers are now skeleton keys to our lives and we have to go forward rather than back in figuring out how to design them so they can safely do everything we need them to do. But it's not hard to justify the sudden criticism here -- it happened after Apple's bad design of the OCSP feature broke local applications, drawing a lot more attention to how it worked. It's reasonable to then ask whether other parts of the design were also poor, as Apple itself obviously is from the changes it's already announced. To take the author up on what should replace OCSP checks -- how about using something like bloom filters for offline checks, and something like haveibeenpwned's k-anonymity for online checks, to remove the possibility that either Apple or a third party could use OCSP for surveillance?

nmadden 6y ago
The browser vendors have been looking at this problem for a long time. See https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/ https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a... for example (bloom filters included).
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.
- 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...
flemhans 6y ago
How many revocations do they do? How about just downloading the whole list to the clients which they can check offline.
- JackC 6y ago
  It sounds like that's how it used to work, and then it changed for some reason, maybe to do with the size of the list and a need for faster updates. Actually that unknown exposes the problem with the original article's demand that critics explain what they want to replace Apple's system. No one outside of Apple is in a position to design a system that addresses all of the design constraints -- we don't even know what they all are. But we are in a position to assert some additional design constraints, such as requiring that the system not leak developer certs to eavesdroppers every time an application is run, and expect Apple to figure out a solution that takes them into account.
  - kelnos 6y ago
    > It sounds like that's how it used to work, and then it changed for some reason, maybe to do with the size of the list and a need for faster updates. If that's true, that's a lazy excuse on Apple's part. Differential updates has been a solved problem for many, many years. Hourly or even daily diffs would be tiny (likely much less traffic than the OCSP checks that occur now), and expired certs could be dropped from the local store, so it wouldn't grow without bound. (Sure, ok, people could turn their clocks back and defeat that last bit, but doing that would break other things, too, like TLS to any website with a reasonably recent cert.)

by JackC 6y ago

nmadden 6y ago

The browser vendors have been looking at this problem for a long time. See https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/ https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a... for example (bloom filters included).

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

flemhans 6y ago

How many revocations do they do? How about just downloading the whole list to the clients which they can check offline.

JackC 6y ago
It sounds like that's how it used to work, and then it changed for some reason, maybe to do with the size of the list and a need for faster updates. Actually that unknown exposes the problem with the original article's demand that critics explain what they want to replace Apple's system. No one outside of Apple is in a position to design a system that addresses all of the design constraints -- we don't even know what they all are. But we are in a position to assert some additional design constraints, such as requiring that the system not leak developer certs to eavesdroppers every time an application is run, and expect Apple to figure out a solution that takes them into account.
- kelnos 6y ago
  > It sounds like that's how it used to work, and then it changed for some reason, maybe to do with the size of the list and a need for faster updates. If that's true, that's a lazy excuse on Apple's part. Differential updates has been a solved problem for many, many years. Hourly or even daily diffs would be tiny (likely much less traffic than the OCSP checks that occur now), and expired certs could be dropped from the local store, so it wouldn't grow without bound. (Sure, ok, people could turn their clocks back and defeat that last bit, but doing that would break other things, too, like TLS to any website with a reasonably recent cert.)