Most active commenters
  • 3pt14159(3)

←back to thread

1183 points robenkleene | 31 comments | | HN request time: 1.04s | source | bottom
Show context
3pt14159 ◴[] No.24838967[source]
This is one of those tough cases where software cuts both ways.

Some people are smart, informed developers that install a trusted tool to monitor their traffic and have legitimate reasons to want to inspect Apple traffic. They're dismayed.

Most people are the opposite and this move protects the most sensitive data from being easily scooped up or muddled in easily installed apps, or at least easily installed apps that don't use zero days.

Is the world better or worse due to this change? I'd say a touch better, but I don't like the fact that this change was needed in the first place. I trust Apple, but I don't like trusting trust.

replies(19): >>24838993 #>>24839043 #>>24839086 #>>24839126 #>>24839194 #>>24839419 #>>24840315 #>>24841406 #>>24841984 #>>24842961 #>>24843115 #>>24843241 #>>24844017 #>>24844287 #>>24844319 #>>24844636 #>>24845405 #>>24845660 #>>24845932 #
1. ballenf ◴[] No.24839086[source]
I'd argue this opens up a giant attack surface where malicious software will try to route its command and control communication through a protected service. Do we really want to trust that Apple will keep all 50+ of these privileged services fully protected?

I think it makes the "world" slightly worse in that it will be harder to discover malware. Little snitch has a small user base, but it's been used to identify many forms of malware and protect many more people once the threat is identified.

replies(6): >>24840000 #>>24841973 #>>24843556 #>>24844470 #>>24844572 #>>24894460 #
2. 3pt14159 ◴[] No.24840000[source]
Yes I agree with your first part. There are real drawbacks.

But it's like installing a custom HTTPS cert in your OS to inspect potential traffic that malware may use through, say, a Google Doc or Sheet. It's helpful to true professionals dealing with highly sensitive information, but it's ultimately a bigger source of compromise for the vast majority of software users.

I don't think there is an easy answer here. That's why I said I thought it made the world a "touch better" and I can see from your response that you understand the tradeoffs roughly as well as I do based on the wording of your response. The fact is that contemplating these hard tradeoffs belie the underlying truth: Securing computers is hard and getting harder and the stakes keep going up. I can't say if this move by Apple will ultimately be worth it, but I certainly understand the predicament they are in. This is no easy work.

replies(4): >>24843279 #>>24844065 #>>24844210 #>>24845648 #
3. comboy ◴[] No.24841973[source]
The decision is questionable, but you can always inspect traffic from the machine outside it, I would even say that's preferable in context of malware.
replies(2): >>24842095 #>>24843750 #
4. gowld ◴[] No.24842095[source]
Can you recommend a portable wifi firewall? Based on Raspberry Pi, perhaps?
replies(1): >>24842279 #
5. yayr ◴[] No.24842279{3}[source]
saw the GL.iNet+GL-MT300N-V2 recently - have not bought it yet, maybe it's time if it's good
replies(2): >>24843036 #>>24844282 #
6. rhizome ◴[] No.24843036{4}[source]
Ah, nice. I've been looking for something with which I can sniff my phone's activity, and that provides all of the keywords. And $20 ain't bad neither.
7. Godel_unicode ◴[] No.24843279[source]
Absolutely not, installing a CA makes attacks which weren't previously possible now possible. A host firewall isn't doing anything a network provider (read: your ISP, coffee shop, vpn provider, etc) couldn't already do. At least you can possibly look at what the host firewall is doing.
replies(2): >>24844333 #>>24845436 #
8. beaunative ◴[] No.24843556[source]
I think this is the case where you can have traffic monitoring set-up on your home router or any other network gateway available. It will be slightly more troublesome, but not impossible.
replies(1): >>24843726 #
9. DaiPlusPlus ◴[] No.24843726[source]
That doesn't work with HTTPS, obviously.

And with DNS-over-HTTPS, DNS-over-TLS and encrypted SNI, that makes it all the more harder.

replies(1): >>24864587 #
10. tssva ◴[] No.24843750[source]
TLS makes this difficult today and SNI encryption will make this next to impossible without installing a custom ca certificate and doing MITM. Even that isn't helpful when you are using a laptop that may not always be on the network where you have deployed a device for inspection. Better to be able to inspect or block on the device by application.
replies(2): >>24845274 #>>24845438 #
11. vaxman ◴[] No.24844065[source]
If they can circumvent system security for their own purposes (even though I’m sure it wasn’t planned to be that way), then they should be open to circumventing it for our country (by backdoor-ing their encryption), at least that is how I would imagine it will be referenced in the inevitable government lawsuit. What a major screw up Apple!
replies(1): >>24845258 #
12. specialp ◴[] No.24844210[source]
I helped a friend of mine with her OS X laptop. She had installed something bad and it installed MITM proxy and its own CA and other things to totally own and inspect all of her web browser traffic including SSL. So these features that we find powerful and informative also do have a dark side for more novice users.
replies(2): >>24844663 #>>24853521 #
13. jasonjayr ◴[] No.24844282{4}[source]
Someone else here recommended those, and now I have 11 for myself + my staff. They are great 2-port devices, with free GPIO pins too! Can do on-device VPN (openvpn, wireguard + tor) with a policy that kills internet access unless it's through the VPN.
14. jachee ◴[] No.24844333{3}[source]
Installing any third-party software that inspects network traffic makes attacks which weren't previously possible now possible, since that software can be targeted.
replies(1): >>24844580 #
15. zamalek ◴[] No.24844470[source]
> Do we really want to trust that Apple will keep all 50+ of these privileged services fully protected?

No.[1] That's what people need to start understanding.

Even if you decide to trust that someone will attempt to act in your best interests (you really shouldn't, see Google's extinct "do no evil" mantra), you can't trust anyone to do so perfectly.

All this aspirational goodwill that fans express on behalf of their favorite FAANGMUULA is the tech equivalent of flat earthing. The facts are simple: no software is perfect, you can't trust any software.

1: https://www.cvedetails.com/vendor/49/Apple.html

replies(2): >>24845513 #>>24846238 #
16. jameshart ◴[] No.24844572[source]
If you can get into apple’s system processes, you are already on the other side of the airtight hatchway. You can make sufficient changes to the system at that point that you can certainly mess with any user-installed firewall monitoring.
replies(1): >>24844598 #
17. ◴[] No.24844580{4}[source]
18. csande17 ◴[] No.24844598[source]
In any system with any kind of sane security model, being able to convince the Maps app to send arbitrary data to an arbitrary URL is not exactly the same thing as total change-stuff-not-even-root-has-access-to compromise.
19. calciphus ◴[] No.24844663{3}[source]
OK, but if it's a real security risk why do they only protect their own services? Why not have the user jump through a bunch of complex hoops like editing a plist file from an elevated terminal account? Hell, this is the os that makes it onerous to install software that didn't come from the App store. Clearly they don't mind throwing some user pain in front of basic activities.
replies(1): >>24844845 #
20. Wowfunhappy ◴[] No.24844845{4}[source]
> Hell, this is the os that makes it onerous to install software that didn't come from the App store.

No, they really don’t. Unsigned software is a little onerous, but signed software can come from outside the Mac App Store.

21. tialaramex ◴[] No.24845274{3}[source]
I would be astonished if Apple doesn't at least experiment with key pinning for the services it has decided to "protect" in this way.

If pinning is used then you can't interfere by interposing a middlebox, the connection would just fail. I guess it's possible Apple would find corporate pushback is too strong, but maybe not.

Don't use things you don't trust. If you trust Apple's proprietary software at least you are getting exactly what you signed up for. Apple gets to do whatever they want, which you apparently trust them to do. Will they accidentally let in bad guys? Maybe. You signed up for that too.

22. saagarjha ◴[] No.24845414{4}[source]
I’m having trouble understanding your comment, but it sure sounds a lot like complaining about downvotes–that’s usually not well received.
23. silentOpen ◴[] No.24845436{3}[source]
It depends on the host firewall... many quality operating systems allow host firewalls to apply process-based policy which your upstream certainly can’t achieve.
24. comboy ◴[] No.24845438{3}[source]
When we are talking about malware that's irrelevant. And if we are talking about inspecting Apple's traffic, I don't think you should trust things you see on their hardware running their operating system.
25. Aerroon ◴[] No.24845648[source]
Why not just give additional permission levels? I don't really get why so many permission models on what software can do are effectively "admin mode" or "user mode". Why can't you get a very strong warning when software tries to snoop on traffic, but you can still do it? Or maybe you have to go into settings and allow it or something like that.

When you rent space in a building, do you get access to every single apartment/office space in the building? No. You get access to specifically what you rented and the front door. The maintenance people for the building will have access to the front door and other maintenance areas, but won't have access to your space. We can clearly conceptualize models like that. We even have something like this on phones.

replies(1): >>24852176 #
26. 3pt14159 ◴[] No.24846238[source]
If you buy a ticket to a commercial flight, you're trusting software with your life.

It's a matter of degree of trust and hazard at failure.

replies(1): >>24846949 #
27. ◴[] No.24846949{3}[source]
28. saagarjha ◴[] No.24852176{3}[source]
Apple's argument is typically "users ignore strong warnings".
29. suifbwish ◴[] No.24853521{3}[source]
I’m trying to think of a powerful tool that is not dangerous. Still thinking
30. Wowfunhappy ◴[] No.24864587{3}[source]
It would work with HTTPS if you can set your software to accept a self-signed root cert. That's a significant if, however.
31. wooger ◴[] No.24894460[source]
Same situation with a government:

Even if you believe all the MPs / representatives are trustworthy and intend to act in your best interests, their competence is going to be limited, so we need to checks and balances and a limit on their power.