macOS OCSP Privacy
1dotd4 opened this issue · comments
It came to my attention this news: https://sneak.berlin/20201112/your-computer-isnt-yours/
TL;DR Apple Analytics Certificate Validation (OCSP) requests can't be turned off with firewall and are unencrypted.
Here is shown that it can't be blocked by regular firewall. https://twitter.com/patrickwardle/status/1327034191523975168
My current solution is to don't resolve the domain so OCSP will fail gracefully.
echo "0.0.0.0 ocsp.apple.com" | sudo tee -a /etc/hosts && sudo dscacheutil -flushcache;sudo killall -HUP mDNSResponder
Note: pi-hole already blocks this since 2019, macOS 10.15.
Update November 15
- clarify that those are not analytics, but in the least threat model it should be encrypted and not a simple unencrypted request;
- add note about pihole;
- awareness of Cryptohack's blog post
- awareness of fabacab's link
Do not disable apple OCSP communications, it handles certificate revocation and thus ensures that malicious apps can be revoked. If you disable OCSP, malicious apps will continue to run on your device.
(I do however agree that sending the app hash over plain HTTP is a security issue.)
So I guess, knowing what I'm installing, it's fine to block OCSP, right?
It's a trade off between privacy and security and I guess it depends on personal data hygiene. Scrupulous people verify what they are installing. A careless user, who may not now what she is doing, may not check.
Current state of privacy and security imply that either the user know what she is doing or someone else know and check for the user. I personally prefer to verify by myself thus I may not need such feature.
Has anyone tested whether blocking traffic at the pf level is still sufficient? It should be possible to just sinkhole Apple IPs if they're in your adversary model.
https://github.com/drduh/config/blob/master/scripts/pf-blocklist.sh
Jeffrey Paul's post describes that this "allows for a table that has the following headings" and, in that table, Jeffrey includes a column labelled "computer." Anyone know where we can get more clarity around that: does Jeffrey mean your individual unique physical computer, or less specific data such as computer make/model or other OS details?
The reason I ask is because it's one thing to let Apple (and any on-path attackers) know what programs are being opened "by a user with, for example, macOS 10.x.x installed," and it's quite another to let Apple (and any on-path attackers) know that I, as a specific individual with a specific piece of hardware currently in my hands have just opened a given program.
Ah, here is a more thorough breakdown of the content in the OCSP query being sent to apple. TL;DR: trustd doesn't send a unique hash of each application, but rather details about the application's developer certificate:
It is clear that the trustd service on macOS doesn’t send out a hash of the apps you launch. Instead, it just sends information about some certificate [and] developer certificates aren’t unique for each app.
If I understand that post correctly, the "computer" column I was worried about in my prior comment is much, much less of a concern because there is no device-specific information contained in the query.
but rather details about the application's developer certificate [...] no device-specific information contained in the query
Yes and no. However it's still a concerning because there is no way to get around transmitting metadata such as timestamps and IP addresses with these requests. Anyone with a privileged network position (or who e.g. has access to the receiving server) may now know stuff like:
on [date & time] [IP x.x.x.x] opened some application by [Mozilla]
on [date & time] [IP x.x.x.x] opened some application by [Signal]
on [date & time] [IP x.x.x.x] opened some application by [Apple]
on [date & time] [IP x.x.x.x] opened some application by [Adobe]
on [date & time] [IP x.x.x.x] opened some application by [Developer who is Critical of the ************]
They won't know every launch, but it can certainly be enough to paint a target on you in any place which curtails personal freedom and privacy.
It came to my attention this news: https://sneak.berlin/20201112/your-computer-isnt-yours/
TL;DR Apple Analytics that can't be turned off. https://twitter.com/patrickwardle/status/1327034191523975168
Possible fix:
echo "0.0.0.0 ocsp.apple.com" | sudo tee -a /etc/hosts && sudo dscacheutil -flushcache;sudo killall -HUP mDNSResponder
Does it break SSL or only application's developer certificate related phoning home?
@drduh will try with that! Currently checking on this too: https://support.apple.com/en-us/HT210060 .
@DarkFlame57 the problem is that the OCSP request is not encrypted in first place. See NiklasBr's comment.
Some of the comments on this issue involve blocking oscp.apple.com with a hosts file. But there is no address associated with this address, so doing so is pointless.
Try it yourself. ping oscp.apple.com or host oscp.apple.com.
You are consistently misspelling the address The address in question is ocsp.apple.com, not oscp. It's the Online Certificate Status Protocol, not the Online Status Certificate Protocol.
You are consistently misspelling the address The address in question is
ocsp.apple.com, notoscp. It's the Online Certificate Status Protocol, not the Online Status Certificate Protocol.
I apologize. I deleted my post to avoid distracting others.
@drduh will try with that! Currently checking on this too: https://support.apple.com/en-us/HT210060 .
@DarkFlame57 the problem is that the OCSP request is not encrypted in first place. See NiklasBr's comment.
Anyways, will blocking ocsp.apple.com in hosts file break SSL?
it's still a concerning because there is no way to get around transmitting metadata such as timestamps and IP addresses with these requests. Anyone with a privileged network position (or who e.g. has access to the receiving server) may now know stuff like:
on [date & time] [IP x.x.x.x] opened some application by [Mozilla]
on [date & time] [IP x.x.x.x] opened some application by [Signal]
on [date & time] [IP x.x.x.x] opened some application by [Apple]
on [date & time] [IP x.x.x.x] opened some application by [Adobe]
on [date & time] [IP x.x.x.x] opened some application by [Developer who is Critical of the ************]They won't know every launch, but it can certainly be enough to paint a target on you in any place which curtails personal freedom and privacy.
True, and if one's risk assessment concludes that Apple is an adversary, this is Very Bad. However, in that case there are bigger concerns for those users running macOS than this particular leak.
Also worth noting is that trustd, at least on macOS 10.15.7 Catalina, will respect network proxy settings entered into the Network System Preference pane, which means it's trivial to Torify or VPN-ify these OCSP queries. If someone insists on using macOS on a network where merely launching an application written by a certain developer makes them the target of that network's owners or global passive adversary, they need to be using Tor or a VPN anyway.
I don't have Big Sur available to test whether this holds on macOS 11 versions but I would be surprised if it didn't. Still, worth testing! Anyone?
Anyways, will blocking ocsp.apple.com in hosts file break SSL?
@DarkFlame57 Blocking the address of Apple's OCSP server will prevent TLS/SSL certificate status checks to that server, which means revoked certificates that instruct your computer to check with Apple to find out if they are otherwise valid will not be blocked at runtime. You will not notice "SSL is broken" but you will no longer be informed about certificates that become dangerous to use until your computer's clock reaches their expiry date. That's why folks are saying that blocking ocsp.apple.com is not a recommended or feasible long-term solution.
it's still a concerning because there is no way to get around transmitting metadata such as timestamps and IP addresses with these requests. Anyone with a privileged network position (or who e.g. has access to the receiving server) may now know stuff like:
on [date & time] [IP x.x.x.x] opened some application by [Mozilla]
on [date & time] [IP x.x.x.x] opened some application by [Signal]
on [date & time] [IP x.x.x.x] opened some application by [Apple]
on [date & time] [IP x.x.x.x] opened some application by [Adobe]
on [date & time] [IP x.x.x.x] opened some application by [Developer who is Critical of the ************]
They won't know every launch, but it can certainly be enough to paint a target on you in any place which curtails personal freedom and privacy.True, and if one's risk assessment concludes that Apple is an adversary, this is Very Bad. However, in that case there are bigger concerns for those users than this particular leak.
Also worth noting is that
trustd, at least on macOS 10.15.7 Catalina, will respect network proxy settings entered into the Network System Preference pane, which means it's trivial to Torify or VPN-ify these OCSP queries. If someone insists on using macOS on a network where merely launching an application written by a certain developer makes them the target of that network's owners or global passive adversary, they need to be using Tor or a VPN anyway.I don't have Big Sur available to test whether this holds on macOS 11 versions but I would be surprised if it didn't. Still, worth testing! Anyone?
Trustd is in the /System/Library/Frameworks/NetworkExtension.framework/info.plist on big sur so network proxy settings aren't probably respected
True, and if one's risk assessment concludes that Apple is an adversary, this is Very Bad
It's not so much about trusting Apple per se, as it is distrust of third parties who may compromise Apple. Either through the legal system (see China w.r.t. encryption keys and server access) or anyone with a privileged network position (e.g. unscrupulous ISP, or a NSA-like security agency) which may harvest and use this data to whatever means to an end they wish.
Anyways, will blocking ocsp.apple.com in hosts file break SSL?
@DarkFlame57 Blocking the address of Apple's OCSP server will prevent TLS/SSL certificate status checks to that server, which means revoked certificates that instruct your computer to check with Apple to find out if they are otherwise valid will not be blocked at runtime. You will not notice "SSL is broken" but you will no longer be informed about certificates that become dangerous to use until your computer's clock reaches their expiry date. That's why folks are saying that blocking ocsp.apple.com is not a recommended or feasible long-term solution.
Is it possible to trigger ssl revoke check manually? If true, will this at the same time send OCSP app list?
Anyways, will blocking ocsp.apple.com in hosts file break SSL?
@DarkFlame57 I checked now:
I set in Firefox's about:config the flag security.ocsp.require to true. As expected, blocking Apple's one did not influence Firefox's one. So it do not break SSL CA checks. This confirm that it blocks macOS from checking certificate revocations of programs.
Edit:
Setting this options should have hard fail Firefox's check. So @fabacab no:
Setting the security.ocsp.require preference to ‘1’ switches to hard fail and triggers a certificate validation error if an OCSP response is not received within 10 seconds.
If the OCSP server returns a status of “unknown”, Firefox will display the “SEC_ERROR_OCSP_UNKNOWN_CERT” error in a non-overrideable error message, regardless of the security.ocsp.require preference. Similarly, if the OCSP responder returns an error such as “trylater”, Firefox will display an error message.
Is it possible to trigger ssl revoke check manually? If true, will this at the same time send OCSP app list?
To reiterate, the OCSP query from trustd does not send the name of the app you're opening. It sends information identifying the certificate of the developer of the app you're opening.
You can of course make the same query manually yourself, but when you do so you need to provide the same information to Apple that is being sent when trustd makes the query for you.
That's how OCSP works. To put it another way: There is no way to avoid using OCSP if you want to use OCSP.
Has anyone tested whether blocking traffic at the pf level is still sufficient? It should be possible to just sinkhole Apple IPs if they're in your adversary model.
@drduh, tested now.
pf can block Appls's IPs, so it cannot be bypassed by Apple like other filters like LuLu which use the Apple's framework.
In this case cutting the host name is more effective because they have a good CDN, probably dynamic; incorrect pf configuration can make you be unable to open applications.
What if I'd run an ocsp service on localhost, and redirect the domain ocsp.apple.com to this local service, can ocsp be MITM-attacked like this?
Then the public service can be overridden. Revoked app certs could be encoded into some small data structure, like maybe a MMR, and the whole solution could be distributed through a github repo ☝️ 😃 which can verify each update to the repo by actually checking with the real ocsp.apple.com
Looks like something will happen, just not now.
In addition, over the the next year we will introduce several changes to our security checks:
- A new encrypted protocol for Developer ID certificate revocation checks
- Strong protections against server failure
- A new preference for users to opt out of these security protections
Looks like something will happen, just not now.
In addition, over the the next year we will introduce several changes to our security checks:
- A new encrypted protocol for Developer ID certificate revocation checks
- Strong protections against server failure
- A new preference for users to opt out of these security protections
"over the the next year". So, how to use macOS for now, apple?
@kauniss
Yes, as I've tested it before and announced here in this thread, pf is not using Apple's framework for filtering requests. So, unlike user installed packets filters, it's not influenced by NetworkExtension's ContentFilterExclusionList.
I think it's off-topic and already remarked by drduh, but at this point if there's the need to filter anything reliably it's only gonna happen with pf and /etc/hosts which operate in the kernel.
If someone could summarize these concerns and any potential workarounds in a PR, that would be very much appreciated.
I think this could fit here... Discover this with my.nextdns.io log.
— The apple clock is contacting apple server even if the '~sync date and time automatically' checkbox is not marked in Syst. Prefs.
For now, I assume we have to allow OCSP and live with the privacy implications?
(Unless someone decides to manually delete bad certificates.)
I would conclude that it depends a lot on threat model.
The considerations I would take from this thread are:
- LuLu (and other user level firewalls) does not block all Apple's services: one should learn and use pf if necessary.
- OCSP issues in untrusted networks are mitigated by encrypted connections and OCSP can be disabled if necessary.
Closing until someone can make a compelling and effective case for blocking ocsp in a PR.