1. 62
  1.  

  2. 42

    It’s funny how everyone here seems to express a sigh of relief that the mentioned question in the title has been “debunked”. I don’t think it has been, here’s why: Instead of the app signature, Apple is sent the developer signature. However, how is that not a big problem? The author gives Mozilla as an example of how Apple couldn’t tell if you were using Firefox or Thunderbird, but most developers only have one successful app and it’s trivial for Apple (and everyone on your (public) Wifi) to infer which apps you’re running because of that.

    This is a big deal and we should rightfully question this practice. I’m glad I left the Apple-ecosystem in 2012, because what we’re seeing here with all the code-signing madness and locking down is an iOS-ification of macOS, and there will be a point where you’ll be completely locked in and not able to run your hardware a few years beyond the last software update, because all the signatures will have expired. Have fun on this sinking ship if you still decide to stay!

    1. 5

      Or maybe – and I know this is something you probably are not prepared to accept, possibly not even capable of accepting – just maybe… other people see this differently than you do, or want to take different sides of a trade-off than you do, or, well, just don’t have exactly the same opinions as you on every conceivable thing under the sun, but still are acting rationally on the same set of information as you, and you should learn how to disagree with them without painting them as inherently stupid and/or evil.

      1. 5

        Wow, did my comment really hit that close to home? I could think of multiple (privacy-protecting and actually more efficient) other ways Apple could’ve shared revocations across their install-base. This is clearly about control and will only get worse. Anyone who believes in free general-purpose computing would be a madman staying in this ecosystem any longer.

        1. 4

          Wow, did my comment really hit that close to home?

          Seriously, just step back and take a look at yourself. You’ve demonstrated that it’s literally inconceivable to you that someone might disagree with you rationally and in good faith, by effectively saying you think it’s impossible for any person to disagree without being either mentally ill or outright evil. This is not a rational position and a rational person would not hold it!

          Anyone who believes in free general-purpose computing

          I will return to an analogy I’ve used before: Apple’s inclusion in their products of security features you personally dislike is as much a “war on general-purpose computing” as a generic corporate holiday greeting is a “war on Christmas”, and proponents of those two positions display, in my experience, roughly equal rationality and equal inability to be reasoned down from the precipices on which they’ve perched themselves.

          1. 2

            Keep using your Mac, if you do and are in a moral conflict, and see what this process leads to. I’ve been watching this with Apple for a few years and have seen numerous examples in the industry. This is not an emotional but an objective standpoint, and I don’t care about your feelings. Bring some counterarguments (instead of vague philosophical assertations) please, because otherwise this discussion here leads nowhere.

            1. 4

              there will be a point where you’ll be completely locked in and not able to run your hardware a few years beyond the last software update, because all the signatures will have expired. Have fun on this sinking ship if you still decide to stay!

              This is not an emotional but an objective standpoint, and I don’t care about your feelings.

              Uh huh, sure.

              I think what you fail to see is that a majority of users require this level of security. Apple has already stated they will add a method to turn off this verification and for those “hackers” it is as easy as blocking the traffic. OHHHH, what’s that you say? An Apple user has a choice? By gosh, I think the computer still works, that is amazing!

              I want to go back to your earlier point though, about hardware dying with a software updates. I’d like to point to the fact that I have a MacBook that is 7 years old and is still functioning just fine. Also, iPhones and iPads are notorious for their long term support compared to Android devices. Perhaps you are letting your emotions towards Apple get in the way here?

              1. 1

                I think what you fail to see is that a majority of users require this level of security. Apple has already stated they will add a method to turn off this verification and for those “hackers” it is as easy as blocking the traffic. OHHHH, what’s that you say? An Apple user has a choice? By gosh, I think the computer still works, that is amazing!

                As I said earlier, one can argue in favor of the benefits of this solution, but the implementation is strange and raises some serious concerns for privacy.

                I want to go back to your earlier point though, about hardware dying with a software updates. I’d like to point to the fact that I have a MacBook that is 7 years old and is still functioning just fine. Also, iPhones and iPads are notorious for their long term support compared to Android devices. Perhaps you are letting your emotions towards Apple get in the way here?

                I don’t have emotions against Apple and even recommend it to some of my customers who benefit from the ecosystem. Big Sur might be the last software update for your MacBook, and after a while (2-3 years) signatures will start expiring and you won’t be able to run software that’s otherwise perfectly fine.

                Apple has been locking down macOS for quite some time now. Every release is just a few degrees hotter for the proverbial frog in the water-pot. While a few degrees at a time might not be noticeable or can even be disregarded, the water will end up boiling at some point.

              2. 2

                You’re the one who made a series of claims, not least of which is that those who disagree with you are either evil (in that they knowingly and deliberately wage some type of war against “general-purpose computing”), or mentally ill (“madmen”, to use your term).

                You’ve provided no evidence for this other than vague mutterings about how you’ve been “watching this” and “seen numerous examples”.

                It is up to you, as the party making positive claims, to support said claims with evidence before you demand that someone else knock them down; this is, among rational people, the way debate and discussion is expected to proceed. And the fact that you don’t and likely won’t, but only retreat further into sneering (“I don’t care about your feelings”) and borderline insults, speaks eloquently about both you, and your claims.

                1. 1

                  Feel free to disregard what I’m saying, but the outcome will speak for itself. If you tolerate the obvious developments of the past few years, I can’t help you. Everyone is entitled to his own opinion and if you choose to spend your money there, it’s your freedom to do so. I’d still think of you as a madman, and you can’t shame me to think otherwise because I don’t measure myself to your standards.

                  1. 1

                    Feel free to disregard what I’m saying

                    Until you make a falsifiable claim and assert some evidence for it – other than your “feelings”, which is odd given what disdain you openly show for those of others – I will, because you are not participating in rational discourse.

                    I’d still think of you as a madman, and you can’t shame me to think otherwise because I don’t measure myself to your standards.

                    The fact that you still can’t handle someone disagreeing with you, without needing to insult or attack them, continues to speak volumes to anyone willing to listen.

      2. 13

        Good non-hysterical overview of ocsp.apple.com and trustd.

        1. 19

          I wouldn’t call it “Good”.

          First, the reason for not using HTTPS is nonsensical. You can obviously make an HTTPS request with a pinned apple cert distributed at OS install/update, no need for some “OCSP loop”. Also, by not pinning means this whole system is currently trivially MITM attacked.

          Second, I bet that 90%+ of dev certs are used to publish one single main app. Compiling a list of hashes to probable used app would be trivial and enough for profiling and spying reasons. You don’t even need the full picture of all apps. Simply compile a list of hashes for all dev certs of targeted software (VPN, encrypted messaging, etc) and you get a low-cost instant “snitch” telling you when someone is using any of these software.

          If the system isn’t fixed, I’m pretty sure we’ll see corporate firewalls start doing this as a feature. Here’s a business idea: Build a script that downloads every update for some targeted apps, provide this hash-to-app list as a paid for API.

          1. 13

            Just wanted to clarify that the review was a good review that looked at the actual technical details. I didn’t mean to comment on the quality of the apple trustd system itself.

            1. 10

              I for one am very happy that they didn’t use HTTPS, because with HTTP it is trivial to prove that no extra information is being sent. I wish more APIs would do this; if you claim you don’t send PII or private data, send it over HTTP with signed responses so I can verify your claim. If your claim is true, no harm done, if it’s false, you have two security issues.

              The OCSP response payload is signed, so the only MITM you can succesfully execute is preventing the signed response from reaching the client, either by mangling the request or the response. This is also possible with HTTPS by blocking DNS or the IP.

              It is true that the dev certificate observed by sniffing may give some idea of the kind of apps being run on a certain IP address, but so does traffic analysis, for which commercially available signature files already exist. Traffic analysis has the extra advantage that it’s not as easy to hide as blocking ocsp.apple.com in your hosts file.

              1. 12

                you could just use an open source os AND https

                1. 2

                  If open source were the solution to software secretly phoning home, we wouldn’t see articles about Firefox and Chromium doing just that.

                  The work involved in maintaining a stable fork with phoning home functionality removed is significantly more than just blocking ocsp.apple.com in your DNS server.

                2. 5

                  I appreciate this perspective, but I think that:

                  if you claim you don’t send PII or private data,

                  …hits at the crux here – I just don’t believe any more that any data worth sending isn’t private, even if it doesn’t meet the threshold of “PII”. That apple can log the apps you open (or, sure, which developers whose apps you open) seems to concern folks. If you don’t mind, then who cares if it’s clear-text. If you do, then this exposure just grew to… everyone on the network.

            2. 6

              Couldn’t Apple avoid this mess by making a local cache of approved certs on each Mac and updating it periodically? I.e. the same thing APT does for package metadata (for all packages available in enabled repositories). You can search the cache (with apt search or apt-cache search) without contacting any servers. Only, in the case of Apple, it wouldn’t be a cache of package metadata, but a cache of approved developer certs. Then they could check all the apps without contacting any servers. This way both privacy and performance concerns are addressed. It would also allow users to launch programs during server downtime.

              1. 8

                That is indeed what they do, for security reasons they don’t require an explicit action from the user to refresh the cache, but they do have a cache, and only check it if a certain amount of time has passed. From the article:

                I should also add that after closing Firefox and opening it again, no requests were made. This is reasonable, and indicates that certificate checking isn’t performed at each launch but only after it hasn’t been performed for a certain period of time.

                1. 6

                  That’s a different thing though. I’m talking about a cache of certificates, while the article seems to be talking about a cache of cert check responses. It means that server still gets some metadata about what programs the user launches. It’s also unclear why in this case people started having problems launching any non-Apple programs during server downtime.

                  1. 1

                    It needs to check in with the OCSP server occasionally to see if the developer certificate hasn’t been revoked, and the only way to chek using OCSP is to send the developer certificate to the OCSP server.

                    People started having problems because the OCSP was available reachable, but never responded with an OK, presumably because it was being overloaded by new Bug Sur requests.

                    1. 4

                      yakubin meant to have a full copy of all certificates on the computer and updating that in full every so often. Therefore no data about individual apps is sent over the network, when launching an app.

                      1. 2

                        One could also use the google safe links algorithm where a partial hash of the app is sent and a bunch of responses is sent such that the server doesn’t know which apps the client is actually using.

                        1. 2

                          That only solves the privacy issue. It doesn’t solve the problem of the time needed to launch an app and reliability of the system in the face of server downtime or packets dropped by a firewall. Generally, I don’t think that execve on its own should ever prompt any network communication.

                          EDIT: Your solution, by introducing frequent collisions, makes the whole mechanism essentially useless. Now you can’t differentiate between detected malware and legitimate software. To make it work at this point, you need to send the full hash to the server, defeating the point. I misunderstood, see @pgeorgi’s reply.

                          1. 4

                            Your solution, by introducing frequent collisions, makes the whole mechanism essentially useless. Now you can’t differentiate between detected malware and legitimate software. To make it work at this point, you need to send the full hash to the server, defeating the point.

                            The solution works like this: client to server: I have a hash here, starting with 12. server to client: I have a set of good hashes 1234, 1235, 1237 and bad hashes 1236, 1239. This set is good for 24 hours.

                            That way the server or a listener can’t infer which hash is specifically requested while the client gets precise information to work with (plus some more that they probably won’t need)

                            1. 1

                              I stand corrected. Still, it solves only one of the issues.

                              1. 2

                                Sure, it doesn’t solve all the issues, but some minor additions can. I think there are two reasonable approaches:

                                1. Periodically receive the total list of revoked certs from Apple (which is presumably not huge).
                                • benefit: privacy
                                • cost: latency (it takes a while for clients to discover that an application is bad), potentially bandwidth, tho it’s probably fine.
                                1. Use OCSP but with some privacy preserving measures, like the safe search thing
                                • benefit: latency, bandwidth
                                • cost: you have to decide what to do if you can’t get at the server, but that’s not super hard: timeout fast; and cache results.

                                If Apple had just set a really small timeout on their request this OCSP system would have worked fine and no one would have noticed this outage.

                                1. 2

                                  From the privacy point of view, looks like they will introduce encryption: https://www.macrumors.com/2020/11/15/apple-privacy-macos-app-authenticaion

                                  1. 2

                                    Thanks for the link. Obviously this approach only offers increased privacy Vs actors that aren’t Apple. But if you’re running a Mac obviously you have to trust Apple a bit, so I don’t think it’s unreasonable.

                      2. 2

                        The neat thing is that this means Apple can effectively remove software from your computer in addition to watching what you run.

                        1. 5

                          Everyone who ever built an antivirus or any sort of malware-removal tool is an active foot-soldier in the war against general-purpose computing, apparently. Seeing as all of those tools are designed to identify and remove software from your computer…

                          1. 1

                            Those all have an off switch

                            1. 4

                              As does Apple’s equivalent.

                          2. 2

                            So a professional is going to be checking if Transmission got their dev server owned this week instead of every single user having to check, cool.

                  2. 5

                    Finally, someone actually did dig deeper and inspected the actual requests and traffic.

                    On a side note, it’d be really nice if Apple would update the server side code to better handle soft failures due to slow connections or, well, their infrastructure failing for whatever reason. Many people are using their Macs all the time and many of us have real work to do on them, especially now in COVID times and a global outage on Apple’s end really shouldn’t make our machines slow to a crawl, under any circumstances, ever.

                    It’d be interesting to read the actual postmortem of the outage that started the hype.

                    1. 1

                      There is a response by apple to the Privacy issue: https://www.macrumors.com/2020/11/15/apple-privacy-macos-app-authenticaion/