181–190 of 215 posts
I was confused at the Little Snitch mention, and then reading further it just seems like a LS bug, that it only works in certain cases. 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?
If the OS allows the registration of a DNS proxy, and some calls bypass the proxy, it's squarely an OS bug.
Sequoia also breaks an application's ability to use DNS (or presumably anything UDP-based) if the macOS firewall is enabled, and an app is listed as "Block incoming connections". https://waclaw.blog/macos-firewall-blocking-web-browsing-aft...
Before Sequoia when using OpenDNS for VPN, could be on VPN and iMessage and other apps still work, but since Sequoia, when on VPN iMessage (text messages) etc no longer work. Once I disconnect to VPN all goes through. Is this related at all? Do have macOS firewall enabled. But not block all incoming connections.
>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?
New title from source: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
Earlier quoted context omitted.
Good thing you can still see the domain over the network if you control the network.
You can’t control anything if they do DNS over HTTPS to a hardcoded IP they control and cert pin so you can’t MITM the connection, can you?
Earlier quoted context omitted.
Dang can we get an update to the title to reflect this?
I see people tagging him as @dang, not sure if there's some backend logic to notify him but here goes nothing. New title from source: Warning: DNS encryption in Little Snitch 6.1 may occasionally fail
> @dang is a no-op. The only way to get reliable message delivery is to email hn@ycombinator.com
Earlier quoted context omitted.
Not at all actually, passing hostnames means they can fully handle happy eyeballs for you and all other performance optimizations that you can do if you resolve and connect in one call.
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 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.
I wonder if this affects iOS, too
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…
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."
Earlier quoted context omitted.
Of course, Apple does not want their app to call `getaddrinfo()` directly, because it would interfere with their internal XDR/NDS/IPS mechanism. 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.
What's XDR/NDS/IPS?
Earlier quoted context omitted.
I can't reproduce this. Some people say it has to do with ESET: https://www.reddit.com/r/MacOS/comments/1fievr5/updating_mad...
It's easily reproducible with a fresh macOS install. Yes, ESET has its own issue. But this is a problem in and of itself. https://imgur.com/a/Nr7Gk6c
> Going to the firewall settings screen, there can be no way to toggle access for the browser.
Earlier quoted context omitted.
But you are already on their OS, so they would always be able to do that. They make the kernel, the hardware and it's firmware, so it's a moot point and needless paranoia. Might as well use the API that gives a better user experience.
> 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…
(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.)