Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

obdev.at

Post reply on HN
Print view View original

191–200 of 215 posts

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#191

Post by hmage »

adastra22 wrote: post #120
kelnos wrote: post #15

It's a little weird to me that getaddrinfo() is considered a "low-level legacy API". Maybe things are drastically different on macOS, but getaddrinfo() is the way to resolve names on Linux and I suspect the *BSDs. Sure, I expect most macOS apps will use something in Foundation or some other NetworkKit-type framework to do DNS queries, but it's odd to me that the code there wouldn't then call down to getaddrinfo() or…

Everything in the UNIX compatibility layer is low-level in macOS. Not necessarily "legacy" though. But this is no different than saying that, for example, calling out platform-specific native OS APIs from Java is "low-level." Which it is, from the perspective of compile-once, run-anywhere Java applets. macOS is a NeXT-compatible non-UNIX API, and you are supposed to use the macOS frameworks for everything. Calling do…

> macOS is a ... non-UNIX

Seems to be badly phrased and meant something else, since macOS is certified to be UNIX - https://www.opengroup.org/openbrand/register/ - contrary to Linux which is not UNIX-certified.

HN posted about this at least once - https://news.ycombinator.com/item?id=29984016

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#192

Post by admax88qqq »

egberts1 wrote: post #174
admax88qqq wrote: post #123

Earlier quoted context omitted.

Most isp resolvers are shit and broken

That’s why it is imperative (at least, for a homelab hobbyist) to host your own DNS servers in your own VSP.

Totally, but most IoT customers are not homelab hobbyists, so I think its defensible for IoT vendors to just hard code known good DNS in their devices instead of relying on broken ISP resolvers.

Related story, there was a period of time where my ISP's resolver that would replace hostnames with no DNS record with their own ad filled garbage page.

So you mistype google.com to foofle.com or something and instead of getting "host not found" you get... ads.

Disgusting behaviour IMO.

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#194

Post by fmajid »

TheNewsIsHere wrote: post #102
fmajid wrote: post #62

Earlier quoted context omitted.

At some point in my copious spare time, I plan on writing software to allowlist in my firewall outbound connections only to IPs resolved using my DNS servers.

You could also configure your router to intercept rogue plaintext DNS lookups on your network with responses from a resolver you trust (for example a Pihole, Cloudflare or Google Public DNS, Quad9, PCH, etc). Adding something like Pihole would give you comprehensive blocking and custom internal DNS entries too.

I already redirect DNS queries to my own DNS servers running unbound, and block UDP and TCP ports 25 from machines other than these from going out on the Internet.

This will force machines misconfigured with 8.8.8.8 as default resolver (cough, systemd) from leaking my browsing history to Google, thank you very much, but won't stop DNS-over-HTTPS like Firefox, or more insidious devices like fallback IPs hardcoded in SmartTVs and other IoT devices (they are on their own VLAN with all traffic logged, but it's not as if I have time to inspect their traffic for suspicious behavior. There are blocklists of DoH, but at that point it becomes a whack-a-mole game, and it makes more sense to block anything that is not the result of a legitimate DNS query instead.

This would only be enforced on untrusted machines like Macs, iPhones, Android devices, IoT devices and Ubuntu machines, as opposed to trustworthy OpenBSD and Alpine Linux servers.

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#195

Post by fmajid »

zbentley wrote: post #158
fmajid wrote: post #62

Earlier quoted context omitted.

At some point in my copious spare time, I plan on writing software to allowlist in my firewall outbound connections only to IPs resolved using my DNS servers.

How would that work? Do you only access a really small/known set of IPs? Or would you program the firewall to only allow connections to an arbitrary IP if it had seen a DNS query to your preferred servers go out and return that IP within a few seconds prior? In the latter case, would you have to aggressively disable local DNS caching on devices to make the behavior work (is that even possible on some devices)? How wo…

The second. The only way untrusted devices connect is to IP addresses that were resolved by my DNS servers so I know what traffic is happening on my network. My DNS servers handle their own encryption via WireGuard to bypass ISP snooping, so I don't need Mozilla's DoH and Apple's and CloudFlare's I do not trust at all.

To avoid race conditions, the trusted DNS servers would add the result IP to the firewall allowlist table before returning it to the client, so either implement it as a Caddy proxy module (I already wrote a DynDNS module for Caddy so I know how to make that work). Or alternatively use unbound's dnstap support. I just need to implement some reliable and secure protocol to send those requests from the DNS server to my OpenBSD firewall running pf.

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#196

Post by ruthmarx »

tpmoney wrote: post #179
ruthmarx wrote: post #159

Earlier quoted context omitted.

It also means if you do it the 'Apple' way they might choose to intercept or modify responses. That seem in line with Apple's practices as a company even if they are not doing it yet. I feel anything they might do like that might be less likely to extend to what the article refers to as a legacy API.

If you were writing a Java application, would you do your own DNS resolution, or would you make a new socket address object and give it a hostname and let the api resolve the hostname for you? If you don’t hand roll your own dns protocol lookups, how do you know the OS, or Java or your socket library aren’t intercepting and modifying request out from under you? Heck, even if you use getaddrinfo directly how do you kn…

> If you were writing a Java application, would you do your own DNS resolution,

Java isn't known to nanny the users of apps developed in it's language. It's never even tried IMO.

> If the threat model you’re coding for is “Apple is a hostile actor intercepting and modifying dns queries” then you really can’t trust their provided posix calls either.

Sure, but that isn't the threat model. I described the threat model above, which is closer to "I don't trust a company famous for trying to nanny not to try to nanny if using their preferred developer frameworks, while I kind of trust they won't for a legacy API they barely pay attention to".

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#197

Post by ruthmarx »

dwaite wrote: post #186
ruthmarx wrote: post #159

Earlier quoted context omitted.

It also means if you do it the 'Apple' way they might choose to intercept or modify responses. That seem in line with Apple's practices as a company even if they are not doing it yet. I feel anything they might do like that might be less likely to extend to what the article refers to as a legacy API.

I would feel far more concerned that an arbitrary application that decided to do its own DNS resolution would be doing so for nefarious reasons, or might mess up the process (such as not supporting encrypted DNS in this case). If you genuinely cannot trust the OS vendor, you don't try to tinker around in user space but you stay off their platform. Personally, this is why I don't have any machines with a Microsoft OS,…

The concern isn't that Apple controls the OS and so could do nefarious rootkit type stuff, but rather they may try to nanny through the framework they prefer and push for all apps for their platform to be developed in.

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#198

Post by dang »

leeter wrote: post #166
dwighttk wrote: post #155

>UPDATE: Spoke too soon… The problem discussed here turned out to be specific to Little Snitch 6.1 and not a general issue in macOS. It will be fixed in an update of Little Snitch later today.

Dang can we get an update to the title to reflect this?

I put "[fixed]" in there temporarily but if that's not accurate we can change it again.

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#199

Post by DrammBA »

dang wrote: post #198
leeter wrote: post #166

Earlier quoted context omitted.

Dang can we get an update to the title to reflect this?

I put "[fixed]" in there temporarily but if that's not accurate we can change it again.

I would say the new source title is more accurate

> Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

Re: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail

#200

Post by nomel »

tpush wrote: post #178
nomel wrote: post #117

Earlier quoted context omitted.

I had a great Windows firewall like this about 20 years ago. It would pop up a dialog for every network request from an app. You could block or allow based on port or destination, or "block all". It was amazing, because as you say, it made it very obvious when an app was trying shady shit. I would love to have that back, but I was never able to find a firewall so hostile to the user experience of the general populati…

Zonealarm?

Yes! That was it. I'll try it again.
Post reply on HN