profile
viewpoint
Anton Tereshchenkov atereshchenkov

atereshchenkov/docs 0

Prometheus documentation: content and static site generator

atereshchenkov/packer 0

Packer is a tool for creating identical machine images for multiple platforms from a single source configuration.

atereshchenkov/prometheus 0

The Prometheus monitoring system and time series database.

atereshchenkov/terraform 0

Terraform is a tool for building, changing, and combining infrastructure safely and efficiently.

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS OCSP Privacy

@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.

1dotd4

comment created time in 6 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS OCSP Privacy

Might be of interest: https://mullvad.net/en/blog/2020/11/16/big-no-big-sur-mullvad-disallows-apple-apps-bypass-firewall/

1dotd4

comment created time in 8 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

DNS over HTTPS

Alose note, there is a bug (or a feature ?! 😒) that disable the certificate when using a firewall like Little Snitch.

paulmillr

comment created time in 8 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS OCSP Privacy

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?

1dotd4

comment created time in 9 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS OCSP Privacy

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
1dotd4

comment created time in 9 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS OCSP Privacy

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

1dotd4

comment created time in 9 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS OCSP Privacy

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 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.

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS Big Sur (>=11.0.0) Privacy

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.

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS Big Sur (>=11.0.0) Privacy

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.

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS Big Sur (>=11.0.0) Privacy

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?

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS Big Sur (>=11.0.0) Privacy

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.

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS Big Sur (>=11.0.0) Privacy

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 Dictatorship] 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

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS Big Sur (>=11.0.0) Privacy

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.

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS Big Sur (>=11.0.0) Privacy

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 Dictatorship]

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?

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS Big Sur (>=11.0.0) Privacy

@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?

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS Big Sur (>=11.0.0) Privacy

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. I apologize. I deleted my post to avoid distracting others.

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS Big Sur (>=11.0.0) Privacy

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.

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS Big Sur (>=11.0.0) Privacy

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.

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

macOS Big Sur (>=11.0.0) Privacy

@drduh will try with that! Currently checking on this too: https://support.apple.com/en-us/HT210060 .

@DarkFlame57 the problem is that the OSCP request is not encrypted in first place. See NiklasBr's comment.

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

Macos Big Sur (>=11.0.0) 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?

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

Macos Big Sur (>=11.0.0) Privacy

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 Dictatorship]

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.

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

Macos Big Sur (>=11.0.0) Privacy

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.

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

Macos Big Sur (>=11.0.0) Privacy

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.

1dotd4

comment created time in 10 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

Macos Big Sur (>=11.0.0) Privacy

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

1dotd4

comment created time in 12 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

Macos Big Sur (>=11.0.0) Privacy

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.

1dotd4

comment created time in 12 days

issue commentdrduh/macOS-Security-and-Privacy-Guide

Macos Big Sur (>=11.0.0) Privacy

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.

1dotd4

comment created time in 12 days

issue openeddrduh/macOS-Security-and-Privacy-Guide

Macos Big Sur (>=11.0.0) 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

created time in 12 days

push eventdrduh/macOS-Security-and-Privacy-Guide

Hannes Braun

commit sha 4c11e87e0e78adc0171a8ecbdd3c04e277f8cabe

Fix PGP/GPG link in table of contents

view details

drduh

commit sha e254ffeac89a66b04710258a95ff94a8472acf4f

Merge pull request #377 from hannesbraun/fix-pgpgpg-link Fix PGP/GPG link in table of contents

view details

push time in 14 days

PR merged drduh/macOS-Security-and-Privacy-Guide

Fix PGP/GPG link in table of contents

The link for "PGP/GPG" in the table of contents does not work currently. This should fix it.

+1 -1

0 comment

1 changed file

hannesbraun

pr closed time in 14 days

issue openeddrduh/macOS-Security-and-Privacy-Guide

DNS over HTTPS

Big Sur allows to use encrypted DNS. This is very useful for privacy. See: https://paulmillr.com/posts/encrypted-dns/

Perhaps it would make sense to include some eDNS advice in the guide.

created time in a month

more