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

201–210 of 215 posts

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

#201

Post by ruthmarx »

marksomnian wrote: post #190
ruthmarx wrote: post #177

Earlier quoted context omitted.

> so it's a moot point and needless paranoia. No it's not. You are misunderstanding my point. I'm not talking about Apple being able to patch the OS and control everything at that level - of course they can, but it seems unlikely. I'm talking about a developer framework, a high level abstraction, where the method of resolving would be more likely to be intercepted - consider for example something like that on an iPho…

Assuming arguendo that apple did want to do that kind of messing with DNS though - what's there to stop them from changing getaddrinfo() in the same way? As someone pointed out upthread, if you don't trust your OS vendor to do DNS lookups correctly, your only option is to not usre your OS vendor for DNS lookups, which is in the realm of Byzantine faults. (And further, assuming arguendo that there was DNS meddling hap…

> Assuming arguendo that apple did want to do that kind of messing with DNS though - what's there to stop them from changing getaddrinfo() in the same way?

Nothing, I already acknowledge they have the power to do rootkity things if they wanted to, but I don't consider that likely.

I do consider it likely they might do that kind of a thing at a framework level and try to push most developers to use it.

> As someone pointed out upthread, if you don't trust your OS vendor to do DNS lookups correctly, your only option is to not usre your OS vendor for DNS lookups, which is in the realm of Byzantine faults.

I responded to that as I'm responding here, by pointing out that isn't relevant to the threat model that I've described.

> now the user has one app that behaves differently to all their others, which is worse in every practical sense.

Not if that app actually gets the user to where they actually wanted to go.

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

#202

Post by adastra22 »

hmage wrote: post #191
adastra22 wrote: post #120

Earlier quoted context omitted.

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

UNIX is/whas a commercial product from AT&T. macOS is UNIX-certified. Not the same thing.

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

#203

Post by matheusmoreira »

jonhohle wrote: post #169
matheusmoreira wrote: post #136

Earlier quoted context omitted.

Linux and the popular Linux distributions are not POSIX compliant to begin with. Only GNU tries to be, and even GNU adds on a ludicrous amount of extensions because the truth is POSIX isn't good enough.

Your comment above was that it is a glibc function, which is true, but it’s there for reason. It’s also a libc, musl, uClibc, and Windows Sockets 2 function: because it’s defined in POSIX 1.1 and extended in RFC 3493. I have no opinion on whether it’s good enough (it seems like not if every platform has a connect-by-name implementation), just that calling it a glibc function overly simplifies it’s origin. It’s also f…

The point I tried to make is the getaddrinfo function is not sacred. It's not the way to do anything at all on Linux. It's just the function that glibc has, and most people use it. Whether it came from POSIX or something else seems like a minor detail to me. POSIX and glibc are not sacred either.

> Any OS will always have something beyond POSIX to differentiate it.

Linux is no exception. We should all be enjoying those exclusive features to their fullest extent. Not restricting ourselves to the lowest common denominator between them. Portability is a trap.

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

#204

Post by matheusmoreira »

yrro wrote: post #153
matheusmoreira wrote: post #110

Earlier quoted context omitted.

> getaddrinfo() is the way to resolve names on Linux Not at all. That's just a glibc function, it's got nothing to do with Linux. People just assume that glibc is how things are done in Linux user space but it doesn't have to be that way. For example, systemd came up with its own resolved mechanism which turned out to be much better than the glibc stuff. I will probably end up inventing my own at some point as well s…

You're probably aware of c-ares, if not then check it out unless you really want to write your own. (As an administrator I'm getting a bit tired of working around the differing bugs and behaviour of different resolver implementations). glibc also has an async getaddrinfo_a function for asynchronous name resolution, with completion notification.

I will look into it even if I end up writing my own. Reading source code is always helpful. Thank you.

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

#205

Post by matheusmoreira »

throw0101a wrote: post #170
matheusmoreira wrote: post #136

Earlier quoted context omitted.

Linux and the popular Linux distributions are not POSIX compliant to begin with. Only GNU tries to be, and even GNU adds on a ludicrous amount of extensions because the truth is POSIX isn't good enough.

> Linux and the popular Linux distributions are not POSIX compliant to begin with. While not (entirely) wrong, not entirely correct either. Good luck trying to compile and run any kind of software without providing getaddrinfo(), socket(), connect(), etc to userland: * https://pubs.opengroup.org/onlinepubs/9699969599/functions/g...

> Good luck trying to compile and run any kind of software without providing getaddrinfo(), socket(), connect(), etc

I'm working on a freestanding lisp language with built in Linux system call support at least in part because I want to to prove that this sort of thing is possible. No legacy interfaces will be provided and yet I have no doubt in my mind that one day it will be able to everything you mentioned and much more.

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

#206

Post by matheusmoreira »

Tepix wrote: post #149
matheusmoreira wrote: post #136

Earlier quoted context omitted.

Linux and the popular Linux distributions are not POSIX compliant to begin with. Only GNU tries to be, and even GNU adds on a ludicrous amount of extensions because the truth is POSIX isn't good enough.

Why are you nitpicking? Linux demonstrates a high degree of practical compatibility to run software written against POSIX standards.

Not nitpicking at all. I just don't like how people see Linux as a "POSIX implementation". It's much more than that.

Practical compatibility is not compliance, the manuals document many subtle differences and incompatibilities. The practicality of it mostly comes from glibc which everyone uses and which does strive to be compliant. Even then it's a hit and miss, the so called "Linuxisms" crop up in the most unexpected of places. The executable path that people write in the shebang lines of their shell scripts, for example. It's gotten to the point some BSDs have started emulating Linux system calls instead of porting software. Even Windows did this once upon a time.

My point is glibc is not even guaranteed to exist on the system. POSIX is not at all mandatory on Linux. The POSIX interfaces are just one of the ways to interface with the kernel. It's also possible to bypass all the POSIX stuff and interface with it directly. Linux is the only operating system to offer this ability via the stable kernel-userspace binary interface. It's even defined at the instruction set level which makes it programming language agnostic. On Linux you actually can trash all that POSIX stuff and reinvent it all in Rust if you want.

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

#207

Post by tpmoney »

ruthmarx wrote: post #196
tpmoney wrote: post #179

Earlier quoted context omitted.

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 a…

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

I think anyone who's run into java keystore / cert problems would beg to differ.

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

Sorry, this just makes no sense to me. You have a threat model that thinks Apple is a malicious actor and will interfere with the implementation of DNS resolution in higher level APIs because they "nanny" their users and developers. But you equally think they won't bother to do such nannying at a the lower levels because they "barely pay attention to [those legacy APIs].

But we're talking about the same apple that implemented SIP which locks out even root (and by extension sudo) from being able to make changes to "system" directories like `/bin`, and necessitated things like homebrew having to migrate their entire deployment hierarchy from `/usr/local/` to `/opt/homebrew/`. The same Apple who replaced init scripts in BSD with their own proprietary `launchd`. The same Apple who swapped `bash` for `zsh` to avoid GPL3 licensing stuff. The same Apple that last OS update changed what signals were sent when doing illegal memory access, breaking a mess of java/docker things in the process. This is the Apple you think would impose hidden DNS interception and replacement at the swift library level but wouldn't bother to either change libc too or point getaddrinfo() at their own internal interceptor.

You are of course free to have whatever threat model you like, but surely you can see why other people find it a little inconsistent?

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

#208

Post by efreak »

eptcyka wrote: post #193
egberts1 wrote: post #188

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Intrusion_detection_system

No mention of apple, xdr or nds.

https://en.wikipedia.org/wiki/Extended_detection_and_respons... Not sure what nds stands for, but I assume it's something related to network intrusion, possibly the I in NIDS (network intrusion detection system) is missing

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

#209

Post by gigatexal »

gigatexal wrote: post #157
jesse_faden wrote: post #144

Earlier quoted context omitted.

I would believe so. I have a custom DNS profile setup that redirects a few domains to a server I run. The server has custom SSL certs issued by a private CA. I the certificate installed on iOS as a trusted root certificate. Everytime I'm connected to my home WiFi I would randomly get `peer closed connection in SSL handshake (104: Connection reset by peer)`. I have absolutely no clue why it does this and this issue go…

Oh this is not good. I hope the vpn providers chime in, the MullVads and ExpressVPNs etc

Nvm. Turns out it was a bug in littlesnitch.

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

#210

Post by ruthmarx »

tpmoney wrote: post #207
ruthmarx wrote: post #196

Earlier quoted context omitted.

> 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 a…

> Java isn't known to nanny the users of apps developed in it's language. > It's never even tried IMO. I think anyone who's run into java keystore / cert problems would beg to differ. > 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 >…

> Sorry, this just makes no sense to me. You have a threat model that thinks Apple is a malicious actor and will interfere with the implementation of DNS resolution in higher level APIs because they "nanny" their users and developers. But you equally think they won't bother to do such nannying at a the lower levels because they "barely pay attention to [those legacy APIs].

I don't think this is a crazy position at all. Higher level frameworks often do things a particular way, often in a way that benefits the company pushing.

I'm pretty sure there are examples of Microsoft doing some slightly dodgy things via the .NET framework or similar but leaving the base win322 APIs untouched.

> but surely you can see why other people find it a little inconsistent?

Not really. I think people are dismissing it before really considering it because they think it's a moot point because the OS vendor could do anything, but I explained in other comments why I think that's flawed reasoning and not really relevant.

I appreciate your reply though, thank you.

Post reply on HN