3 ms·

The principle here is good (check if the developer’s certificate is revoked) but the implementation is completely batshit. Why not cache the result and send a p

by ponker 6y ago

The principle here is good (check if the developer’s certificate is revoked) but the implementation is completely batshit. Why not cache the result and send a push notification through the centralized channels if there is a Sev1 revocation incident?

jozzas 6y ago
This is a really good point, there is no good reason to have millions of devices phone home for permission on every single app open. If Apple's claim is to be believed there are a million patterns that make more sense for achieving this goal. Blacklists, whitelists, caching, etc. I get "never attribute to malice what can be explained by incompetence", but this is Apple. Are we to believe that this public, unencrypted endpoint was set up and is being called tens of millions of times a day because Apple engineers were too incompetent to come up with a better solution for something so fundamental (to Apple) as the security of the software running on their devices? And flying so blatantly in the face of their claim to protect user privacy? This whole incident is completely bonkers. People should be getting fired over this and there should be an apology and a massive step back from this horrible, horrible approach.
- bobbylarrybobby 6y ago
  After this incident I’ve found it hard to buy the “but this is Apple” line of reasoning. I think their processes are just plain bad. https://arstechnica.com/information-technology/2017/11/macos-bug-lets-you-log-in-as-admin-with-no-password-required/ https://arstechnica.com/information-technology/2017/11/macos...
- rsfinn 6y ago
  This article by Jacopo Jannone refutes the notion that macOS sends an application's hash to Apple "on every single app open": https://blog.jacopo.io/en/post/apple-ocsp/ https://blog.jacopo.io/en/post/apple-ocsp/ Also in that article, the OCSP protocol is supposed to go over HTTP and not HTTPS: "If you used HTTPS for checking a certificate with OCSP then you would need to also check the certificate for the HTTPS connection using OCSP." Furthermore, the returned information apparently includes a timeout period for the result to be cached at the endpoint, and according to Jeff Johnson, Apple has raised that timeout in the wake of Thursday's incident from 5 minutes to 12 hours: https://lapcatsoftware.com/articles/ocsp.html https://lapcatsoftware.com/articles/ocsp.html There's certainly room to argue about Apple's approach, but let's make sure we're arguing about the actual behavior.
pilif 6y ago
The protocol in use is OCSP. The OCSP endpoint is part of the certificate. If I had to guess, I would say that they just relied on certificate validation features of the library they are using, not necessarily aware of all of the consequences. Checking OCSP is a standard feature of many SSL libraries. Doing what you suggest is an implementation outside of what standard libraries would provide and was probably completely out of scope until now when stuff started burning. Don't call relying on standard features of an underlying library "batshit implementation". For the vast majority of cases going with what's already there is the way better solution than NIHing your custom thing
- johncolanduoni 6y ago
  To be fair, they fully control the library they’re using, as they have their own x509 library and API in Core Foundation. But it also supports CRLs so I’m somewhat circumspect this is the reason. More likely it’s the server side: CRLs have fallen out of popularity because they don’t work well for the scope of most CAs. On the web OCSP doesn’t have the drawbacks it does in this situation because servers themselves can staple OCSP responses instead of forcing the client to fetch them itself. Obviously the same doesn’t quite work for binaries sitting on a user’s disk.
  - pilif 6y ago
    > To be fair, they fully control the library they’re using, as they have their own x509 library and API in Core Foundation. But it also supports CRLs so I’m somewhat circumspect this is the reason. yes. if of course it's their library. But I assume the caller was just calling some (imaginary) function like validate_cert(cert, ENABLE_ALL_CHECKS); and that was it. That ENABLE_ALL_CHECKS would then go out to check the OCSP server was probably not immediately known or was just seen as something that's part of, well, enabling all checks without much additional thought. Whether the certificate also lists a CRL endpoint and whether that imaginary ENABLE_ALL_CHECKS also checks that I don't know, but possibly neither did the person who called that (imaginary) function. Heck, the function might even default to ENABLE_ALL_CHECKS internally at which point the author of this code in question might not even have been aware of the network calls.
alacombe 6y ago
> The principle here is good (check if the developer’s certificate is revoked) How is that remotely good ? It makes it easy to bully / blackmail developer to abide to every Apple will and revoke a certificate in pure retaliation, cf. the Epic debacle. A central authority can't be trusted.

by ponker 6y ago

jozzas 6y ago

This is a really good point, there is no good reason to have millions of devices phone home for permission on every single app open. If Apple's claim is to be believed there are a million patterns that make more sense for achieving this goal. Blacklists, whitelists, caching, etc. I get "never attribute to malice what can be explained by incompetence", but this is Apple. Are we to believe that this public, unencrypted endpoint was set up and is being called tens of millions of times a day because Apple engineers were too incompetent to come up with a better solution for something so fundamental (to Apple) as the security of the software running on their devices? And flying so blatantly in the face of their claim to protect user privacy? This whole incident is completely bonkers. People should be getting fired over this and there should be an apology and a massive step back from this horrible, horrible approach.

bobbylarrybobby 6y ago
After this incident I’ve found it hard to buy the “but this is Apple” line of reasoning. I think their processes are just plain bad. https://arstechnica.com/information-technology/2017/11/macos-bug-lets-you-log-in-as-admin-with-no-password-required/ https://arstechnica.com/information-technology/2017/11/macos...
rsfinn 6y ago
This article by Jacopo Jannone refutes the notion that macOS sends an application's hash to Apple "on every single app open": https://blog.jacopo.io/en/post/apple-ocsp/ https://blog.jacopo.io/en/post/apple-ocsp/ Also in that article, the OCSP protocol is supposed to go over HTTP and not HTTPS: "If you used HTTPS for checking a certificate with OCSP then you would need to also check the certificate for the HTTPS connection using OCSP." Furthermore, the returned information apparently includes a timeout period for the result to be cached at the endpoint, and according to Jeff Johnson, Apple has raised that timeout in the wake of Thursday's incident from 5 minutes to 12 hours: https://lapcatsoftware.com/articles/ocsp.html https://lapcatsoftware.com/articles/ocsp.html There's certainly room to argue about Apple's approach, but let's make sure we're arguing about the actual behavior.

pilif 6y ago

The protocol in use is OCSP. The OCSP endpoint is part of the certificate. If I had to guess, I would say that they just relied on certificate validation features of the library they are using, not necessarily aware of all of the consequences. Checking OCSP is a standard feature of many SSL libraries. Doing what you suggest is an implementation outside of what standard libraries would provide and was probably completely out of scope until now when stuff started burning. Don't call relying on standard features of an underlying library "batshit implementation". For the vast majority of cases going with what's already there is the way better solution than NIHing your custom thing

johncolanduoni 6y ago
To be fair, they fully control the library they’re using, as they have their own x509 library and API in Core Foundation. But it also supports CRLs so I’m somewhat circumspect this is the reason. More likely it’s the server side: CRLs have fallen out of popularity because they don’t work well for the scope of most CAs. On the web OCSP doesn’t have the drawbacks it does in this situation because servers themselves can staple OCSP responses instead of forcing the client to fetch them itself. Obviously the same doesn’t quite work for binaries sitting on a user’s disk.
- pilif 6y ago
  > To be fair, they fully control the library they’re using, as they have their own x509 library and API in Core Foundation. But it also supports CRLs so I’m somewhat circumspect this is the reason. yes. if of course it's their library. But I assume the caller was just calling some (imaginary) function like validate_cert(cert, ENABLE_ALL_CHECKS); and that was it. That ENABLE_ALL_CHECKS would then go out to check the OCSP server was probably not immediately known or was just seen as something that's part of, well, enabling all checks without much additional thought. Whether the certificate also lists a CRL endpoint and whether that imaginary ENABLE_ALL_CHECKS also checks that I don't know, but possibly neither did the person who called that (imaginary) function. Heck, the function might even default to ENABLE_ALL_CHECKS internally at which point the author of this code in question might not even have been aware of the network calls.

alacombe 6y ago

> The principle here is good (check if the developer’s certificate is revoked) How is that remotely good ? It makes it easy to bully / blackmail developer to abide to every Apple will and revoke a certificate in pure retaliation, cf. the Epic debacle. A central authority can't be trusted.