I don't use Mullvad, but I respect the shit out of them. This is a good, information dense explanation of the problem, their short term workaround and potential workarounds for others, as well as what will need to be fixed in Android. Good stuff.
I was a bit surprised to walk onto a DC Metro car last weekend to find the walls plastered with ads for Mullvad. Just wanted to note that Mullvad is spending money on traditional advertising, as well as blog posts like this.
However I'm worried that their goodwill and values will become more valuable to some private equity corp that buys them to asset strip and squeeze their customers.
If you don't use a VPN I'll note that they have a DNS service that is free. I think this demonstrates some support, at least in the way that increased traffic/usage can be support (and should help make Mullvad VPN users stand out less WRT DNS requests). The only downside I'll say is that the ping time for me is quite a bit higher than quad9 or cloudflare.
I wrote some info about it in this thread[0], including how you can do ad blocking at the DNS level (and cloudflare info for the same).
Simply the best VPN around, in terms of values, mindset, loyalty to their core beliefs and the relentless proof to stick to their moto over the last decades.
I AM a user of mullvad, and I am extremely satisfied. I once mailed support with a payment question and added a small iptables question regarding a problem I had.
I got back a swift reply which solved the payment question, and a detailed iptables reply with pros and cons of different solutions.
> these issues should be addressed in the OS in order to protect all Android users regardless of which apps they use.
Android's paranoid networking has always had an exception for System and OEM apps (which include Google apps). Most such bugs fixes are unlikely to fix that core assumption. Some code refs: https://github.com/celzero/rethink-app/issues/224
> The leak during tunnel reconnects is harder for us to mitigate in our app. We are still looking for solutions.
Android supports seamless handover between two TUN devices (on reconfiguration). It is tricky to get it right, but implementable.
To be fair, it’s the application developer who requests the application’s permissions and it is possible to release an app without internet permission.
I agree that the OS should have a way to override the permission, but it’s not Android itself just giving out internet access by default. It’s more that it’s almost every developer’s default setting when building the app.
The best example of no internet permission in an app off the top of my head is Hacker’s Keyboard – and you can understand why the developer chose to avoid it.
Which flashlight app? As far as I know there is no official flashlight app (though recently there is a built in flashlight feature). How is Google responsible for a third party app that refuses to work without an internet access?
This depends on the firmware used. I am writing this comment from an Oneplus device which allows blocking internet access on a per-app basis - on a stock firmware.
This has been a long-standing issue with android, that no matter how much you want it to use internal dns servers only, it'll decide to flip to cell and use those as it needs/wants. I've observed adb debugs for times recently to see why/when wireless was disconnecting, and it comes down to liveliness checks that if it can't see or resolve something, it'll simply bring up and try the cell data to do so.
It's especially frustrating when using internal dns records that only live internal will randomly not work on a phone. I can see that the device is on wifi that is feeding internal dns servers with the records, but it's resolving externally still for some android reason. This happens on my SO's phone when using things all the time, but I really don't use my phone in the house except to read books and rarely notice.
No idea how apple is about this, but the fact they try to proxy everything you do via their "privacy" vpn by default including dns as DOH, I can't imagine it is any better trying to use what they'd see as a competing product, and we know how apple feels about those.
Apple (or iOS) actually has a robust built-in way to filter and block traffic using configuration profiles. I’m uncertain if you can configure it per-app, but you can definitely whitelist/blacklist hostnames. For an example of this in action, check out this system-wide ad blocker https://myxxdev.github.io/depictions/MYbloXXforiOS/MYbloXXfo...
I built AOSP from source. It's supposed to be devoid of any google specific requirements. I went out of my way to block as many google servers as I could in the hosts file just to ensure it wasn't phoning home.
As far as I can tell the only issue I ran into was that despite being connected to a working wireless access point, the device reported I had no internet. It still worked, but it seems for the purposes of the status bar icon, and whatever other underlying system code, it was using a google server to verify internet was working.
I would just stay far away from android if you value your privacy, and probably tech all together.
That would be a pretty expensive mistake considering iOS also has VPN leaking issues that have been reported but unfixed for what, years at this point?
A few years ago, when I was testing various VPN set ups for a project, one thing I would do is have a MikroTik firewall device (hardware) sit between my computer and my main router, it’s only purpose would be to block any traffic, not dst for the IP address of the VPN server that the pc was connecting to.
This worked great to ensure that no traffic was leaked from pc to vpn server. The IP address of the VPN server you’re making use of rarely changes or if it does it’s easy enough to change on the MikroTik firewall.
Another method is to block all traffic not to the port/protocol pair being used by the VPN server if you don’t know the servers IP address (or if it changes). As an example drop any traffic not dst UDP 1194 (based on the type of VPN, of course). MikroTik routers also have a great little tool called torch that allows you to quickly and easily watch traffic (in addition to of course, supporting packet captures. Mikrotik routers are very reasonably priced and range from as low as $30 up to $3000 - all with no software licenses, and they are very powerful and capable if you know what you’re doing.
Can a standard linux distribution be configured as a network slug? I'm sick of companies forcing themselves onto people's private information without their consent.
This worked great to ensure that no traffic was leaked from pc to vpn server. The IP address of the VPN server you’re making use of rarely changes or if it does it’s easy enough to change on the MikroTik firewall.
Another method is to block all traffic not to the port/protocol pair being used by the VPN server if you don’t know the servers IP address (or if it changes). As an example drop any traffic not dst UDP 1194 (based on the type of VPN, of course).
outbound filtering by source and/or destination address and/or port is both a fundamental firewalling concept and standard configuration on all firewall-routing platforms. (policy-based routing[0], i.e. filtering by gateway, is the same.) generally speaking, only the con/prosumer products allow everything out by default.
just curious, what was your "main router" in this setup? ISP-supplied?
It was also a mikrotik - so of course, I could’ve done everything on that one.
however, I had to show / prove to a client that the set up could be easily duplicated at other locations (and moved around) where everything else on the network was unknown (only known / controlled parts were to be a Windows laptop, and the mikrotik router connecting ethernet from that laptop to whatever network also via eth.
For some of the configurations that needed to be very portable, the (very low end) MikroTik was powered via USB from the laptop
Customer also wanted the router to log any dropped/leaked traffic (which we did on the mikrotik to it’s internal memory, or a usb stick with a txt file log)
Raspberry pi with a second network interface… Running FreeBSD.
As to your other point… If you remove the Sim card from your telephone and then connect to a second router device that you carry with you… But we’re getting a little weird here…
The Problem with Android in regards to DNS: you just can't set your own IPv6 DNS Server on that platform, it gets changed anytime anything happens to your wifi.
There is no app, even for rooted android, which can disable the operating system from changing it.
When you are stuck with a router that always hands out IPv6 Adresses and doesn't let you turn that off you are just screwed.
I don't even know if you could install a firewall appliance behind that router and strip out the IPv6 DNS Servers it advertises.
What if you use the system-level support for DNS-over-TLS instead of setting the DNS server IP addresses? That's a global setting so it should apply regardless of which network you're on, or what happens on it. If you care about DNS requests leaking you should be using DoT or DoH anyway.
even bigger nightmare on iOS where 'always-on VPN' can only be configured on devices 'supervised' by an Apple-approved (documented application and telephone call with current employee required) organization's MDM solution—or you otherwise need a Mac to use the Apple Configurator app to even create a Configuration Profile containing the 'always-on VPN' key.
I've done this before for months at a time (the GL.inet E750 with an iPhone with no SIM) but oftentimes US GSM providers throttle the hell out of UDP traffic on weird ports (like to 64-128kbps, a tenth of a megabit), and also notifications are frequently delayed.
Yeah it's the best solution if you use any public wifi or even mobile telephony. Somebody can just run their own base station and then your phone would connect to that. If it's not your network don't directly connect without a mobile router.
Edit: Other commenters report that Android will silently re-enable cell data under various conditions, so this isn't a surefire solution, either.
The Grugq created a tool for this a decade ago (sadly unmaintained): https://github.com/grugq/portal as part of a presentation about operational security for hackers. It's a great watch if you're interested in how various (in)famous hackers thought they were secure and got busted anyway. https://www.youtube.com/watch?v=9XaYdCdwiWU
It'd be hilarious if phones hadn't largely replaced desktops/laptops for most people. I feel bad for all the kids who grew up/will grow up with nothing but a device primarily designed for media consumption and the collection of their private data for a computer.
Making userdebug builds with ro.adb.secure=1 to have root access via ADB with the rest of the security model intact is officially supported by GrapheneOS. Using Magisk massively rolls back the OS security model and is strongly discouraged. Using ADB on a production device isn't recommended with or without root, but it's officially supported if you want to do it. If you only grant ADB access to the computer you use for building and signing the OS, it's not a big deal. You need to be aware that you need to heavily secure that computer and shouldn't use it for anything else though.
Not OP, but I think that their concerns are legitimate for the most part. One example they've brought up is that, with root, a single bug in the display server could lead to complete and immediate compromise of the entire device (assuming root access is gated by UI prompts as is common on most rooted ROMs). Additionally, with verified boot, persistent changes to the OS made via root would cause the phone to be unable to reboot, which limits what you can do with root (assuming you still want verified boot). GrapheneOS standards are much higher than on desktop Linux, where root can be acquired as easily as injecting a fake `sudo` into ~/.bashrc.
Basically the idea is that there should be no need for root if everything is nicely gated by permission controls and high-level APIs. If every component of Android were actually well-designed, this idea would have more merit, but unfortunately there are still a few big gaps in what you can do with a rooted versus non-rooted device, e.g. custom firewall rules (which could provide a hotfix for the issue at hand here). When asked to expose more fine-grained firewall control to the end user, the Graphene devs basically responded that it's extremely difficult to set up firewall rules properly such that leaks are impossible [1], which may be true, but I'd like to think it's better than nothing.
Also, because root access would break Android's protection against end user application tampering, that would likely rule out the possibility of GrapheneOS receiving special support from banking apps, which is something they hope to see in the future [2].
a point as salient as it is germane. this is exactly why open-source software and hardware mobile device projects[0] will only continue to proliferate.
As much as I want to support those kinds of devices they're all insanely priced and have earned a reputation for failing at the most basic tasks. Maybe after it's been more than 3-5 years since the last forum post titled "can make/receive calls" I'll give pine phones another look.
Then tons of my most important systems are "insecure" by your definition. I'll give you $100k cash no questions asked if you can provide me with copies of my SSH private keys held on such devices.
Your definition is meaningless and not useful for reasoning or communication.
Root is complicated, I would refactor that to "Any system where you don't have access to the bootloader signing keys is insecure". If you can't run your own code on the device, you can't really trust it.
I remember being chastised in some Android subreddits years ago for going against the (probably astroturf) opinion that having root access was "insecure". Sigh...
Most are happy to outsource root to the OS manufacturer. And while I demand having root on Desktop, I don't see it happening on mobile for the majority.
Most phone users are oblivious to what root even is and yet still hate it when changes are pushed to their devices without notice, with no ability to revert to how things were or prevent unwanted changes in the future. This isn't acceptance but rather learned helplessness.
Block connections without VPN is turning out to be as reliable as my self-control at an all-you-can-eat buffet…if I'm not mistaken, these DNS leaks can very much expose where you browse and even your location, which kinda defeats the whole purpose of a VPN (and yes, even with VPNs, Android might still leak your DNS info. If you're really privacy-conscious, you might need to look beyond just using Android or keep your sensitive stuff off your phone)
Readit News
However I'm worried that their goodwill and values will become more valuable to some private equity corp that buys them to asset strip and squeeze their customers.
I wrote some info about it in this thread[0], including how you can do ad blocking at the DNS level (and cloudflare info for the same).
[0] https://news.ycombinator.com/item?id=40056162
I got back a swift reply which solved the payment question, and a detailed iptables reply with pros and cons of different solutions.
In short: they are great.
> these issues should be addressed in the OS in order to protect all Android users regardless of which apps they use.
Android's paranoid networking has always had an exception for System and OEM apps (which include Google apps). Most such bugs fixes are unlikely to fix that core assumption. Some code refs: https://github.com/celzero/rethink-app/issues/224
> The leak during tunnel reconnects is harder for us to mitigate in our app. We are still looking for solutions.
Android supports seamless handover between two TUN devices (on reconfiguration). It is tricky to get it right, but implementable.
I agree that the OS should have a way to override the permission, but it’s not Android itself just giving out internet access by default. It’s more that it’s almost every developer’s default setting when building the app.
The best example of no internet permission in an app off the top of my head is Hacker’s Keyboard – and you can understand why the developer chose to avoid it.
I sometimes wish I could just configure that per-app as a user. Frustratingly, on iOS it's possible only for mobile data, but not for Wi-Fi – why!?
Deleted Comment
https://support.google.com/googleplay/android-developer/answ...?
Deleted Comment
It's especially frustrating when using internal dns records that only live internal will randomly not work on a phone. I can see that the device is on wifi that is feeding internal dns servers with the records, but it's resolving externally still for some android reason. This happens on my SO's phone when using things all the time, but I really don't use my phone in the house except to read books and rarely notice.
No idea how apple is about this, but the fact they try to proxy everything you do via their "privacy" vpn by default including dns as DOH, I can't imagine it is any better trying to use what they'd see as a competing product, and we know how apple feels about those.
Are you sure you don't have wifi assist enabled? That's explicitly designed to switch to cellular when wifi signal is poor.
That is, if my configuration profile Becomes invalid or is non-functional, Will it just cease to pass traffic?
And a simple search shows definitely people annoyed by the exact same symptom of redirected DNS queries and inability to use internal-only DNS entries. https://www.reddit.com/r/ios/comments/uurkqr/limit_ip_addres...
As far as I can tell the only issue I ran into was that despite being connected to a working wireless access point, the device reported I had no internet. It still worked, but it seems for the purposes of the status bar icon, and whatever other underlying system code, it was using a google server to verify internet was working.
I would just stay far away from android if you value your privacy, and probably tech all together.
If you really want secure and private, get a dumb phone, and just use it as a phone. Anything else, use linux that you can actually control and audit.
This worked great to ensure that no traffic was leaked from pc to vpn server. The IP address of the VPN server you’re making use of rarely changes or if it does it’s easy enough to change on the MikroTik firewall.
Another method is to block all traffic not to the port/protocol pair being used by the VPN server if you don’t know the servers IP address (or if it changes). As an example drop any traffic not dst UDP 1194 (based on the type of VPN, of course). MikroTik routers also have a great little tool called torch that allows you to quickly and easily watch traffic (in addition to of course, supporting packet captures. Mikrotik routers are very reasonably priced and range from as low as $30 up to $3000 - all with no software licenses, and they are very powerful and capable if you know what you’re doing.
If we’re being formal, a true slug is one that has no IP address defined and is a transparent layer two firewall… But we don’t need to pick nits here…
[1] https://john.kozubik.com/pub/NetworkSlug/tip.html
just curious, what was your "main router" in this setup? ISP-supplied?
[0] https://en.wikipedia.org/wiki/Policy-based_routing
however, I had to show / prove to a client that the set up could be easily duplicated at other locations (and moved around) where everything else on the network was unknown (only known / controlled parts were to be a Windows laptop, and the mikrotik router connecting ethernet from that laptop to whatever network also via eth.
For some of the configurations that needed to be very portable, the (very low end) MikroTik was powered via USB from the laptop
Customer also wanted the router to log any dropped/leaked traffic (which we did on the mikrotik to it’s internal memory, or a usb stick with a txt file log)
If only we could insert a firewall between our apps and the modems in our phones.
As to your other point… If you remove the Sim card from your telephone and then connect to a second router device that you carry with you… But we’re getting a little weird here…
When you are stuck with a router that always hands out IPv6 Adresses and doesn't let you turn that off you are just screwed.
I don't even know if you could install a firewall appliance behind that router and strip out the IPv6 DNS Servers it advertises.
does this happen with wifi tethering too? if i have a vpn set up on a laptop that i connect through the phone's wifi will that leak in the same way?
even bigger nightmare on iOS where 'always-on VPN' can only be configured on devices 'supervised' by an Apple-approved (documented application and telephone call with current employee required) organization's MDM solution—or you otherwise need a Mac to use the Apple Configurator app to even create a Configuration Profile containing the 'always-on VPN' key.
Disclaimer: I've never used this feature. I only use it for backups and copying files to my iPhone.
The format cannot be that complex, right?
The Grugq created a tool for this a decade ago (sadly unmaintained): https://github.com/grugq/portal as part of a presentation about operational security for hackers. It's a great watch if you're interested in how various (in)famous hackers thought they were secure and got busted anyway. https://www.youtube.com/watch?v=9XaYdCdwiWU
This is terrifying.
...unless you care to elaborate on why you disagree with this statement in substance and/or on point?
Basically the idea is that there should be no need for root if everything is nicely gated by permission controls and high-level APIs. If every component of Android were actually well-designed, this idea would have more merit, but unfortunately there are still a few big gaps in what you can do with a rooted versus non-rooted device, e.g. custom firewall rules (which could provide a hotfix for the issue at hand here). When asked to expose more fine-grained firewall control to the end user, the Graphene devs basically responded that it's extremely difficult to set up firewall rules properly such that leaks are impossible [1], which may be true, but I'd like to think it's better than nothing.
Also, because root access would break Android's protection against end user application tampering, that would likely rule out the possibility of GrapheneOS receiving special support from banking apps, which is something they hope to see in the future [2].
Anyway, this particular issue is definitely a bug in AOSP, and will hopefully be resolved promptly. It's being tracked here: https://issuetracker.google.com/issues/337961996
[1] https://discuss.grapheneos.org/d/4113/6
[2] https://grapheneos.org/articles/attestation-compatibility-gu...
https://github.com/chenxiaolong/avbroot
Works great with CalyxOS and GrapheneOS.
[0] https://en.wikipedia.org/wiki/PinePhone_Pro
Your definition is meaningless and not useful for reasoning or communication.