![]() Recently with using NordVPN I was having major problems with my applications just hanging on exit. Hopefully it all works out then Little Snitch can continue to be fully functional without a kext in the future. I am guessing this (or something similar) is the "alternate method" they're already looking into. I'm no developer, just thinking logically about how the system functions. Or perhaps create some logic to look at what traffic is captured by both then remove traffic already gathered by the API before combining both streams, this seems like it'd be a more reliable approach and require less maintenance. I imagine it'd be a little tricky to implement since the PF firewall isn't application based by definition but it could be done by keeping a regularly updated list of domains those services communicate with. what's to stop Little Snitch also using the PF firewall to capture all traffic? Shouldn't be difficult in theory no? They could show data gathered by both Apple's new API and the PF firewall, and configure the PF firewall component to capture traffic from services on the whitelist. If they start turning it into iOS for laptops they take away what makes it a great UNIX system for power users.Īlready I'm having to use outdated software and enable an obscure hidden function in recovery mode just to get a unencumbered firewall to run.Īctually, thinking a bit on this. Just install Brew and you've got the benefits of Linux on a well supported and easy to maintain UNIX OS. I and many others have loved macOS/OS X because it's a very user friendly, well implemented UNIX system that allows power users to do their thing if they wish. They can't really make the firewall config part of the read only filesystem protected by SIP because by nature the firewall config needs to be, well, configurable in order to actually be of any use within the OS.īut the moves they're making are clearly aimed at slowly locking down macOS more and more. Short of completely reinventing the entire firewall implementation I don't see how they'd force VPNs to use the API instead. Apple is bound to revoke support for kexts entirely in a future macOS release.Īs for VPNs though there is not much they can do regarding the PF integrations. I am going to have to keep an eye on this in the long-term though. So now all I have to do is run a command in recovery to allow Little Snitch 4.6 to install its kext then install the IVPN client as normal and both the problems I'm concerned about are gone. ![]() Since PIA and Mullvad are also use PF I think it's safe to assume any decent VPN service will continue to do the same for their clients. You can see in the code exactly how they manage WireGuard connections (WG is great) and they set their own firewall rules directly, no API. ![]() The current Apple management team doesn't have any interest in apologizing for these sort of missteps. Steve would have been completely pissed at Thursday's snafu and would have personally apologized (he did this) but Steve has been dead 9+ years. They will make no apology for Thursday clusterf*** and they will keep things status quo. In just a few days, every script kiddie on the planet knows they can inconvenience millions of Mac users by taking out because Apple showed them it was possible. That's bad design.Įven worse, it invites hackers to DDoS attack because now they know interrupting data packets to that domain will cripple millions of Apple devices. Apple's enforcement of OCSP validation has revealed a single point of failure as we saw on Thursday. ![]() ![]() In fact, I read about the /etc/hosts workaround while surfing this site on my Windows PC. When it first failed, I fired up my Windows PC which had no problem connecting to various e-mail accounts. I wasn't attempting to download Big Sur, I just wanted to read e-mail on my Mac. I consider this a massive F-A-I-L for Apple. By then Apple had fixed the underlying OCSP issue. So I reluctantly removed the /etc/hosts entry yesterday. However, I left the entry in /etc/hosts and then parts of App Store wouldn't connect. I used the /etc/hosts method and was able to fire up macOS Mail during this snafu. The big problem in blocking access to is that you don't know how every single application will react. You can block it via the /etc/hosts hack or in some environments you can block this at the router level or with a device like a Pi-Hole. Click to expand.Little Snitch is not necessary. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |