The author of WireGuard lamented that certain network pathway must be preserved for existing Apple infrastructure before WireGuard app can be approved and made available by Apple App Store.
So, there is no easy way to catalogue what kind of cellular data traffic unless we magically ran a network capture (WireSHARK) at cell tower level or root our iOS phone.
I do do know for iOS phones that cellular data traffic is drastically different than LAN-based WiFi traffic.
Man, it sure would be nice if you could just... install an app without Apple's permission. Sure seems like they aren't looking out for your privacy or safety, in this situation.
Multiply “you” by all possible “yous”, multiplied by downsides of “just install an app” not vetted, for those “yous”. What’s the net effect on total privacy or safety of all yous out there?
If “you” are here on HN, odds are you are a vanishingly small part of the venn diagram of yous that should inform an iPhone PdM’s thinking on this issue.
EXCEPT, of course, for the NPS (net promotor score) / influencer aspect of you. Because we’re still in an era where the IT person in a circle causes others to make choices. HN users still have a disproportionate voice in tech trend setting.
But, as that person, you also have a responsibility to advise in well considered ways that help the person being advised, not yourself. As engineers, our entire purpose is to pay a blood/sweat/tears price to make technology accessible and useful to non-engineers.
You know what to do. They don’t. This device is for them.
Well, Android has been successful for years now with a model where it is possible to sideload an APK on any device, but it's buried sufficiently deep that the people who shouldn't be using it can't find it.
Why not replicate that (IMO) success?
Because if I understand GP correctly, they are talking about the ability for devs and white hats to install software which enables debugging and logging so it becomes much easier to find stuff like this?
Of course there is. Facebook and Oracle would immediately have some mandatory spyware you’d need to install. Curtailing developers’ freedom is a favourable choice for many consumers. Apple reflects that market pressure. (Android, its inverse.)
This isn't news, really - folks who actually work with large-scale deployments (and management) of iOS devices (particularly devices with cellular connectivity or which need to access random wifi networks) already know that the only real always-on VPN capability in iOS is IKEv2 pushed via your MDM system of choice. This has been true since the capability was first released in (IIRC) iOS 8. Yes, it's hella-lame Apple buries this information.
FWIW, this capability IS available to individuals using the free Apple Configurator application. The only catch is you'll need a machine running the latest MacOS to run the latest Apple Configurator.
Neat tip! So this will ensure that all connections including Apple's push notification service always go through the VPN?
How does this interact with public wifi captive portals, which often are a barrier to get online in the first place? A pretty common need would be to click through the public portal, sometimes dealing with email verification links or Facebook logins for those portals that require identifying oneself, and then to want 100% of traffic after the Internet connection is open to go through the VPN.
In other words, road warriors with security concerns need a solution that is NOT always-on but is comprehensive when on. Apparently iOS doesn't support this as per the article, and the always-on MDM suggestion isn't that either.
"A Network Slug, or "Slug", is a transparent layer 2 firewall running on a device with only two interfaces ..."
"So, while the device participates on the physical layer of the (probably ethernet) network, it does not have an IP address and cannot answer IP (or even ICMP) requests ..."
In my case, if I needed a VPN, I would use the excellent 'sshuttle' on, for instance, port 40 and then set the slug to allow only TCP port 40 and nothing else.
Not the OP but an example of such a setup would be connecting your ios device to a router that has firewall rules to only allow UDP port 51820 (ie. wireguard) to go through. That way if there's any traffic leakage from your ios device, nothing will get out because of the firewall on your router.
Correct - however, what you are describing is a normal firewall.
What distinguishes a "slug" is that it is not on the TCP/IP network - you cannot connect to it - and it acts as a "dumb" chokepoint that cannot be misconfigured or attacked or co-opted by other actors or software.[1]
Further, it is a physical, wired device with exactly two ports so you can conceptually witness - with your eyes - how your traffic is locked to whatever VPN you may be using.
[1] Yes, of course it can but when we think of a layer 2 bridge with no TCP/IP connectivity being attacked by a remote actor ... we're bordering on science fiction. For what it's worth, the FreeBSD filesystem I use on my slugs is mounted read-only. Defense in depth.
The real issue here is that VPNs for security purposes has always been a hack or misuse of virtual private networks. The real intended use case for VPNs is right there in the name: extending a private network remotely. Persistent connection to this remote network and guarantees that all network traffic uses this virtual interface is not what VPNs are built for.
VPNs are for securely connecting to machines on an internal network from an external one. Apple isn't a part of your internal network so this isn't actually an issue.
You can mitigate this by using a VPN router. I have a little GL.Inet router I use that ensures all traffic is passed through the VPN. The only caveat is you can’t travel with it even though they’re advertised as ‘travel routers’. You could use it in a hotel if you don’t trust random Wi-Fi hotspots. All I need is a .OVPN config file which I upload in the router’s admin dashboard, copy and paste my username and password and I’m set. A nice feature is if the VPN connection drops, the router doesn’t leak your IP.
Apple App Store mandates that their Apple network infrastructure shall not be impacted by an app (VPN, TailScale, WireGuard, et. al.)
In addition to unimpeded Apple network pathway, DNS resolver is being resolved by Apple DNS recursive DNS server during your tunneling setup, arguably resolving even just the IP address(es) as well as DNS names of VPN server.
More on this sad saga of Apple iOS and VPN, et. al.:
Edit: of course, an external router would only leverage the WiFi part of iOS. We could use just the WiFi part of iOS and totally ignore the mysterious cellular traffic.
I’m not talking about an app. I’m talking about a router that VPN-ifies all your traffic to mitigate any form of leak. That article talks about iOS leaking traffic when using VPN apps. A VPN router is the only solution to stop this from happening.
Or you can just use a different device. There's plenty of hardware/software that respects your VPN routing rules, Apple is the outlier here. You don't need a complicated racked-and-stacked Ubiquiti when kernel-level WireGuard will do the trick.
See my comment elsewhere in the thread about using your normal network setup, but inserting a "slug" that only allows your VPN port and/or endpoint(s).
Since the slug is invisible, and has no IP address, and runs no daemons, etc., the only misconfiguration possible would be the initial one.
Once the slug is in place, there is no more "accidentally didn't use the VPN..."
Well I have a Gl.inet mango router which I think supports 3g USB modems, so you could hook up that and power the router with a power bank. You can use it traveling, but not when driving as you would need some sort of Wi-Fi hotspot in the car. You could setup one on your phone though this is where everything gets complicated and not for the average user.
Is this talking about Cell Phones only ? To me it seems to.
No surprise with IOS, and I am rather sure the same can be said for Android. Cell Phones are closed systems, so the manufacturers can get around anything and probably do a good job of hiding this too.
If you want to hide yourself, never use any Cell Phone.
The author of WireGuard lamented that certain network pathway must be preserved for existing Apple infrastructure before WireGuard app can be approved and made available by Apple App Store.
So, there is no easy way to catalogue what kind of cellular data traffic unless we magically ran a network capture (WireSHARK) at cell tower level or root our iOS phone.
I do do know for iOS phones that cellular data traffic is drastically different than LAN-based WiFi traffic.