Privacy concerns with Silicon Macs

[Joelist]

None of my apps had any issues whatsoever during the server outages, and also I frequently am using my MBP with no internet enabled at all (WiFi off to covserve power when on the road) and everything opens and runs just fine. So obviously the idea that it checks every time is incorrect.

@leman is correct; this is just routine OCSP stuff and the usual suspects are generating FUD to get clicks.

 

[theSeb]

Just want to caution that RFCs are simply uniform standards that are expected to be followed. We don’t really know how data on Apple’s end is inferred from what it receives. Sure, it’s borderline conspiracy, but if you have ever implemented a RFC, you would know there is always a possibility.

I believe the irony out of all this is Apple preaches privacy but are not fully transparent about what dependencies are involved. The mere fact that something as simple as this can halt businesses from being productive is very concerning. It certainly caught a lot of IT and users offguard globally.

I have implemented various RFCs. Sure, I could have tried to get the ATM to actually put 0.0002 cent into a secret account out of every transaction fee, but reality does not quite work that way, or it does for a short time before catching up with you. We have code audits to prevent that sort of thing and people are just really bad at keeping secrets.

At some point you have to trust someone digitally speaking and if you do not feel comfortable trusting the maker of the operating system that you are using, then you should be looking for a different one.

There are a few things here though that we must consider. This isn't a new thing. It's been going on since Catalina was released. Jeff from the op's link isn't the only one concerned about this kind of thing. There are many people who are far more qualified that would have raised privacy flags a long time ago. The only reason why Jeff picked this up is because of the issue with Apple's servers last week. He then did some thinking and decided that 2 + 2 = 5.

It's silent and invisible, but also everyone can see. Pick a lane and stick with it. The link to https://en.wikipedia.org/wiki/Room_641A was a beautiful and alarmist touch. The author needs to capture the info and show what he has captured. He hasn't. It should be really simple, especially for someone claiming to be hacker and a security specialist. Capture the traffic and show a screenshot of the information to add some substance to the alarmist article.

Instead the author then proceeds down some country lane on a destinatin to I have no idea where.

He's just making things up at this point in time. What is this? He is saying that because you have an IP address you can now make this table. Notice he isn't saying that Apple is doing this. He is saying that it allows for this. Well, having a car allows me to drive it off a bridge.

Application hash? No, it's not sending "application hashes". That's not how any of this works. Like I've already said above, the author is welcome to actually prove his case by capturing the traffic and showing his work. But he does not. He also claims that Apple is then storing the requests in a table, like he suggested, and is doing *something* with this information.

I did giggle at the mention of "Akamai" as if he's just letting people in on a big secret conspiracy. Look, if you are not going to trust Akamai, then you may as well stop using the internet immediately.


What about the fact that this is unencrypted?

From wikipedia:

If you are truly the target of a MIM attack, then, believe me, you have far bigger concerns than somebody finding out what apps you are using at what time.

There are control issues / concerns here. I do not see privacy issues. The control concern is that Mac OS is moving towards a controlled ecosystem like iDevices. How much further it will go is something that we don't know yet.

 

[mac.ross]

I find all the drama over this genuinely hilarious, it's like people are for the first time finding out how basic networking and security concepts work and it all terrifies them.

If there is a decent level of security and certificates are involved then there has to be an authority that the validity of the certificates are checked against, that's just how it works and if it's something you're worried about then I don't recommend going on the internet ever again because that's the only way you'll avoid this no matter which device you use.

 

[jeanlain]

I'm not concerned about the privacy side of the issue, but I'm concerned about the fact that the other day, my applications took ages to launch. Isn't there a better solution than calling home?

 

[theSeb]

I'm not concerned about the privacy side of the issue, but I'm concerned about the fact that the other day, my applications took ages to launch. Isn't there a better solution than calling home?

That's an issue of poor implementation and poor testing. They didn't anticipate this particular case and the code did not work as it should have. The solution itself does make sense, if implemented correctly.

 

[mac.ross]

I'm not concerned about the privacy side of the issue, but I'm concerned about the fact that the other day, my applications took ages to launch. Isn't there a better solution than calling home?

Honestly, OCSP is probably the best solution, the only problem for me personally is that if it fails it should do so in a more graceful manner rather than just a hard failure we were seeing.

For normal day-to-day operations OCSP is far better than the alternatives like Certificate Revocation Lists, in the CRL method you check the certificate against a large list that is periodically downloaded but searching through the thousands of entries in the CRL can take a relatively long time and this inefficiency is the main problem, that's not to mention that since CRLs are only periodically updated there can be a period where there's a known bad certificate but users still don't have the most recent version of the CRL to compare against and malicious code is able to run.

Rather than deal with whole lists OCSP instead means you can just ask the Certificate Authority 'Hey, I have this certificate, is it valid' and they'll respond whether that single certificate is valid or not without you having to trawl through a massive list.

The problems with OCSP revolve around the availability of the OCSP Responder which is the part of the Certificate Authority that deals with OCSP queries, if it's not able to respond as in this instance the trust basically falls apart.

Honestly, I think Apple should just make a statement and make it clear that they don't store these certificate queries in any way and improve their OCSP implementation to include a more graceful fail state with something like Stapling.

 

[jeanlain]

https://sneak.berlin/20201112/your-computer-isnt-yours/ has been updated, please read it again.
The Apple community is upset.

What is the "Apple community" you speak of? Because none of the Apple users I know, and I know plenty, is even aware of the issue.

 

[JMacHack]

Did you read the article? Little Snitch can't protect you in Big Sur. By getting rid of Kernel Extensions and forcing them to use an API, they made it so that it can't check or block OS level calls.

I should've specified it was for Mojave.

 

[venom600]

Honestly, I think Apple should just make a statement and make it clear that they don't store these certificate queries in any way and improve their OCSP implementation to include a more graceful fail state with something like Stapling.

What they should do is give us the ability to turn it off if we don't want to have to trust them. I don't care if it's an
obscure terminal command... I don't want my machine phoning home. If you don't care, leave it on. The choice should be up to the user.

 

[egalitarian]

I feel that a lot of users commenting here doesn't quite understand the security implications of this. Let's unpack these a little bit. The problem is not that the information is sent to Apple - after all they already have a lot of information on you. The protocol is unencrypted which is its major flow. Saying that it is a standard doen't change the fact that it is unsecure the same way HTTP and FTP are unsecure and should be avoided.

Anyone sitting between you and the apple server could intercept the message and see in most cases not only who is the app developer but also if the developer has only one app what app are you actually running and when. This means that in most cases they could know your daily routine — when you are at home, when you are asleep, etc. They could even know your profession if you use specific apps. This is a privacy nightmare. Everybody saying that this is standard in other OSs please provide examples as this is really not the case. If the protocol was encrypted only Apple would have this information.

This could be easily solved using two methods:

1. Encrypt the OCSP message with offline public key and update the key from an apple server when changed (very easy to implement)

2. Checking the application signatures locally using an offline list which also updates when needed downloading only the difference. This is the most private method which also happens to generate the least traffic and is also the fastest for the user experience (a little bit harder to implement but still very easy to do)

The mere fact that Apple left this the way it is shows the level of concern for you privacy. It doesn't matter if this information is broadcasted every time an app is started or cached for several hours or days. That is information that should never leave your computer unencrypted.

 

[leman]

I feel that a lot of users commenting here doesn't quite understand the security implications of this. Let's unpack these a little bit. The problem is not that the information is sent to Apple - after all they already have a lot of information on you. The protocol is unencrypted which is its major flow.

This is the only relevant point worthy of discussion in this entire story. It's just a shame that it has been presented in such a reckless, sensational and misleading way by Jeffrey Paul.

Anyway, let's discuss this.

Anyone sitting between you and the apple server could intercept the message and see in most cases not only who is the app developer but also if the developer has only one app what app are you actually running and when. This means that in most cases they could know your daily routine — when you are at home, when you are asleep, etc. They could even know your profession if you use specific apps. This is a privacy nightmare.

I am not sure I agree that this is such a critical privacy issue as you argue. Let's assume that a malicious party is at a position to intercept your traffic. First of all, I am not sure how these validation requests would provide them with any information that they already won't know. They will already know when you are asleep and when you are at home etc. by simply analyzing your general traffic. They will know which servers you connect to and even which websites you visit (DNS traffic is not encrypted).

The only information they might get is — as you say — a general idea which apps might be installed on your machine. They won't necessarily know which apps you use or what are your routines when because the OCPS requests are only sent out sporadically. I agree that this is a privacy concern. I don't necessarily agree that this is a critical privacy concern — as much of this information is very easy to obtain without analyzing the OCPS traffic. They can trivially guess your profession by checking whether your computer regularly connects to servers of known applications such the Adobe suite etc. Heck, they will even know which banking software and which stock broker you use — again, simply by analyzing your IP traffic. There is not much that developer certificate validation would add here to the information that is already out there — unencrypted and in plain sight.

1. Encrypt the OCSP message with offline public key and update the key from an apple server when changed (very easy to implement)

This seems straightforward to me and if it is indeed an easy update that will provide a bit more privacy, why not? At the same time, simple encryption won't work. Just encrypting the certificate ID it using a key would not hide any information — it would just remap it to a different hash. You will need to use one of the handshake-based encryption protocols with per-connection negotiated shared secret. Is it viable? No idea. Not my area of expertise.

2. Checking the application signatures locally using an offline list which also updates when needed downloading only the difference. This is the most private method which also happens to generate the least traffic and is also the fastest for the user experience (a little bit harder to implement but still very easy to do)

From what I gather, this method (Certificate Revocation Lists) was the precursor to OCSP but is not used much anymore, because it actually doesn't work that well. The problem in the nutshell: there would be a LOT of revoked certificates (there are millions of registered Apple developers after all), so maintaining a database on each active Apple device (over a billion of them) as well as synchronizing it frequently would be a major traffic generator.

Here is link I found discussing this issue: https://www.fir3net.com/Security/Concepts-and-Terminology/certificate-revocation.html

 

[RogerWade]

Disgusting, I'm downloading Little Snitch to block this now. I was wondering why my laptop was freaking out yesterday and now I know. Even if I wasn't concerned about privacy, having that affect the user experience is downright annoying.

Little Snitch won't work.

 

[egalitarian]

I agree on some of your points and they apply to most of the users but not all. Mostly the ones not caring about their privacy much or the ones not technically savvy enough to improve it. I'll explain why.

I am not sure I agree that this is such a critical privacy issue as you argue. Let's assume that a malicious party is at a position to intercept your traffic. First of all, I am not sure how these validation requests would provide them with any information that they already won't know. They will already know when you are asleep and when you are at home etc. by simply analyzing your general traffic. They will know which servers you connect to and even which websites you visit (DNS traffic is not encrypted).

DNS traffic could be unencrypted or encrypted (e.g. by using DNScrypt). If encrypted that makes it a lot harder for someone to analyse your traffic.

The only information they might get is — as you say — a general idea which apps might be installed on your machine. They won't necessarily know which apps you use or what are your routines when because the OCPS requests are only sent out sporadically. I agree that this is a privacy concern.

I agree. The range is from mild to terrible privacy concern - we don't exactly currently know.

I don't necessarily agree that this is a critical privacy concern — as much of this information is very easy to obtain without analyzing the OCPS traffic. They can trivially guess your profession by checking whether your computer regularly connects to servers of known applications such the Adobe suite etc. Heck, they will even know which banking software and which stock broker you use — again, simply by analyzing your IP traffic. There is not much that developer certificate validation would add here to the information that is already out there — unencrypted and in plain sight.

Can not agree here. Again you have (had) a choice. You could turn on your VPN for your important traffic or even configure a split tunnel if you are a little bit more technically savvy. That would make it impossible for anyone but the VPN provider to analyse your traffic and guess what applications you are using. Also would hide when you are asleep or awake because the traffic could be constantly generated anyway for example by background downloading stuff or automated updates. Apple bypassing VPN could also be fixed by installing the VPN on your router.

This seems straightforward to me and if it is indeed an easy update that will provide a bit more privacy, why not? At the same time, simple encryption won't work. Just encrypting the certificate ID it using a key would not hide any information — it would just remap it to a different hash. You will need to use one of the handshake-based encryption protocols with per-connection negotiated shared secret. Is it viable? No idea. Not my area of expertise.

If you use private-public key encryption you don't need any handshakes. It's simple and secure.

From what I gather, this method (Certificate Revocation Lists) was the precursor to OCSP but is not used much anymore, because it actually doesn't work that well. The problem in the nutshell: there would be a LOT of revoked certificates (there are millions of registered Apple developers after all), so maintaining a database on each active Apple device (over a billion of them) as well as synchronizing it frequently would be a major traffic generator.

Several kilobytes per day could never be major traffic generator. Apple doesn't revoke millions of certificates daily.

Here is link I found discussing this issue: https://www.fir3net.com/Security/Concepts-and-Terminology/certificate-revocation.html

I'll take a look at that.

My general point is that Apple made it a lot harder for privacy minded users to keep their privacy by using this signature checking technology. You currently have a choice of not using it at it all (e.g. by blocking the OCPS dns request) and impoving your privacy but worsening your security or using it and making your OS more secure but less private and frankly this is a choice that sould never be done. The solution is for Apple to implement more secure signature checking. I don't believe that it was done in any malicious way but for sure it was careless of them to implement it this way as it makes if very easy for a malicous party to abuse it.

 

[egalitarian]

Little Snitch won't work.

Also Apple bypasses VPNs installed in MacOS for this. You need to disable dns requests to ocsp.apple.com by adding it to /etc/hosts or blacklist it in some other way if you want to disable it.

 

[RogerWade]

Louis Rossman is the worse piece of trash on YouTube. He hates Apple and tries to make money and clicks on YouTube trashing Apple. Yuk!

You really shouldn't be allowed to comment about him. You're clearly in over your head.

"Yuk"?

 

[RogerWade]

None of my apps had any issues whatsoever during the server outages, and also I frequently am using my MBP with no internet enabled at all (WiFi off to covserve power when on the road) and everything opens and runs just fine. So obviously the idea that it checks every time is incorrect.

@leman is correct; this is just routine OCSP stuff and the usual suspects are generating FUD to get clicks.

You didn't even bother to read the article or watch the video.

They state multiple times that being off-line allows apps to open without issue. What's wrong with you that you would feel the need to make that comment?

 

[egalitarian]

Sorry, misunderstood (deleted)

 

[Piggie]

Louis Rossman is the worse piece of trash on YouTube. He hates Apple and tries to make money and clicks on YouTube trashing Apple. Yuk!

I fully appreciate whilst you may personally dislike his viewpoint towards how Apple carries on with aspects of their business, but please stop for one moment and consider how someone, and this could be yourself, may have a different view if you visited a Apple store, and they told you your whole machine was scrap, and you would lose all your data, then you took your machine to his company and they were able to do a component level board repair, which ended up with your machine back up and running and your data saved.

Yes, you may dislike his viewpoints, but he and his company have saved probably many many thousands of people with their Apple equipment.

 

[leman]

If you use private-public key encryption you don't need any handshakes. It's simple and secure.

My point is that it won't work, since it won't hide the content. You will just map one hash onto a different one — encrypting the same developer ID will always produce the same string. If you want privacy, you have to use a handshake

Several kilobytes per day could never be major traffic generator. Apple doesn't revoke millions of certificates daily.

Could be. Don't have much intuition about this. You'll have to synchronize the databases somehow and there are over a billion of Apple devices out there... no idea if it can be done in an efficient manner.

My general point is that Apple made it a lot harder for privacy minded users to keep their privacy by using this signature checking technology. You currently have a choice of not using it all (e.g. by blocking the OCPS dns request) and impoving your privacy but worsening your security or using it - making your OS more secure but less private and frankly this is a choice that sould never be done. The solution is for Apple to implement more secure signature checking. I don't believe that it was done in any malicious way but for sure it was careless of them to implement it this way as it makes if very easy for a malicous party to abuse it.

I don't disagree with this. This is certainly something that they should look into.

Also Apple bypasses VPNs installed in MacOS for this. You need to disable dns requests to ocsp.apple.com by adding it to /etc/hosts or blacklist it in some other way if you want to disable it.

Now this is something I definitely take issue with. Bypassing VPN is not ok. If I use VPN, I expect all the external traffic to go via that VPN.

 

[leman]

I fully appreciate whilst you may personally dislike his viewpoint towards how Apple carries on with aspects of their business, but please stop for one moment and consider how someone, and this could be yourself, may have a different view if you visited a Apple store, and they told you your whole machine was scrap, and you would lose all your data, then you took your machine to his company and they were able to do a component level board repair, which ended up with your machine back up and running and your data saved.

That is all good and dandy but it doesn't change the fact that he is using his Youtube channel to actively generate controversy in order to boost his business. I am fairly sure that his "component-level" repair rates are subsidized from his Youtube revenue, because otherwise it doesn't make any sense financially (unless he occupies illegal workers). It's good business, sure. And it can be even good for some customers (unless you are one of the unfortunate people whom he sets up with with some of the counterfeit low-quality parts he has admitted to have been smuggling). He is still an unsympathetic creep.

 

[TETENAL]

Just encrypting the certificate ID it using a key would not hide any information — it would just remap it to a different hash.

You can encrypt it together with some random garbage which would result in unique encrypted messages.

 

[Maconplasma]

I fully appreciate whilst you may personally dislike his viewpoint towards how Apple carries on with aspects of their business, but please stop for one moment and consider how someone, and this could be yourself, may have a different view if you visited a Apple store, and they told you your whole machine was scrap, and you would lose all your data, then you took your machine to his company and they were able to do a component level board repair, which ended up with your machine back up and running and your data saved.

Yes, you may dislike his viewpoints, but he and his company have saved probably many many thousands of people with their Apple equipment.

Way too much defending on Louis Rossman. This is worse than when people criticize Apple and Apple's watch dogs jump to their defense. He generally sends his people to MR and Reddit to drum up business for him. He's horrible and has no class. I would never recommend any trust him to fix their Apple computers when he trashes the company to make money on YouTube. Furthermore he's NOT an Apple authorized service repair tech. I doubt highly Apple would ever approve him.

 

[egalitarian]

My point is that it won't work, since it won't hide the content. You will just map one hash onto a different one — encrypting the same developer ID will always produce the same string. If you want privacy, you have to use a handshake

Not quite. It will hide the content 100%. There are simple ways of doing this without producing the same thing every time. For example you can prefix the content with a random string of set lenght (salting) and it will everytime produce different results every time. Again I repeat private-public key is simple and secure way to implement this. I simply can't understand why they didn't went this way. If you want to revoke the public key just check a given URL from time to time for updates and redownload it.

Edit: sorry didn't see the response above.

 

[leman]

You can encrypt it together with some random garbage which would result in unique encrypted messages.

Not quite. It will hide the content 100%. There are simple ways of doing this without producing the same thing every time. For example you can prefix the content with a random string of set lenght (salting) and it will everytime produce different results every time.

Simple and smart, I like it. So the device would then encrypt the payload using the public key and the server can decrypt it using the private key? I can see this work.

 

[Ocnetgeek]

Do you understand what a warrant is? Because if you do, you realize that what you just said is nonsense.

The other thing to keep in mind is that the issue is not unique to Apple Silicon Macs. It's all Macs and we are just now seeing more about it.