Timeline for What is the best way to block ocsp.apple.com on mac?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 25, 2023 at 14:38 | comment | added | NBTX |
@archieoi The easiest way is probably to edit the hosts file (sudo nano /etc/hosts) and delete the line. Then, save the file and exit. You can run sudo killall -HUP mDNSResponder to ensure the changes are applied immediately.
|
|
| Jul 24, 2023 at 5:47 | comment | added | archieoi | How do you undo this? | |
| Nov 17, 2020 at 22:18 | comment | added | Allan | @SamJakob - check out pfSense... commercial grade for free and on hardware that most people would toss out as rubbish! On r/pfSense users literally take it as a challenge to see how cheap they can build a router. Saw one a while back on an R-Pi. | |
| Nov 17, 2020 at 21:54 | comment | added | NBTX | @Allan For sure, while I don't necessarily think they will, you're totally right that they can break this. In which case doing this at the router-level like your answer suggests would, of course, be an ideal "Apple-proof" solution. That said something like a piHole may also be necessary as not everyone has commercial grade routers - or even access to the router they use, e.g. college networks. | |
| Nov 17, 2020 at 21:41 | comment | added | Allan | @Sam I totally agree that it's a worthwhile fix for the present (thus my +1 on this answer). I'm merely pointing out that Apple can break this given that they already "broke" LittleSnitch's ability to block traffic coming out of your own computer. | |
| Nov 17, 2020 at 21:35 | comment | added | NBTX | @Allan You do make a good point and naturally Apple sees their monitoring tools as a security protection and therefore bypassing them could be considered a vulnerability particularly with a potentially untrustworthy VPN, however I believe it is unlikely that the hosts file would be ignored as unlike programs or VPNs blocking checks to Apple's servers it is blatantly obvious if someone is abusing the hosts file because a user can trivially see both that it's been modified and how it's been modified. Either way it's a useful workaround for the present. | |
| Nov 17, 2020 at 21:28 | comment | added | Allan |
@Sam starting in Big Sur, Apple is starting to make it impossible to disable their monitoring tools. The new API prevents apps like LittleSnitch from blocking the traffic and it will even "go around" a VPN if you have one. It's not a major leap to ignore the hosts file and do DoH resolution directly from trustd to prevent users from circumventing things.
|
|
| Nov 17, 2020 at 21:11 | comment | added | NBTX | @Allan If DNS over HTTPS is implemented at the OS-level, changes to the hosts file should still apply AFAIK. It's my understanding that the only reason it doesn't at the moment is because DoH is usually implemented by browser vendors such as Firefox who avoid using any OS-level DNS resolution, hence ignoring the hosts file. | |
| Nov 14, 2020 at 14:34 | comment | added | nohillside♦ |
@DisplayName The $ is just the prompt, the command part starts with sudo
|
|
| Nov 14, 2020 at 14:34 | history | edited | nohillside♦ | CC BY-SA 4.0 |
deleted 4 characters in body
|
| Nov 14, 2020 at 7:45 | vote | accept | Display Name | ||
| Nov 14, 2020 at 5:51 | comment | added | Allan | I haven't tested this to confirm, but if Apple decides to use DNS over HTTPS, this won't work at all | |
| Nov 14, 2020 at 1:42 | comment | added | Display Name |
I'm getting -bash: $: command not found. Is there a way I can fix this?
|
|
| Nov 14, 2020 at 0:52 | review | First posts | |||
| Nov 14, 2020 at 1:49 | |||||
| Nov 14, 2020 at 0:50 | history | answered | NBTX | CC BY-SA 4.0 |