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 goes away when I'm connected on mobile data.
Now I'm guessing that it is bypassing the DNS profile and resolving it using my ISPs DNS or some other way.
It won't, it was specifically a bug in Little Snitch (which doesn't currently run on iOS, I believe.)
"The problem discussed here turned out to be specific to Little Snitch 6.1 and not a general issue in macOS. It has already been fixed in Little Snitch 6.1.1."
Not really.
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 the like to do the dirty work. I guess GAI is blocking, so presumably there's some other low-level non-blocking call?
Correct, CFNetwork is open source so you can check implementation but last I remember it used some variant like `getaddrinfo_async`. But Apple really doesn't want you (the end-user) to use getaddrinfo (or the async variant CF exposes) to resolve an IP and then directly connect() via that ip, everything is geared towards connect-by-hostname since then Apple's can internally handle the implementation of happy-eyeballs.
Edit: You can read https://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf for their thoughts on why they don't like the getaddrinfo() model [there are speaker notes at the bottom of each slide]
https://developer.apple.com/library/archive/documentation/Ne...
Applications should not use getaddrinfo(). Because for the connect by name, the OS or app SDK can parallelize the entire multi-step lookup and connection process, not just step by step:
“Now, I’m not saying that all implementations of these APIs [Java, Apple Foundation, etc., doing connect by name] necessarily do the right thing today, but if applications are using these APIs, then the implementations can be improved over time.”
“The difference with getaddrinfo() and similar APIs is that they fundamentally can’t be improved over time. The API definition is that they return you a full list of addresses, so they have to wait until they have that full list to give you. There’s no way getaddrinfo can return you a partial list and then later give you some more.”
The deck's position on implementation of happy-eyeballs (which could sound dismissive here but is treated as "you had one job" important by the deck), is finding a way to avoid waiting 5 seconds for either side of IPv4 vs. IPv5 stack to timeout before finishing connection setup and serving the user a web page.
I don't think it is considered legacy. The blog post gets that wrong.
(Whether it's "low-level" or not just depends on your perspective.)
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 since I'm working on freestanding software targeting Linux.
So OP might not be completely accurate, but getaddrinfo is _the_ way to resolve names if you are writing portable POSIX and/or UNIX code.
(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.
At least on OpenBSD, all classical/standard DNS functions (getaddrinfo/gethostbyname/...) are wrappers around OpenBSD's libc asr implementation, written by Eric Faurot.
I'm not sure if this is the case in this case, but it might be worth noting that some system functions with the same name have drastically different internal/implementation differences between Linux/*BSD/MacOS. With there being differences between the *BSDs too.
So on some systems one function call is "the way", because its been maintained over the years, but then on another it might actually be old and not useful.
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 down to BSD or even mach is definitely not what Apple wants you to do.
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
Isn't the Mach kernel based on BSD?
How much of getaddrinfo is in the kernel, how much of it is pure "libc"?
See WWDC 2018's "Introducing Network.framework, A modern alternative to sockets".
NeXTSTEP might have been a UNIX, and macOS derives from it, but the whole UNIX story has always been to bring UNIX software into the platform, not to make it easier to move elsewhere.
EDIT: maybe not anymore, Sequoia isn't listed yet, https://www.opengroup.org/openbrand/register/xy.htm
* Host file
* Configured DNS server
* App-specific DNS server if it exists
So, usually devs should use the Java or Apple or whatever higher level OS API gets you connected the fastest, and that API is free to implement the connection however most quickly gets to the point of able to return data to the user (app or end user).
The API that returns a list of addresses is stuck doing that, instead of being able to parallize the entire "get connected" data flow.
I can’t blame them but I personally would still have my apps use them, even knowingly that it would be made off-limit to iOS/iPadOS apps … soon.
/s
New title from source: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
> After further investigation, we found that this bug has already existed at least since macOS 14.5 Sonoma (maybe even earlier, but we currently don’t have access to an older 14.x system for testing).
You can do a fresh install of an older macOS version whenever you like (you need to enable that option in the rescue system tho).
You can also run older macOS in a VM (the hypervisor framework keeps getting new features that make guest macOS more fully supported).
Name an OS (ok maybe NixOS) that allows you to do clean downgrades out of the box. Also wonder what's gonna happen to your data in e.g. Postgres if you blindly downgrade.
I also wish people would post the FB numbers and the details of their report when they say they've reported things like this.
Well, seems this is the LS blog, so only confusion is why this is portrayed as a macOS bug? I'm not saying it's wrong, it's their domain not mine after all, it just doesn't seem to be justified in TFA?
Besides, apps can always make direct lookups to a resolver of their choice, bypassing any resolver hints of the operating system.
Maybe part of this old bug (that I thought was fixed)
I use a stub listener on localhost:53 for local requests and then forward them via UDP QUIC (TLS 0-RTT) requests to Cloudflare (1.1.1.1) with caching for most requests. Fast and reasonably secure.
Isn't this an inherent risk when attempting to do network stuff in userspace? You're at a very high level so hoping that lower level things comply seems risky if DNS encryption is critical to your use case.
this is not "bypass encryption" this is "uses a range of ABI/API bindings in code which don't expose well into a single control point"
As a long-time DNS security researcher, the ultimate and final end means would be to mirror the root servers, but I assert, for now, popping in your own `resolv.conf` should suffice, … again, for now.
Browsers such as Firefox have offered this directly for a while. Of course, that only covers DNS lookups made from the web browser, but it doesn't rely on OS-level hooks that (at least in Apple's case) can break.
I also still haven't figured out how to get SSID-based switching to work, does it even?
TBH I’m too lazy to dig in and find out. Has anybody else run into this issue?
If disabling the firewall (for testing) solves this problem, this is likely your issue.
In other words, it would be unencrypted to the pihole but encrypted when going out to the internet.
Does Little Snitch do things differently?
man 5 resolver
FYI, it looks like Firefox fixed this.
The reasons applications do this is to prevent users from blocking telemetry etc. It's my computer, I should have final say on what goes out.
I remember 20+ years ago when one of the most commonly seen attacks was malware configuring a proxy server in Internet Explorer which by design overrode the operating system's configuration.
What a lot of software does today by ignoring the operating system in lieu of their own shit is just like the above. If your program doesn't (or can't) respect the operating system, your shit is malware and you should reconsider who you write code for.
> @dang is a no-op. The only way to get reliable message delivery is to email hn@ycombinator.com
> Going to the firewall settings screen, there can be no way to toggle access for the browser.
If you want to stay at a lower level the recommendation these days is to use Network.framework. If you want something higher level then use CFNetwork (probably through the classes exported by Foundation like NSURLSession).
It is not best practice to use `getaddrinfo` for DNS resolution, for sure. But it is best practice to use it before connecting to an IP address directly because that address may need to be translated.
For instance, their recent Spatial (stereographic) Video features uses a format that has basically zero current support outside of Apple—which is in fact just standard MV-HEVC [0] (with some extra optional metadata [1]), which is just the H.265 evolution of the standard H.264 MVC that 3D Blu-rays have used for a long time. (AFAIK no 4K 3D Blu-rays have been released, presumably due to space constraints, explaining the lack of usage of MV-HEVC outside Apple).
In piracy world, most re-encoded 3D movies just use objectively inferior composited 2D formats like half-side-by-side or over/under. And without diving in you’d just assume Apple was using some bespoke format to be evil, when in fact they are popularizing what should be the canonical, standardized format for 3D video.
[0] http://hevc.info/mvhevc [1] https://developer.apple.com/av-foundation/HEVC-Stereo-Video-...
I agree with GP that this is generally not a great trend.
As anyone that has painfully tried to write POSIX portable code across big iron UNIX is aware of.
getaddrinfo() is part of POSIX, so it would be necessary to expose it:
* https://pubs.opengroup.org/onlinepubs/9699969599/functions/g... (2004)
* https://pubs.opengroup.org/onlinepubs/9699919799/functions/g... (2017)
* https://pubs.opengroup.org/onlinepubs/9799919799/functions/g... (2024)
Where does it say DNS encryption is required?
Here’s the breakdown:
• Mach OS refers to the Mach microkernel, which primarily focuses on low-level system functions such as task scheduling and memory management. It is not a full-fledged operating system, and thus, libraries like libcompat, which are higher-level UNIX compatibility libraries, would not be integrated directly into the Mach kernel itself. • Mac OS (particularly macOS, formerly OS X) is a complete operating system that includes the Mach microkernel, the BSD layer, and various other components. macOS has a strong Unix heritage, and libcompat is part of the broader Unix-like environment included in macOS to support legacy Unix APIs and applications.
Thus, libcompat was integrated into macOS (or its predecessor, NeXTSTEP) as part of its Unix compatibility layer, rather than into the Mach kernel directly
If you consider the source of income of what's most likely a considerable portion of the HN community, I think this makes more sense. Apple is one of the only companies interested in preventing tracking, and it hurts, in the billions sort of way [1][2].
[1] https://www.forbes.com/sites/kateoflahertyuk/2022/10/08/appl...
[2] https://www.forbes.com/sites/timbajarin/2022/07/26/apples-do...
One malicious overrides universal network communication while the other just conducts DNS queries limited to a single application domain.
You are describing malware. Benign malware is still malicious, even if it does no active harm. Intent (of how the software operates) matters.
Queries that will ignore configurations you set.
If I see something ignoring/evading my configured DNS server, that shit is fucking malware.
It worked before I upgraded to Sequoia. But I don't know enough to point fingers. Just mentioning that turning off the firewall long enough for Firefox to update fixes the problem.
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 population.
Blocking socket APIs would break every app that supports other protocols. Goodbye file transfer apps, VPN apps, file sync apps, database tools, SSH clients, remote desktop clients, audio and video conferencing apps, etc.
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.
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...
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.
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 false to say only GNU tries to be POSIX compliant. There are 8 commercial UNIXes that meet some POSIX standard, another 8 that are discontinued (at least one of which was a Linux distro), and dozens that are mostly compatible. POSIX doesn’t care if that compatibility comes from the kernel or user space libraries.
POSIX isn’t good enough at what? Maybe you don’t understand what it’s goal is/was. POSIX exists for portability. It’s a minimal set of functions developers can target to get things done on any UNIX. Any OS will always have something beyond POSIX to differentiate it.
> 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.
We use a .dev domain as a localhost alias, and turns out his ISP’s DNS wouldn’t resolve 127.0.0.1 (or whatever it is) for the .dev domain. Changing his resolver at the network level to 1.1.1.1 fixed it.
I imagine there are lots of difficult support tickets for app devs, and at a certain point they just hardcode the DNS to remove one variable from the equation when debugging bug reports.
Only problem was that nobody in my family out of state could see it. It took awhile to realize realize that we never bought that domain. Our local ISP just added it to their DNS records, and since we all hooked into them we thought we were live across the 'net.
I remember one of the first times I used the Internet and opened my local radio station’s website from several states away. It was incredible to me that it worked and I also wondered why anyone across the country would care. The early internet was amazing.
I agree that it’s usually the right behavior.
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.
The corporations making proprietary software are not the only ones who have that attitude. I've resolved to make all my free software Linux-exclusive so that I can use Linux to the fullest. The Linux kernel is packed full of exclusive non-portable features that very few people take advantage of because they're obsessed with portability, POSIX compliance or whatever. I think that's a waste.
Portable software is usually sucky lowest common denominator software. We should not limit ourselves to whatever glibc offers.
https://developer.apple.com/documentation/network/nwendpoint...
Which honestly sounds like a good reason to make sure you do do it yourself.
Because not sure if you know this but the entire software industry is built on high level libraries on top of largely portable code. For example this Swift library wraps c-ares a portable API.
One can make a good technical argument based on the merit of the portable API without immediately resorting to the EEE argument.
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.
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 would encrypted DNS fit into this scheme?
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.
Sometimes I wish it would allow wildcards, but honestly that's probably just another way for users to shoot themselves in the foot (e.g. by adding '*').
pfSense for example uses unbound, and while it doesn't have a switch for disabling rebind protection, it does allow injecting arbitrary unbound config, which can disable rebind protection for any depth of a DNS zone or IP space. E.g.:
server:
private-address: 192.168.0.1/24
private-domain: plex.directIf 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, and why I don't have a Playstation.
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 iPhone with the justification being safety or 'for the children' or whatever.
That doesn't seem unlikely or improbably at all, and certainly not moot or any kind of paranoia.
(And further, assuming arguendo that there was DNS meddling happening but somehow getaddrinfo() was exempt - now the user has one app that behaves differently to all their others, which is worse in every practical sense.)
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.
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".
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?
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.