Privacy concerns with Silicon Macs

[Elyus]

Interesting article. I'm exploring Pi-hole as an option since you can block ocsp.apple.com requests at the network level. It doesn't help while traveling but can add a little more privacy to your home network.

Regarding OCSP itself, I was unaware Apple did this until yesterday when my Mac stopped launching apps and started freezing while Apple's servers were struggling. I thought it was a problem with my machine until seeing the other reports and then learning more about this verification process.

To be clear, this is not occasional data, nor is it the same as analytics you can opt out of. This process seeks to verify every app launch with Apple whenever an internet connection is present. If it were designed to fail more gracefully than it did when Apple's servers went down, many would continue to never know about it, but after yesterday's issues, I think many will be disconcerted that their local machine can just stop working because of a problem on Apple's servers.

Apple should be encrypting this traffic and providing an opt-out, just like they do with website warnings, Siri audio, and other analytics data. Certainly, verifying apps is a helpful security feature, but being transparent about it and giving users control is very important, especially for a company which runs extensive ad campaigns touting privacy. In the meantime, the only option is something external like Pi-hole. As the article points out, Little Snitch has been forced to adopt DriverKit over a traditional kext, preventing it from blocking Apple traffic.

 

[leman]

Yes, snooping by third parties listening on the connection. Apple has a valid use for it. The government has a legal right to access it. But anyone else listening in should not be seeing cleartext.

Perhaps this is getting blown out of proportion. But at the same time, I think Apple needs to do better to protect the communication of this data.

It seems that Apple is simply using https://en.m.wikipedia.org/wiki/Online_Certificate_Status_Protocol to validate certificates. There is no data being sent that can be used to identify you and it is certainly not sent every single time you open an application.

OCSP is backed by an open standard and is used literally everywhere, on every OS, to check the validity of issued certificates. And yes, it included the “safe” Linux.

The article is baseless fear-mongering. I don’t question the mans credential but I do question his agenda. A security researcher that conveniently chooses to omit mentioning OCSP?

 

[LeeW]

I don't trust Apple without verification, and you shouldn't either.

Never said I trusted Apple, I trust nothing, but I understand risk.

 

[bklement]

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

Do you understand what sending this data over http means?

 

[bklement]

Yes, snooping by third parties listening on the connection. Apple has a valid use for it. The government has a legal right to access it. But anyone else listening in should not be seeing cleartext.

Perhaps this is getting blown out of proportion. But at the same time, I think Apple needs to do better to protect the communication of this data.

The government has the right on US soil/citizens. What about everyone else?

 

[leman]

Do you understand what sending this data over http means?

From what I've read, OCSP requests are sent over HTTP. This is standard practice. Using an SSL layer doesn't make much sense because then you would need to send another OCSP request to verify that layer's certificate and so on... and since the data does not contain any sensitive information, it's perfectly fine to sent it unencrypted.

 

[bobmans]

From what I've read, OCSP requests are sent over HTTP. This is standard practice. Using an SSL layer doesn't make much sense because then you would need to send another OCSP request to verify that layer's certificate and so on... and since the data does not contain any sensitive information, it's perfectly fine to sent it unencrypted.

Exactly this. There's no sensitive information (it's literally a public key, spec is here: https://tools.ietf.org/html/rfc6960#appendix-A

Also for people saying it should be https instead of http.
First of all, that's not according to OCSP spec and second: how would you validate the https certificate? Just got yourself stuck in an endless loop here.

 

[bklement]

It seems that Apple is simply using https://en.m.wikipedia.org/wiki/Online_Certificate_Status_Protocol to validate certificates. There is no data being sent that can be used to identify you and it is certainly not sent every single time you open an application.

OCSP is backed by an open standard and is used literally everywhere, on every OS, to check the validity of issued certificates. And yes, it included the “safe” Linux.

The article is baseless fear-mongering. I don’t question the mans credential but I do question his agenda. A security researcher that conveniently chooses to omit mentioning OCSP?

It's irrelevant that ocsp is an open standard. Ftp is an open standard too, yet it wouldn't be okay if someone uses it to upload your computer's content to a public site, just to cite the most extreme example.

 

[bklement]

From what I've read, OCSP requests are sent over HTTP. This is standard practice. Using an SSL layer doesn't make much sense because then you would need to send another OCSP request to verify that layer's certificate and so on... and since the data does not contain any sensitive information, it's perfectly fine to sent it unencrypted.

No, you wouldn't need another one, unless you think apple servers can be compromised, or that your request was rerouted to a malicious server, but the current implementation doesn't do this either, sending it encrypted would be an improvement anyway. It contains the hash of the program, so the program can be identified, and your ip address. And the closer to you the interception happens, the easier to tie it to you.

 

[leman]

It's irrelevant that ocsp is an open standard. Ftp is an open standard too, yet it wouldn't be okay if someone uses it to upload your computer's content to a public site, just to cite the most extreme example.

Apple is not uploading m computer contents anywhere. They are using an industry standard protocol to verify a security certificate, just like every other device does, and they do it according to industry practices.

If you are worried that a couple of checks per day can reveal what software you use, you should disconnect yourself from internet and throw away all your devices — your internet connection history is just as unencrypted is is WAY more easier to abuse. What might shock you even more: DNS resolve requests are usually not encrypted. So each time you are opening a website, it's URL is being broadcasted for the internet to snoop upon.

This is stupid fear-mongering without any reason or logic. The only thing that Apple messed up here is their OCSP server. They should fix their OS so that a server failure won't have any effect on the users.

 

[leman]

No, you wouldn't need another one, unless you think apple servers can be compromised, or that your request was rerouted to a malicious server, but the current implementation doesn't do this either, sending it encrypted would be an improvement anyway. It contains the hash of the program, so the program can be identified, and your ip address. And the closer to you the interception happens, the easier to tie it to you.

If you hard-code the public key in the OS, it might just work. I am not a security expert though, there can be an obvious exploit here. At any rate, if they can encrypt it, sure, why not. Still doesn't change the fact that this issue is massively overblown. There is a ton of unencrypted DNS and OCSP traffic flying around, but the moment Apple does it — *gasp*— those corporate bastards!

 

[leman]

P.S. Do you know what makes me most upset though? The article links to a ycombinator discussion, where you have a bunch of people loudly explaining how all this corporate cr***p is evil and people should use Linux instead, with other people chiming in that they are switching to Linux now. Funny thing though: code signing implementation for Linux (not that there are many because Linux apparently doesn’t care about security) use exactly the same mechanism for checking for certificate validity, and guess what? they also send out OCSP requests over plain http! But for some reason it's ok, because it's a "community effort". This kind of hypocrisy is literally the worst.

P.S. I suppose I spoke too harshly. Linux support for code signing seems to be practically non-existent. So I suppose they don’t have to deal with these issues be sure they just don’t.

 

[bobmans]

No, you wouldn't need another one, unless you think apple servers can be compromised, or that your request was rerouted to a malicious server, but the current implementation doesn't do this either, sending it encrypted would be an improvement anyway. It contains the hash of the program, so the program can be identified, and your ip address. And the closer to you the interception happens, the easier to tie it to you.

1. Yes, you would need another one.
For https you need to validate the SSL certificate, if the SSL certificate is issued by the same authority as the certificate being checked then you might as well not even check the certificate status. So the SSL certificate has to be issued by a 3rd party authority. You're now redirected to an OCSP from a 3rd party authority to verificate the SSL certificate. And the circle repeats. It's a dog chasing it's tail.

2. It doesn't contain the hash of the program, it contains the hash of the Developer ID to check if the developer's certificate isn't revoked. Theoretically the program can be identified if the developer only has a single app, but in a lot of cases this is not possible.

You're getting your info from the article that we're disputing instead of from actual data like the OCSP spec.


Let me tell you a little story:
Bob creates a great application and has notarizes the application. The application now contains a small note saying "Hey computer, everything ok here. This application comes from us, you can start at lowest security settings".

After a while Bob notices that he has a great install base and Bob starts getting dark thoughts. He implements and activates cryptocurrency mining into his application.

After a while some users start noticing their computer's fans start spinning and they notice the application has been compromised... 95% of users aren't tech-savy and would keep the application not knowing the aplication now contains a bitcoin miner tho.

Now how does Apple get rid of that letter attached to the application so the 95% of users who don't know their application is compromosied stop using it? They revoke the certificate on their end. How do they check the certificate status? OCSP.

If you care so much about these requests and are so scared that someone might be intercepting that traffic then you can just 0.0.0.0 ocsp.apple.com btw, but let me just tell you that this should be the least of your worries.

 

[bklement]

Apple is not uploading m computer contents anywhere. They are using an industry standard protocol to verify a security certificate, just like every other device does, and they do it according to industry practices.

If you are worried that a couple of checks per day can reveal what software you use, you should disconnect yourself from internet and throw away all your devices — your internet connection history is just as unencrypted is is WAY more easier to abuse. What might shock you even more: DNS resolve requests are usually not encrypted. So each time you are opening a website, it's URL is being broadcasted for the internet to snoop upon.

This is stupid fear-mongering without any reason or logic. The only thing that Apple messed up here is their OCSP server. They should fix their OS so that a server failure won't have any effect on the users.

But if they were doing it it would be using an open protocol. That's the point of the analogy.

DNS usually stays inside the ISP's network, limiting who can intercept it. And you have the option to use something more secure. Apple took away the choice with Big Sur(prise).

 

[Akulareb]

Another concern (including Linux too as @leman pointed out that they use OCSP) which applies to EU citizens is that, if found and confirmed to be true it would be in direct violation of GDPR, as data from European citizens is not allowed to be sent to US data centers.
So this put the matter on a serious light, regardless if it has been done in previous OSX versions or the current Big Sur.

I think it’s always easy to condone a company behaviour by the assumption that they are doing nothing wrong and under the hood they are clean as my toilet after I flush it. But you know sometimes in a rush, you might forget the skid and so they did.

This open debate, to who’s really transparent at the end of the day.

You get examples all the time, like google tracking you while in incognito, you were under the assumption that they wouldn’t systematically track you. But so they did

 

[bobmans]

Another concern (including Linux too as @leman pointed out that they use OCSP) which applies to EU citizens is that, if found and confirmed to be true it would be in direct violation of GDPR, as data from European citizens is not allowed to be sent to US data centers.
So this put the matter on a serious light, regardless if it has been done in previous OSX versions or the current Big Sur.

I think it’s always easy to condone a company behaviour by the assumption that they are doing nothing wrong and under the hood they are clean as my toilet after I flush it. But you know sometimes in a rush, you might forget the skid and so they did.

This open debate, to who’s really transparent at the end of the day.

You get examples all the time, like google tracking you while in incognito, you were under the assumption that they wouldn’t systematically track you. But so they did

And what user data is sent? Literally none.
The developer ID is sent and that's it.

 

[leman]

Another concern (including Linux too as @leman pointed out that they use OCSP) which applies to EU citizens is that, if found and confirmed to be true it would be in direct violation of GDPR, as data from European citizens is not allowed to be sent to US data centers.
So this put the matter on a serious light, regardless if it has been done in previous OSX versions or the current Big Sur.

This is really not my area of expertise, but if I understand it correctly everyone uses OSCP. It is most commonly used to validate web server certificates, but for example, Microsoft also actively uses it for software variation.

The big question is whether sending the code signature for validation qualifies as "citizen data". Frankly, I would be surprised if it did.

I think it’s always easy to condone a company behaviour by the assumption that they are doing nothing wrong and under the hood they are clean as my toilet after I flush it. But you know sometimes in a rush, you might forget the skid and so they did.

This open debate, to who’s really transparent at the end of the day.

This I hope we can all agree upon. Customers need to be able to know and to understand these things.

 

[bklement]

1. Yes, you would need another one.
For https you need to validate the SSL certificate, if the SSL certificate is issued by the same authority as the certificate being checked then you might as well not even check the certificate status. So the SSL certificate has to be issued by a 3rd party authority. You're now redirected to an OCSP from a 3rd party authority to verificate the SSL certificate. And the circle repeats. It's a dog chasing it's tail.

2. It doesn't contain the hash of the program, it contains the hash of the Developer ID to check if the developer's certificate isn't revoked. Theoretically the program can be identified if the developer only has a single app, but in a lot of cases this is not possible.

You're getting your info from the article that we're disputing instead of from actual data like the OCSP spec.


Let me tell you a little story:
Bob creates a great application and has notarizes the application. The application now contains a small note saying "Hey computer, everything ok here. This application comes from us, you can start at lowest security settings".

After a while Bob notices that he has a great install base and Bob starts getting dark thoughts. He implements and activates cryptocurrency mining into his application.

After a while some users start noticing their computer's fans start spinning and they notice the application has been compromised... 95% of users aren't tech-savy and would keep the application not knowing the aplication now contains a bitcoin miner tho.

Now how does Apple get rid of that letter attached to the application so the 95% of users who don't know their application is compromosied stop using it? They revoke the certificate on their end. How do they check the certificate status? OCSP.

If you care so much about these requests and are so scared that someone might be intercepting that traffic then you can just 0.0.0.0 ocsp.apple.com btw, but let me just tell you that this should be the least of your worries.

You sound like a typical IT manager with superficial knowledge who rejects an improvement because it would not be perfect, and ends up ordering a "solution" not benefiting the customers.

Yes, without checking the ocsp cert, it would not be perfect, but the whole pki architecture is not perfect, you eventually have to trust someone telling you the truth. Encrypting this trafic would mean that the only viable attack point would be the ocsp server itself. Using plain http means that the said attacker can redirect ocsp traffic to their server, telling you everything is ok. With http they would need to steal Apple's cert, which would be highly publicized.

Even more, the whole idea of linking encrypted transmission with server identification was a terrible mistake to begin with, delaying the prevalence of https.

Finally, you could check the ocsp server itself via http. It would only tell, that you've started up an application. That's much less information than right now.

 

[bklement]

The big question is whether sending the code signature for validation qualifies as "citizen data". Frankly, I would be surprised if it did.

If they log the ip of that request then it qualifies. However, I don't think Apple doesn't have servers inside the EU, so that part of GDPR is irrelevant here.

 

[theSeb]

Another concern (including Linux too as @leman pointed out that they use OCSP) which applies to EU citizens is that, if found and confirmed to be true it would be in direct violation of GDPR, as data from European citizens is not allowed to be sent to US data centers.
So this put the matter on a serious light, regardless if it has been done in previous OSX versions or the current Big Sur.

I think it’s always easy to condone a company behaviour by the assumption that they are doing nothing wrong and under the hood they are clean as my toilet after I flush it. But you know sometimes in a rush, you might forget the skid and so they did.

This open debate, to who’s really transparent at the end of the day.

You get examples all the time, like google tracking you while in incognito, you were under the assumption that they wouldn’t systematically track you. But so they did

There is no personally identifiable data that is sent in the OCSP request. Even dynamic IP addresses have been ruled as personal info in the EU. If Apple was storing the requests, along with IP , then we would have heard about it by now, or we will very soon. Personally I don't believe Apple would follow such an approach.

OCSP requests are sent in every operating system. This is a normal thing and has been happening for years. If there was a GDPR violation, then it would have been addressed a long time ago. OCSP was enabled by default in OS X Lion Safari to check that a website's certificate was valid. Now Apple is also using OCSP to validate all cryptopgraphic certificates on your machine, including the ones being talked about in this thread that are used for app notarization. Windows does the same thing.

The protocol definition is here

RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP

This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and...

tools.ietf.org

 

[Pralaya]

After reading all this, not knowing what kind of information are send to Apple and Little Snitch now unable to hold back communications to Apple, my tactic for the future will be the following: For Internet communications a PC with a hardened Linux, and for creative work an Apple without internet connection.
Mac OS is catching up to Win 10, a backdoor OS.
It won't get better with Mac OS in the future...

By the way, did you know that the abbreviation for OS in German is BS? In the case of Big Sur, it could be.😂😂😂

 

[leman]

After reading all this, not knowing what kind of information are send to Apple

You know what kind of information is being sent. The link to the RFC 6960 with relevant quotes has been posted directly above your post.

 

[Pralaya]

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

 

[ipponrg]

There is no personally identifiable data that is sent in the OCSP request. Even dynamic IP addresses have been ruled as personal info in the EU. If Apple was storing the requests, along with IP , then we would have heard about it by now, or we will very soon. Personally I don't believe Apple would follow such an approach.

OCSP requests are sent in every operating system. This is a normal thing and has been happening for years. If there was a GDPR violation, then it would have been addressed a long time ago. OCSP was enabled by default in OS X Lion Safari to check that a website's certificate was valid. Now Apple is also using OCSP to validate all cryptopgraphic certificates on your machine, including the ones being talked about in this thread that are used for app notarization. Windows does the same thing.

The protocol definition is here

RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP

This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and...

tools.ietf.org

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.

 

[slomojoe]

the best answer isn't technology but actual, enforceable privacy laws with teeth, hard to get upset when we are increasingly tracked in so many other ways in our lives, we are losing the technology battle with big-brother

we need laws that make misuse of private data a serious crime with serious consequences