Little Snitch / Lulu seem to disable DNS over HTTPS / TLS
paulmillr opened this issue · 27 comments
Seems like a bug
Seems like a bug
Hey, is this why every time I try to enable it, it ignores the command? That makes sense! Been trying to figure this out for weeks! 😱
Same for me. Anyone got a workaround?
Hi guys! I've run into the same problem.
How do I disable Lulu so that DoH works? Do I need to remove the app completely?
There is a workaround for having a DNS-Over-HTTPS implementation on a Mac device whilst at the same time running LuLu or Little Snitch which I found, this is using a project called DNSCrypt, which maintains a proxy server which can be run locally to forward the traffic to DNS-Over-HTTPS providers.
Link to project: https://github.com/DNSCrypt/dnscrypt-proxy
Unfortunately however, it looks like some of the more fancy features like domain-based rules (at least on Little Snitch) seem to rely on being able to intercept and see these DNS requests as they happen, and when such a proxy is used, all of these rules very quickly fail to match, giving you a flurry of requests to allow connections to seemingly random IP's.
So overall, so far I haven't had the best experience with running DNS-Over-HTTPS systemwide on a Mac, the best solution I found is to continue running it on the network the Mac connects to, i.e. on a router or similar.
Looking forward to seeing some compatibility between Little Snitch / LuLu and these native DNS profiles, wether by them doing something, or Apple patching this bug which prevents them from being activated when these other products are active at the same time.
@marcoslater does it mean that even after Apple fixes the bug and we will be able to run native encrypted DNS profile together with Little Snitch the domain-based filters won't work in Little Snitch and more importantly, we won't be able to see to which domain the app is making a request in the alert pop-up. I mean that situation won't change either it's a native encrypted DNS profile or third-party DNSCrypt proxy?
@georgysavva Not necessarily. My above workaround has that effect, but it may not mean that the native way does.
It all depends at what point the system encrypts the queries, and if that is before or after Little Snitch/LuLu intercept them to figure out hostname/ip's. Honestly, how these products do it and at what stage is a bit of a mystery to me, I haven't found the time to dig into that subject and see the inner workings.
But anyhow, no one can really check or test until the MacOS bug preventing it from working is resolved, I guess we'll see once that happens. 😄
@marcoslater I see, thanks for explaining this to me. Let's wait for the apple fix then!
Is that bug been reported to Apple?
Is that bug been reported to Apple?
Yes, I've done that.
After lots of research and tests, I finally choose a simple, reliable and effective solution nextdns (link with my affiliate), it handles all, web interface to manage everything, famous block lists, White/Black user list, logs (optional), all OS, via curl... free 300.000 requests/month, can be set on router or per device.
Works perfectly well, easy to white list, just check your log on the site.
The log can also indicates which device has issue a request.
I have tried a lot but the problem is always when you need something that's blocked, here it takes one copy paste from the log into the whitelist.
A small tip, check the domain which are very often requested on the logs, for example my TV check netflix every minute!
I don't even use netflix! Same for phone, computer...
Block them in the router or private/etc/host file.
In host file use 0 and ::1 to block IP4 and 6!!! too
Here is a huge list of misc. DNS providers
https://0000
Sorry, was not my intention, just tried to provide a solution which solves all the problem of other tools. Sorry again.
@paulmillr Since it's not a bug in .mobileconfig file I ask this issue be closed.
We cannot fix it only apple can so I vote to close it but it's up to you.
Anyone tried the Monterey betas in regard to this?
As a follow up, the Monterey release includes the iCloud Private Relay beta, which by default encrypts all DNS requests out* and sends them to Apple to be bounced off to another provider, as with the rest of the "Private Relay" traffic, so that is a possible workaround for having Little Snitch or LuLu enabled and have DNS requests effectively protected at the same time, although it's once again not a direct solution to the issue at hand.
(*Based on my testing so far, please do advise if there's some edge cases.)
@marcoslater unfortunately iCloud Private Relay only works for requests made from Safari (as of today anyway - 28th Jan 2022).
So whilst it's a cool product for stopping websites building profiles on your activity, it's not a system-wide alternative.
This issue with Little Snitch etc. currently has no nice workaround. 😢
It is my understanding (and apparently @marcoslater has verified it) that all DNS requests systemwide go through iCloud Private Relay, as well as all unencrypted traffic.
It is HTTPS traffic that is only routed through Private Relay on an app-by-app basis. Apps other than Safari need to opt in. In the case of Mail, traffic gets routed through Private Relay if the user enables Mail Privacy Protection.
As far as I can still see, all DNS requests are routed via Private Relay and as such effectively providing similar security to DNS over HTTPS/TLS.
I was under the impression that anything other than DNS would be routed over it if it was either Mail or Safari, do you have a source on HTTP requests outside of those being sent through the relay? Interesting!
It's worth noting that Private Relay is quite sporadic on the MacOS Beta, sometimes Safari goes through it when the rest of the system doesn't, and sometimes it's the opposite in my experience, so mileage may vary.
Your DNS records are encrypted, so neither party can see the address of the website you’re trying to visit.
It’s built directly into the networking framework of iOS, iPadOS, and macOS, and protects traffic most susceptible to tracking: web browsing and any connections that are unencrypted. As a result, Private Relay protects all web browsing in Safari and unencrypted activity in apps, adding both privacy and security benefits.
During the .0 betas, using a .mobileconfig for encrypted DNS disabled Private Relay entirely. I reported this to Apple, and you can now use both, with precedence being given to .mobileconfig.
I have since stopped using .mobileconfig, because it was too hard to make it work reliably with captive portals. Private Relay encrypts DNS requests with a simple toggle, provides greater privacy through ODoH, and “just works” with captive portals. The only caveat would be regions where Private Relay is banned; but I keep the 1.1.1.1 app in my App Library for when I visit my brother in Colombia.
To protect the privacy of DNS name resolution for all queries sent by the device and prevent such tracking, Private Relay uses Oblivious DNS over HTTPS (ODoH).
If a user has configured custom-encrypted DNS settings using a profile or an app, the DNS server specified will be used instead of ODoH. Safari connections and all unencrypted HTTP connections will also resolve names using the specified DNS server prior to routing through Private Relay.
That document is pretty detailed, and makes for an interesting read.
As for Mail, I know it only uses Private Relay if you’ve enabled Privacy Protection, because as I mentioned above, during the .0 betas, .mobileconfig would interfere with Private Relay. If I enabled Privacy Protection, Mail would complain that it was unable to load content privately (which was due to Private Relay being blocked by .mobileconfig). If I disabled Privacy Protection, no errors occurred (proving that Private Relay was not being used at all).
Of course, with Private Relay still being in beta, it can be finicky, as you’ve noticed, and anything is subject to change at any time without warning.
@zecanard except that to use icloud relay, you need an apple account, which could easily be logging ALL your accesses.
Also it's not "more private", because compromising two huge corporations is easy. You cannot select entry point and exit point.
With encrypted dns, however, you can set up your own servers, or use anything anonymously.
It's not only a Little Snitch problem. If I understand it correctly than you can only have one filter for the internet traffic to be enabled. My setup is Vallum firewall and AdGuard private DNS set by a profile but as soon as I enable one of then, the other one becomes disabled. And yes, macOS Ventura 13.4.1 on an M1 still has this bug.
@georgysavva you've said that you has reported this bug to the Apple itself. How? Any issue number? Have they responded?
Yes, I've done that.
@zecanard except that to use icloud relay, you need an apple account, which could easily be logging ALL your accesses.
Also it's not "more private", because compromising two huge corporations is easy. You cannot select entry point and exit point.
With encrypted dns, however, you can set up your own servers, or use anything anonymously.
for me it's a false arguments, since if you use iPhone / Mac / iPad you have an apple account, it's mandatory to use Apple Store.
@BirdInFire
for me it's a false arguments, since if you use iPhone / Mac / iPad you have an apple account, it's mandatory to use Apple Store.
- It is not mandatory for macs: xcode cli tools are downloaded outside of app store
- Soon, after apple implements EU rule that mandates 3rd-party app stores, there would be less need in apple app store
- You can use apple id just to download apps. This would limit amount of information Apple receives. Nothing bad in this idea.
@BirdInFire
for me it's a false arguments, since if you use iPhone / Mac / iPad you have an apple account, it's mandatory to use Apple Store.
- It is not mandatory for macs: xcode cli tools are downloaded outside of app store
- Soon, after apple implements EU rule that mandates 3rd-party app stores, there would be less need in apple app store
- You can use apple id just to download apps. This would limit amount of information Apple receives. Nothing bad in this idea.
- Like hell you will find someone crazy enough to buy a Mac and not using appstore or any other Mac related feature.
- It's not completely true, since many app (like with fdroid on android) will never use this store, and knowing apple I'm pretty sure that the third party store will need to change a settings ... that will require an apple account).
- Technically if you enable the free (advanced protection) that enable E2EE on nearly everything (but iCloud mail, calendar & contact), your covered (also relay use a 2 hop) to prevent apple or their partner to even know who do what so technically speaking it's more private than dns (who have your ip AND your request)
I respect your work but in this case I do really think you have misunderstood how work this feature and I don't think saying to people to avoid it because of that is a good idea but on the other end I completely understand that some people prefer to only protect their dns.
The final fact is that these 2 protection (the one you help to give) and apple relay do not work together it's the first or the second but not both.
I understand that iCloud Relay's 2-hop is better than 1-hop, which encrypted-dns provides. However, self-hosting, if you have time and resources for this, is always a better option than icloud relay or public encrypted-dns services. DNS over TOR is even cooler, but complicated.
Today apple may be pro-privacy, but tomorrow they can easily change their stance, under pressure, or else. And for tomorrow we need to be prepared. To be left without an apple account, etc. Even if it's "unconvenient" for you.
With regards to E2EE iCloud: I have investigated this feature as soon as it came out, and it is unclear. There seem to be no re-encryption happening, which means we still need to trust Apple their key enclave would properly erase the data encryption key. If you've stored your data in Apple before e2ee, chances are, Apple and related entities have already logged your key. Which means even if it's not stored today, it's entirely possible your data is still decryptable. Even if the logging was done by error.
I would prefer to not trust Apple on that and use my own key instead.
There is no silver bullet. Privacy is hard.
I understand that iCloud Relay's 2-hop is better than 1-hop, which encrypted-dns provides. However, self-hosting, if you have time and resources for this, is always a better option than icloud relay or public encrypted-dns services. DNS over TOR is even cooler, but complicated.
Today apple may be pro-privacy, but tomorrow they can easily change their stance, under pressure, or else. And for tomorrow we need to be prepared. To be left without an apple account, etc. Even if it's "unconvenient" for you.
With regards to E2EE iCloud: I have investigated this feature as soon as it came out, and it is unclear. There seem to be no re-encryption happening, which means we still need to trust Apple their key enclave would properly erase the data encryption key. If you've stored your data in Apple before e2ee, chances are, Apple and related entities have already logged your key. Which means even if it's not stored today, it's entirely possible your data is still decryptable. Even if the logging was done by error.
I would prefer to not trust Apple on that and use my own key instead.
There is no silver bullet. Privacy is hard.
Problem all your solution need technical knowledge and will fail if your internet / electricity fail.
For the no account problem the answer is easy (do backup), because sync is not a backup.
But again I understand your stance and if you have the knowledge the hardware (for network protection) the double ISP, and electricity backup of course it's more private (I will not say more secure due to some feature (passkey, yubikey enabled 2FA, the mandatory 2FA on new account, the mandatory 2FA for old account for some new feature, that is not available on many self hosted services).
For E2EE, all you need to do it's to remove the data (if you had), enable the E2EE, and resend them they never had your E2EE key since it's deviated for you first device password (that they don't have too) and was already used for the keychain or health data.
I do not actually know if there is encryption on device and send back or so, but (in my case) I only sended my data after E2EE activation so they never had version of my data in clear.
For me here you have 2 tool for 2 kind of people, the first tool is the self hosted yadayadayada, who need a big knowledge in network and security to not have a script kiddy in your server in no time.
The second tool is those offered by apple for people who do not want to deal with it themselves (or cannot due to a lack of knowledge).
But again relay have some handy feature that the dns protection do not provide, it's the fact it's intercept any unencrypted connection (dns, http etc) from app or system and trow It too the relay, so it technically protect you from network snooping.
But at the end of the day it depend on the trust you put on Apple who do not want to mess with their brand (because if tomorrow we know they had access to data they will crash in wall street)
Or if you prefer to trust another DNS provider.
So technically both of us are right, since our trust is put on people we Trust and not the other.
both of us are right, since our trust is put on people we Trust and not the other
yep