[HN Gopher] DNS traffic can leak outside the VPN tunnel on Android
___________________________________________________________________
DNS traffic can leak outside the VPN tunnel on Android
Author : ementally
Score : 780 points
Date : 2024-05-03 13:46 UTC (1 days ago)
(HTM) web link (mullvad.net)
(TXT) w3m dump (mullvad.net)
| nazgulsenpai wrote:
| 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.
| pqdbr wrote:
| Blog posts like this (instead of endless YouTube sponsorships
| like their competitors do) are what made me choose them as my
| VPN service.
| bloopernova wrote:
| I use and recommend Mullvad.
|
| 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.
| input_sh wrote:
| Why do you think they'd accept an offer? They openly said
| it's not for sale:
| https://mullvad.net/en/blog/2021/9/16/ownership-and-
| future-m...
|
| Not everyone's in it for the money. Assuming they're not
| operating at a loss, even less so.
| Groxx wrote:
| Not everyone telegraphs if they're in it for the money.
|
| In some lines of business, like (purely hypothetically)
| security, it might actually be a bad thing for your
| business if you do.
|
| I also use mullvad because I don't really think this is
| the case, but bad actors are generally hard to
| conclusively identify _by design_. And VPNs are pretty
| far out in the "just trust me bro" realm of handing over
| all your browsing habits with no ability to check their
| real behavior.
| reaperman wrote:
| I think legally they would have to change their ownership
| directive document in Switzerland to allow the board of
| directors to allow the two founders to sell more than 50%
| of their shares. So you might get a heads up!
| blowfish721 wrote:
| They arent based in Switzerland but in Sweden.
| yencabulator wrote:
| Mullvad is trying pretty darn hard to be as far from
| "just trust me bro" as is feasible. If you do take their
| word for how they run their systems (/are working
| toward), their servers are diskless (what logs?), will
| only run software signed by their infrastructure team,
| and will remotely attest that their software has not been
| tampered with.
|
| This is so very, very, far away from the typical VPN
| company that any such comparison sounds ridiculous to me.
|
| Just the pretense of doing all this work costs so much
| that a greedy biz bro simply wouldn't.
|
| https://github.com/mullvad/system-transparency
|
| https://www.system-transparency.org
|
| https://news.ycombinator.com/item?id=29903695
| kfreds wrote:
| Thank you for noticing! System Transparency is taking way
| longer to figure out, design and build than I expected.
| On the other hand the project is quite ambitious, and our
| work on ST has sprouted two additional OSS projects:
|
| - https://www.sigsum.org (a transparency log with witness
| cosigning)
|
| - https://tillitis.se (an open-source hardware FPGA-based
| security key with measured boot)
| fragmede wrote:
| > a greedy biz bro simply wouldn't.
|
| On the other hand, if it were an NSA honeypot, doing all
| that work would easily be worth the cost. Personally, I
| don't think they are, so I'm merely pointing out that
| there are angles other than totally above-board honest
| legitimate reasons, and "greedy biz bro".
| yencabulator wrote:
| For sure. Them being Swedes with a long track record
| decreases that probability a lot.
| kfreds wrote:
| > VPNs are pretty far out in the "just trust me bro"
| realm of handing over all your browsing habits with no
| ability to check their real behavior.
|
| Yes. It is quite an interesting situation, really. It's
| also a fun challenge! To what extent can we prove that we
| are trustworthy, and using what tools? Do those tools
| exist or do we have to invent them?
| fragmede wrote:
| You'd have to invent this one at least, as it currently
| doesn't exist. As the DNS server operator, you can view
| all my DNS queries. In a zero-trust environment where I
| don't trust you not to log all user queries and forwards
| them to the NSA, you'd need to use homomorphic encryption
| and create a DNS client and server than can do a lookup,
| without you, the DNS server operator, from finding out
| what the DNS lookup was of.
|
| https://github.com/menonsamir/spiral-rs claims to have
| implemented this at a level that's practical for real
| world applications, with a demo for a wikipedia server,
| but it's far too slow, as demoed, for use as DNS server.
|
| Now, the fact of the matter is that you can map my
| account ID back to the IP I'm connecting from, but with
| very limited way to map from my IP to my identity
| protects that in many ways, but data-mining at scale,
| knowing how many users connecting to one proxy server
| from city X, would be worth something to advertising and
| related companies who are more interested in large habits
| of users. If it turns out no one uses the pirate bay
| anymore, but use torrent site XYZ, I know where I'd place
| my advertising dollars for, say, a VPN product.
|
| This is on the extreme end, but you asked for a fun
| challenge! :)
| kfreds wrote:
| Thanks! :)
|
| I should've been more clear. The questions I posed above
| are rhetorical. I've spent well over half a decade
| obsessing over them. See my mention of System
| Transparency, Sigsum and Tillitis elsewhere in this
| thread.
| fragmede wrote:
| Thank you for your hard work. You've spent way more time
| on the problem than I. Didn't realize it was rhetorical!
| Mostly I wanna see homophobic encryption happen in
| practice. :p
| Groxx wrote:
| tbh I don't think they exist. And I'm, like, half okay
| with that - it's entirely justified paranoia, bad actors
| of all skill levels undeniably exist and they hide
| successfully for many years, but I do believe good actors
| exist. It's why I chose mullvad.
|
| At best you have stuff like attestation... but we all
| know those have a long history of being flawed and are
| subject to loads of side channels that can't be attested
| against. Plus VPNs are such a honeypot in every
| conceivable way that TONS of state-actor-level efforts
| are entirely reasonable, and that could easily include
| cheating on basically all attestation systems imaginable.
| We're just kinda stuck trusting history and lack of
| public leaks / correlated actions / whistleblowers IMO.
|
| Or, frankly, the Mozilla partnering counts for a lot to
| me. I won't use their setup because it doesn't have non-
| vpn-app options, but they're a group I mostly trust to
| have people's safety at heart.
|
| Personally, stuff like Tor (where by construction you
| only need to touch a couple good actors to be reasonably
| secure, and anyone can contribute) is about the only
| mostly-actually-trustworthy kind of system. You can
| _expect_ malicious actors to participate there, and still
| have a reasonable level of privacy, particularly if you
| check a few personally (which is feasible because anyone
| can contribute). Tor and similar have plenty of issues,
| but structurally they 're much more sound by design than
| any centralized VPN can ever be. Now if only they were
| even a tiny fraction as usable...
| selectodude wrote:
| There are billboards for Mullvad all over Chicago which
| kind of weird me out.
| ziddoap wrote:
| They do traditional advertising (billboards being one
| example) instead of paid reviews, affiliate/influencer
| advertising, etc.
|
| https://mullvad.net/en/help/policy-reviews-advertising-
| and-a...
| neuronexmachina wrote:
| Oh wow, I wish more companies had pages like that
| summarizing what sort of marketing/advertising they
| do/don't use.
| ziddoap wrote:
| I'm fanboying at this point, but I honestly believe
| Mullvad should be the poster child for a lot of things
| other companies should be doing. Transparency,
| accountability, data minimization, thorough
| documentation, publicly available audits, etc.
| hughesjj wrote:
| I've been a happy expressvpn customer since dec 2016 but
| I'm sincerely considering switching to mullvad at this
| point
| kfreds wrote:
| I'm sorry you feel that way, but I can relate. I
| initially had mixed feelings about it as well.
|
| On the other hand the campaign we did in Stockholm last
| year worked out quite well. It managed to affect both
| domestic and EU legislative discussions at the time. Or
| at least our campaign contributed to moving the
| discussion in the right direction.
|
| How much is that worth? I'm not sure, but the reason we
| started Mullvad in the first place was to conduct
| political action through entrepreneurship, specifically
| regarding mass surveillance and censorship.
|
| If nothing else it seems to amuse a lot of people,
| including me and my colleagues. When I first heard of the
| idea of plastering privacy propaganda all over some major
| U.S. cities my initial reaction was more or less "lol, we
| can just do that?". As it turns out we can. :)
| nickburns wrote:
| thank you for offering up in this forum at least your own
| personal contributions to your organization's position on
| its advertising campaigns. not sure if any official
| statements on the matter have been made elsewhere, but
| you've assuaged at least my own slight concern about it
| with this one. truly. (and by 'truly' i mean i've been
| meaning to stuff some cash in an envelope addressed to
| you guys!)
|
| transparency is absolutely a corporate virtue.
| j0e1 wrote:
| Thank you for sharing that! I am definitely part of the
| HN group think that tends to be irked by mass marketing-
| mainly because of baggage from the past of false
| advertising. However, I do agree that getting the non-IT
| geek's attention is what would actually move the needle
| for political action. I was amused (mostly surprised) to
| see a billboard while driving down the 110 in LA. More
| importantly, it led to a cool discussion with my non-tech
| wife who now appreciates your guys' brand more. :)
| chefandy wrote:
| As frustrating as it is, even great products don't sell
| themselves. I find much, if not most marketing for
| subscription-based services pretty scummy, but it's not
| like it has to be, and I'd much rather see physical ads
| than how most stuff gets surreptitiously slipped into my
| surveillance-capitalism-sponsored life.
| pyinstallwoes wrote:
| How did you measure the effectiveness of physical ads to
| issues and other key metrics? I'm just curious what it
| takes to measure those as it's always been mysterious to
| me. It seems like it needs to include a coupon code or
| something? Also interesting re: legislation. How so?
| kfreds wrote:
| To my knowledge we don't measure it, at least not in the
| way I think you mean.
|
| I can't speak for my marketing colleagues but I would
| assume they reason about it. It seems like a complex
| system to me, which means the approach kind of has to be
| (1) forming an understanding of the system and (2)
| deciding whether one is comfortable with the uncertainty.
|
| One aspect that makes the cost/benefit assessment quite a
| bit easier is that we don't only care about how many new
| paying customers we get. It's also fun to do this kind of
| advertisement. How many interesting conversations about
| privacy have been had as a result of people seeing our
| billboards? That's worth something too.
| gaudystead wrote:
| Okay, this comment was the comment that got me sold on
| Mullvad. I was looking for a VPN I liked anyway and if
| you also use your business entity to help drive
| legislation toward a more privacy focused end, I'm in.
| trelane wrote:
| For me, (one of) the moments was when there figured out
| how to do remote attestation of the _server_ to check
| that what it was running was what you expected, so you
| could check its privacy yourself.
|
| Rather a neat subversion of the common corporate use of
| remote attestation, to _preserve_ user privacy and
| security rather than curtail it.
| kfreds wrote:
| Thank you! You are of course referring to System
| Transparency. I feel obligated to point out that we have
| yet to fully implement that idea. I've been working on
| it, and the related projects Sigsum and Tillitis, for the
| past six years. There have been lots of detours, but we
| are making progress towards the vision outlined in the
| blog post I wrote in 2019:
| https://mullvad.net/en/blog/system-transparency-future
|
| Two years ago we moved the OSS projects System
| Transparency and Sigsum to its own organization: Glasklar
| Teknik AB (glasklarteknik.se).
|
| The OSS and OSHW project TKey was moved to Mullvad's
| other sister company Tillitis AB (tillitis.se)
| SturgeonsLaw wrote:
| https://en.m.wikipedia.org/wiki/Sousveillance
| walterbell wrote:
| _> plastering privacy propaganda all over some major U.S.
| cities_
|
| The ads are great to see in NYC subway and giant
| billboard near NY Times HQ.
|
| Is there an online page with all of the ads? Maybe a
| video tour of the ads "in the wild" in different cities?
| kfreds wrote:
| Thanks! I don't think so unfortunately. It's a great idea
| though.
| walterbell wrote:
| Since there's no existing compendium, maybe a social
| media contest for people submitting photos of anonymized
| objects (e.g. in a box), books (hardback with custom
| cover), humans (costume/mask/etc) with Mullvad ads /
| billboard in the background. Crowdsource field reporting
| and motivate discussion about metadata in online and
| offline privacy.
| anakaine wrote:
| Thank you for the service that you and the rest of the
| team provide. I've found it to be excellent, and you're
| one of only a very slim number of transparent VPN
| providers who seem to be in it for the right reasons.
| starttoaster wrote:
| What is it about a company spreading awareness about
| their product that weirds you out in particular, I'm
| curious? Billboard advertisements are an awareness type
| of advertisement. I'd be much more concerned to learn
| about paid endorsements, which they document on their
| website that they specifically do not do. Endorsements
| are a much more sensitive form of advertising, where once
| money trades hands for an endorsement, it stops being a
| useful third party assessment and starts being an
| advertisement disguised as a third party assessment.
| Awareness advertisements just make good business sense,
| so I'm genuinely curious why those would shy anybody
| away.
| epcoa wrote:
| I saw them on the side of a CTA bus for the first time
| the other day. I don't think it is bad at all, but the
| initial reaction for me as an American used to typical
| bus advertising it was exactly as if seeing an ad for
| 4chan there. It just isn't the expected modality for the
| product.
|
| (Seeing the reply down thread from a Mullvad rep, this is
| not unexpected)
| int_19h wrote:
| I agree with you, but I also understand where GP is
| coming from. For the past 20 years, what people are
| mostly exposed to is internet ads, which are, to put it
| mildly, _pushy_. As a result, all ads now have to deal
| with considerable negative sentiment as a baseline simply
| by virtue of being ads.
| snowwrestler wrote:
| My concern with the Mullvad ads is that some are
| essentially lying about what their product does. One of
| the ads I recall said something like:
|
| > Imagine an ad that won't track you after you see it
|
| > Mullvad VPN
|
| That's not what a VPN does though. Tunneling my browsing
| does not stop sites from serving ads, setting cookies,
| fingerprinting browsers, etc.
| xnyan wrote:
| > That's not what a VPN does though.
|
| Mullvad itself is extremely clear that use of a VPN alone
| is not enough for the reasons you stated. Mullvad VPN
| (which is what they advertised) is a suite of products
| and services, some of which are:
|
| - DNS services (ads, tracking)
|
| - A privacy-optimized browser (cookies, fingerprinting)
|
| - Network services like multihop routing (many benefits
| such as resistance to timing attacks)
|
| All of these services are included with your subscription
| at no additional cost. I feel like the claim of
| preventing ad tracking is as legitimate as it could
| possibly be.
| wepple wrote:
| They're in it for the money.
|
| They've made some claims that are downright lies, I
| chuckle at the idea anyone would trust them.
|
| The NYC subway ads state that they save you from online
| web ad systems; blatantly false.
|
| I'll take a photo next time I see the ad to store away.
| cjaybo wrote:
| > They've made some claims that are downright lies
|
| Which claims are you referring to?
| wepple wrote:
| From my above post:
|
| > The NYC subway ads state that they save you from online
| web ad systems; blatantly false.
| Rastonbury wrote:
| What were the lies?
| wepple wrote:
| From my above post:
|
| > The NYC subway ads state that they save you from online
| web ad systems; blatantly false.
| TheCraiggers wrote:
| A very cursory search online shows that it's actually
| _your_ statement which is blatantly false. They 've
| offered ad blocking for years.
|
| While it's true they've not always offered this, it's on
| you when making such claims to ensure you're still
| factual.
| wepple wrote:
| > They've offered ad blocking for years.
|
| Please show me evidence to back this up and I'll happily
| walk back my statements.
|
| The "mullvad" browser is not their VPN product. And if
| you think DNS denylisting prevents "ad networks from
| spying on you", I have some unfortunate news for you. It
| works to prevent the rendering of a subset of ads
| (especially in the browser), but isn't worth a damn for
| actual behavioral analysis.
| trelane wrote:
| https://mullvad.net/en/blog/how-set-ad-blocking-our-app
|
| "How to set up ad blocking in our app"
|
| Dated May 27, 2021
|
| I would guess it started with something like this: they
| serve DNS to prevent DNS leaks when using the VPN. They
| realize they can use this to block domains, just like a
| pihole or Cloudflare DNS. They integrate that into their
| VPN offering.
|
| It's pretty logical once you think about it, but it was a
| surprise to me too.
| kfreds wrote:
| A VPN is not enough for privacy. But in combination with
| a privacy-focused browser, you make sure to block third-
| party cookies and other tracking technologies used by the
| data collectors.
|
| The paragraph above is clearly visible on our landing
| page. We don't want people using our service for things
| it's not designed for.
|
| The paragraph below is also a direct quote from our
| website.
|
| "When you visit a website, you can be identified and
| tracked through your IP address, third-party cookies, all
| kinds of tracking scripts, and through so called browser
| fingerprints. That's why masking your IP address is not
| enough to stop the data collection. However, by using a
| trustworthy VPN in combination with a privacy-focused
| browser, you can put up a better resistance against the
| mass surveillance of today. That's why we partnered with
| the Tor Project to develop Mullvad Browser - a browser
| designed to minimize tracking and fingerprints."
| tredre3 wrote:
| Your knowledge might be a bit out of date, they do offer
| an ad-blocking DNS now.
|
| I don't know if it's easily configurable in the app,
| though.
| trelane wrote:
| > I don't know if it's easily configurable in the app,
| though.
|
| I just discovered it by accident the other day.
|
| It's super easy.
|
| See "DNS content blockers" at
| https://mullvad.net/de/help/using-mullvad-vpn-on-
| android#vpn...
| ph0ny wrote:
| They are making bank. Thank you open Swedish data:
|
| https://www.allabolag.se/5592384001/mullvad-vpn-ab
| radicality wrote:
| I've been using and still using Mullvad but also getting
| worried. I live in nyc and in the last few months I've seen
| a _lot_ of ads from them. Huge billboards in high-traffic
| areas. Full-sized ads on a side of a bus. A whole subway
| car just with mullvad ads.
|
| Some of the ads also felt deceptive making it seem like it
| will prevent all your online tracking, even though we know
| that's not the case.
| fernandotakai wrote:
| they do advertise, but they try to keep traditional
| (instead of influencers)
| https://mullvad.net/en/help/policy-reviews-advertising-
| and-a...
| kfreds wrote:
| > Some of the ads also felt deceptive making it seem like
| it will prevent all your online tracking, even though we
| know that's not the case.
|
| I'm sorry to hear that. For what it's worth our marketing
| colleagues make a big effort to minimize the risk of such
| interpretations. Sometimes a really snappy string of
| words can be interpreted multiple ways. There's also only
| so many words we can put on an ad before it gets messy.
| We do try hard to make the nuances clear on our website,
| which ultimately is where any new users will have to go
| in order to buy the service.
| woodruffw wrote:
| I'm a big fan of your service, but I agree with GP. I
| rode the subway yesterday and saw a Mullvad ad that
| strongly implied that a VPN is adequate protection
| against data brokers and data collection on websites.
|
| It certainly wasn't the most egregious VPN ad I've ever
| seen, but it was disappointing to see Mullvad imply
| privacy properties for VPNs knowing that ordinary people
| don't understand cookies, sessions, fingerprinting, or
| JavaScript.
| kfreds wrote:
| Did the ad in fact talk about the VPN by itself, or in
| conjunction with the Mullvad Browser?
|
| In any case we make the most important nuances clear on
| our landing page, and in other places on our website.
| woodruffw wrote:
| I believe it just said Mullvad, which I interpreted to be
| the VPN. It was on the NYC subway.
| wepple wrote:
| Sorry, not buying it. To claim that you stop online ad
| networks is a downright falsehood and you know it.
|
| That copy should've never made it past basic checks for
| legitimacy.
|
| Or alternatively: feel free to describe to HN how Mulvad
| protects users against ad networks.
| nickburns wrote:
| To claim that you stop online ad networks is a downright
| falsehood and you know it.
|
| can you link to these remarks? i can't see kfreds making
| any reference to ad networks anywhere.
| wepple wrote:
| I'm going to make sure to photograph the NYC subway ads
| next time I see them
| nickburns wrote:
| ah, now i understand. your earlier comment very much read
| like you were accusing kfreds personally of making such a
| statement about ad networks. but you meant to say one (or
| more) of the ads you've seen yourself appears to makes
| such a claim. thanks for clarifying.
| kfreds wrote:
| > feel free to describe to HN how Mulvad protects users
| against ad networks.
|
| A VPN is not enough for privacy. But in combination with
| a privacy-focused browser, you make sure to block third-
| party cookies and other tracking technologies used by the
| data collectors.
|
| That's why we partnered with the Tor Project to develop
| Mullvad Browser - a browser designed to minimize tracking
| and fingerprints.
|
| Please also note that this information is clearly
| displayed on our landing page. We don't want people using
| our service for things it's not designed for.
| wepple wrote:
| In combination?
|
| The browser piece is doing almost all of the work against
| ad networks, isn't it?
|
| Which part of defense against ad networks does a VPN
| contribute to?
| robertlagrant wrote:
| > Sorry, not buying it. To claim that you stop online ad
| networks is a downright falsehood and you know it.
|
| Where do they claim their VPN stops online ad networks?
| wepple wrote:
| The NYC subway ads
| robertlagrant wrote:
| Can you point me at the one you're talking about, please?
| trelane wrote:
| There are settings to help with that, though.
|
| https://mullvad.net/en/blog/aiding-to-break-habits-
| gambling-...
|
| https://mullvad.net/en/blog/how-were-knocking-down-ads-
| and-t...
|
| It's not going to prevent everything, but it'll
| definitely _help._
| 2OEH8eoCRo0 wrote:
| I was an extremely happy user until they removed port-
| forwarding. That forced me to switch unfortunately :(
| nicce wrote:
| What was the reasoning for removal?
| ziddoap wrote:
| Unsurprisingly, they wrote a blog post about it.
|
| > _" Unfortunately port forwarding also allows avenues
| for abuse, which in some cases can result in a far worse
| experience for the majority of our users. Regrettably
| individuals have frequently used this feature to host
| undesirable content and malicious services from ports
| that are forwarded from our VPN servers. This has led to
| law enforcement contacting us, our IPs getting
| blacklisted, and hosting providers cancelling us."_
|
| > _" The result is that it affects the majority of our
| users negatively, because they cannot use our service
| without having services being blocked."_
|
| https://mullvad.net/en/blog/removing-the-support-for-
| forward...
| Gormo wrote:
| How were you using port forwarding with an external VPN?
| fullspectrumdev wrote:
| A lot of VPN's allow you to forward a port from local to
| "listening" on one of their servers, to make it easier to
| use P2P filesharing and such.
|
| Mullvad and a few others have had to disable this feature
| because it turns out it's super useful for hosting
| malware C&C servers, phishing pages, etc
| Gormo wrote:
| I sort of understand their reasoning, then, because
| acting as a reverse proxy for externally-initiated
| inbound connections is not typically within the scope of
| VPN services per se, and especially outside the scope of
| Mullvad's particular mission of offering VPN services for
| the purposes of protecting privacy and suppressing
| censorship.
|
| There are other solutions for your use case, with or
| without a third-party VPN, that wouldn't require port
| forwarding. There are also other VPN services that do
| offer this functionality.
| epcoa wrote:
| It's typically for BitTorrent.
| uneekname wrote:
| 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.
| watermelon0 wrote:
| FYI they are transparent about buying outdoor ads:
| https://mullvad.net/en/help/policy-reviews-advertising-
| and-a...
| readyman wrote:
| The ads themselves make the buying pretty transparent
| the_du_ wrote:
| XD
| bragr wrote:
| I was surprised this week to see a big yellow Mullvad ad on
| LA Metro bus. They must be on an advertising push.
| SpaceManNabs wrote:
| I saw mullvad vpn ads on the L train (nyc) this week!
| zevra wrote:
| I saw them on metro north going into nyc
| shantara wrote:
| Mullvad's "Stop chat control" ads have been all over
| Stockholm a few months ago, including this giant banner in
| the airport. This is the kind of advertising I respect.
|
| https://mastodon.online/@mullvadnet/109959480069637837
| sli wrote:
| They don't do YouTube sponsors but they sure plastered their
| ads all over Chicago. Literally everywhere.
| dkga wrote:
| Good points. By the way, how do they compare with the likes of
| ProtonVPN?
| rmdes wrote:
| 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.
| stoniejohnson wrote:
| only bummer is that due to their strong respect of user
| anonymity a lot of their IPs are blocked by major platforms
| like Reddit
| spxneo wrote:
| how are platforms like reddit able to get complete list of
| mullvad IPs and other vpns but not residential proxies?
| stoniejohnson wrote:
| people use mullvad IPs maliciously -> those IPs end up on
| blocklists
| adamomada wrote:
| It's an industry now e.g. https://ipinfo.io
| spxneo wrote:
| damn this is crazy, how did they even compile all the
| residential proxies
|
| im seeing it detect!!
| fragmede wrote:
| Net flows. A residential proxy should have a residential
| amount of traffic coming from it. If one IP has 1000x the
| usual traffic one household could reasonably account for,
| then mark it as a residential proxy. It won't be 100%
| accurate, but it's sufficiently accurate for reddit to go
| on a blocking spree.
| utensil4778 wrote:
| How does one even get access to that kind of information?
| Are ISPs just selling this stuff or what?
| reincoder wrote:
| We have 700 servers around the world and we run
| measurements over all of the usable internet space,
| including assigned IPv6 addresses.
|
| I highly recommend reading some of our blog posts and
| community posts.
|
| You can also checkout our IP data tags page:
| https://ipinfo.io/tags
| reincoder wrote:
| Our detection model at ipinfo is largely based on
| behavior models of IP addresses. We have 700 servers
| around the world from which we run internet measurement,
| allowing us to reliably determine which IP addresses are
| VPNs or proxies. These measurements are largely
| ping/traceroute data, which enable us to estimate a
| number of different things most importantly IP location
| data.
|
| If you are interested in what kind of other information
| we can discover from our internet measurements, check out
| our tags page: https://ipinfo.io/tags
| lbhdc wrote:
| I am not sure how they do it, but one option is setting
| some arbitrary threshold for number of devices
| fingerprinted on a single ip in a given period of time.
| Something like taking the average number of devices and
| denying access to ips that they detect ~3 sigma different
| devices from.
| jorams wrote:
| Well I don't know how many IP addresses each of Mullvad's
| servers have, but they list a domain name, IPv4 and IPv6
| address for all of them publicly[1].
|
| [1]: https://mullvad.net/en/servers
| EA-3167 wrote:
| I use Mullvad and Reddit has never tried to block me, in fact
| I've run into no blocks at all. Then again my browsing habits
| are quite boring.
| stoniejohnson wrote:
| you are likely logged in! they only enforce the blocklist
| on lurkers
| EA-3167 wrote:
| You're correct, and I just tested it... seems that about
| half of Mullvad IP's are in fact blocked if you're logged
| out. Good catch.
| colordrops wrote:
| What VPN do you use, if any?
| godelski wrote:
| 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).
|
| [0] https://news.ycombinator.com/item?id=40056162
| gregoryl wrote:
| That's unfortunate, they only recently rolled out prompts to push
| Android users away from their in-app always-on functionality to
| the built in version.
| tiagod wrote:
| I guess the safest setup is to have mobile data off on your phone
| and carry an OpenWRT hotspot to do the VPN bit upstream from the
| phone.
| nickburns wrote:
| it's true.
|
| 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.
| fullspectrumdev wrote:
| Making a simple OSS tool to generate valid configuration
| profile files seems like a potentially useful way to spend a
| weekend sometime.
|
| The format cannot be _that_ complex, right?
| nickburns wrote:
| lol, hit me up with your rate. my only term is that i get
| to be watching over your shoulder the whole time.
| jasomill wrote:
| Looks like it's just XML .plist format, and (at least
| partially) publicly documented:
|
| https://developer.apple.com/business/documentation/Configur
| a...
| yonatan8070 wrote:
| Until you get to the bit where I'm guessing you need Apples
| private keys to sign it or whatever
| walterbell wrote:
| Web page for offline generation of iOS VPN configuration
| profile: https://mobileconfig.app
| brobinson wrote:
| I _think_ iMazing can do what you want:
| https://imazing.com/configurator
|
| Disclaimer: I've never used this feature. I only use it for
| backups and copying files to my iPhone.
| nickburns wrote:
| never even thought to check if iMazing had any of this
| functionality. disclaimer noted, great tip regardless.
| thank you.
| mise_en_place wrote:
| 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.
| hackermatic wrote:
| 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
| mise_en_place wrote:
| > Other commenters report that Android will silently re-
| enable cell data under various conditions
|
| This is terrifying.
| autoexec wrote:
| It's expected. The people who own the phones aren't in
| control of the OS and the wireless chipsets are
| closed/proprietary. Cellphones really shouldn't be trusted
| by anyone.
| mise_en_place wrote:
| Correct, the baseband usually has binary blobs. Although
| I am curious why Google/Apple decided not to make their
| own baseband, given their new silicon manufacturing
| expertise.
| Too wrote:
| Armchair speculation: Patents?
| adamomada wrote:
| IIRC Apple has tried/is trying, but it is ridiculously
| complex to the point that they had to go back to Qualcomm
| as there really is no other option. Read: The biggest
| tech co on the planet stumbles with this, it should be
| considered a magic box as this point.
| nolist_policy wrote:
| Google is sort of trying by using a Samsung modem
| (instead of Qualcomm) with an IOMMU in between, so at
| least the modem doesn't have access to the whole address
| space like on other phones. But they get a lot of flack
| for it.
| spxneo wrote:
| so then whats the other alternative?
|
| solder on some ESPs on an old playstation portable device
| and connect from starbucks?
| autoexec wrote:
| Right now we have no alternatives, but it's not
| technologically impossible to create mobile devices that
| give us root access to a mobile OS, or to create open
| wireless chipsets with open firmware.
| nickburns wrote:
| i'm almost certain i've had it happen on iOS, too. only
| reason i can't definitively say--is because i can't rule
| _myself_ out always having to manually toggle cell data on
| /off, both radio-level and per-app, when i'm coming/going
| from my own networks to my mobile VPN.
| spixy wrote:
| even in roaming?
| tredre3 wrote:
| Both Android and iOS will do that when you receive a MMS.
|
| Even if the MMS is supposedly on an intranet, it wouldn't
| surprise be that a poor implementation might expose the
| rest of the system to internet for a brief moment.
| hwbunny wrote:
| Just be cautious...
| sneak wrote:
| 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.
| ignoramous wrote:
| _rethinkdns dev here_
|
| > _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.
| cma wrote:
| They don't even allow disabling internet permissions on a
| flashlight app, the OS is run by an internet ad company so it
| makes sense.
| switch007 wrote:
| FWIW GrapheneOS does (it asks you before installing any app)
| codedokode wrote:
| As I understand, it installs a pseudo-VPN and passes
| traffic through it. I remember using similar app (NoRoot
| Firewall), and it worked poorly and couldn't block
| everything I wanted.
| switch007 wrote:
| GrapheneOS is totally different to having an app on stock
| android
|
| > GrapheneOS adds a Network permission toggle for
| disallowing both direct and indirect access to any of the
| available networks. The device-local network (localhost)
| is also guarded by this permission, which is important
| for preventing apps from using it to communicate between
| profiles. Unlike a firewall-based implementation, the
| Network permission toggle prevents apps from using the
| network via APIs provided by the OS or other apps in the
| same profile as long as they're marked appropriately.
|
| >The standard INTERNET permission used as the basis for
| the Network permission toggle is enhanced with a second
| layer of enforcement and proper support for
| granting/revoking it on a per-profile basis.
|
| > To avoid breaking compatibility with Android apps, the
| added permission toggle is enabled by default. However,
| the OS app installation UI has been extended to show the
| toggle as part of the installation confirmation page so
| users can disable it when installing an app.
|
| > when the Network permission is disabled, GrapheneOS
| pretends the network is down. It shows the network as
| down in various APIs, returns errors showing a network
| connectivity issue rather than a revoked permission and
| avoids running scheduled jobs depending on the network.
| This results in apps handling it as if the network is
| down rather than crashing or showing errors from trying
| to use the network and being unable to do it.
| sureglymop wrote:
| Nope. GrapheneOS is an AOSP fork (with not so many
| modifications) intended to be more secure. It doesn't do
| it in a hacky way, these apps just don't get the internet
| permission. And it lets you install Play Services as a
| normal app (not a system app) so you choose what
| permissions that gets.
| Larrikin wrote:
| Can you link to the documentation explaining how developers
| disable Internet permissions on iOS.
| loa_in_ wrote:
| Unfortunately a race to the bottom is a bad thing, not an
| excuse
| paulddraper wrote:
| Or any other operating system...
| adamomada wrote:
| Third party app firewalls exist for at least macOS and
| Linux distros. It's likely built in to the system as
| well, but you'd have to wrangle the command to do it in
| the terminal.
| lern_too_spel wrote:
| They also exist for Android, for that matter.
| Too wrote:
| Depending on how blur you draw the line of os:
|
| docker run --network none
| Dylan16807 wrote:
| For windows you go into the firewall settings and either
| set a deny rule for a specific executable or even set the
| default behavior to deny.
|
| For linux there's a couple ways of setting up a process
| group that can't access your network.
|
| I'm not very familiar with other OSes.
|
| Why do you ask? Isolation between processes can be
| difficult on non-phone operating systems, but removing
| permissions tends to be quite easy.
| chefandy wrote:
| My network security requirements have nothing to do with
| iOS. Can't we just collectively drop OS tribalism?
| izacus wrote:
| They have as much to do with iOS as the original
| commenters pet peeve has to do with the posted article.
|
| How about you all slowly wean off this utterly dumb habit
| of ranting and raving about your pet problems in
| unrelated topics?
| lambdaxyzw wrote:
| 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?
| chimeracoder wrote:
| > 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?
|
| GP is saying that the Android permissions model requires
| giving Internet access to any app you install from the Play
| Store; there isn't a way for an app to request "zero
| permissions" (or rather, there is, but basic Internet
| access is a permission granted to all apps, even when zero
| additional entitlements are requested).
|
| That said, this isn't unique to Android. At least as of a
| few years ago, iOS did more or less the same thing. (You
| can disable an app's access to the _local_ network, but
| that 's not the same thing as denying (or requiring an app
| to request) basic network connectivity).
| nickburns wrote:
| still the same. Alphabet nor Apple have any real
| incentive to change this (commercial incentivization to
| maintain it notwithstanding).
| beeboobaa3 wrote:
| Thats exactly the point that is being made, yes.
| toast0 wrote:
| Google doesn't let you deny permissions for most of them.
|
| As I understand it, apps that use the internet still need
| an entitlement, it's just that the Google Play store no
| longer shows that one in the list.
| chimeracoder wrote:
| > As I understand it, apps that use the internet still
| need an entitlement, it's just that the Google Play store
| no longer shows that one in the list.
|
| That's what it is, I think. The Play Store doesn't show
| it in the list of permissions anymore.
| beeboobaa3 wrote:
| The hypothetical flashlight app that was used as an example
| to demonstrate the problem of not being able to take away
| the permission to access the internet from an app.
| lambdaxyzw wrote:
| Thank you, I missed the point of GP clearly. I use
| GrapheneOS and forgot you can't deny network access to an
| application in a "regular" Android.
| cma wrote:
| It's just an example of an app that doesn't need internet
| access, yes flashlight is so useful it is built in to
| basically all phones now.
| talldayo wrote:
| Netguard is an open-source program that helps fix this:
| https://netguard.me/
| fifteen1506 wrote:
| GrapheneOS does if you're willing to take the plunge.
| metadat wrote:
| Take the plunge to not do any banking on your phone.
|
| It's an unfortunate limitation for a device I own to be
| handicapped this way.
| madmads wrote:
| Not universally true, I use banking apps on my Pixel
| running the latest GrapheneOS. There is literally nothing
| I cannot do on my phone. I think it's possible that no US
| banks have apps that can be used as it seems a universal
| experience among Americans.
| mkopec wrote:
| Do Android Auto and VoLTE / VoWiFi work on Graphene these
| days? I also remember Google Maps and Uber being
| extremely problematic
| sureglymop wrote:
| I think they work if you install Google Play Services (as
| a sandboxed app). What doesn't work for me is contactless
| payments with Google Pay however Google Wallet itself
| works. But I think that is actually intended and for
| security reasons.
| mbananasynergy wrote:
| Google Wallet is usable on GrapheneOS, but Google
| artificially restricts contactless payment functionality
| to Google-certified OSes.
|
| It's not a real security check that they're doing, but
| rather just checking for certification, which is very
| unfortunate.
| ajvpot wrote:
| Uber, Google Maps, VoLTE, VoWiFi, and eSIM work. You may
| need to install the sandboxed Google Play Services from
| the Apps app.
|
| Android Auto is completely disabled as an opinionated
| security measure.
|
| Google Pay and some banking apps (ones that require
| Google's Play Integrity API) will not run. GrapheneOS
| doesn't attempt to spoof these APIs because they are
| moving towards cryptographic verification [0]. Most apps
| don't require this check but if they do you are out of
| luck unless you can get the app developers to trust
| GrapheneOS's keys.
|
| [0]: https://grapheneos.org/articles/attestation-
| compatibility-gu...
| mbananasynergy wrote:
| Note that Android Auto has been supported in GrapheneOS
| for a while:
|
| https://grapheneos.org/usage#android-auto
| mbananasynergy wrote:
| Android Auto is supported on GrapheneOS:
|
| https://grapheneos.org/usage#android-auto
|
| VoLTE and VoWiFi are supported if your carrier supports
| it.
|
| Google Maps and Uber work fine, provided you install
| sandboxed Google Play.
| nickburns wrote:
| there _is_ (or at least can be) some risk tolerance
| within any so-called 'threat model.' but i absolutely
| take your point and agree with you.
|
| nary the case but i suppose if i absolutely _needed_ to
| access any finances from my mobile device, it certainly
| wouldn 't be from one of said institution's own mobile
| apps, but via web browser.
| GTP wrote:
| > i suppose if i absolutely needed to access any finances
| from my mobile device, it certainly wouldn't be from one
| of said institution's own mobile apps, but via web
| browser.
|
| I used to do home banking from my bank's website.
| Recently, they created a digital-only branch for
| customers who mostly do home banking and only rarely need
| to go in person to the bank. They asked their customers
| if they wanted to switch and offered services at the same
| or lower cost than before. I made the switch, but found
| out that unfortunately the new website lacks some
| functionalities that are only available from the mobile
| app. I guess they are assuming that most people would
| just use their phone anyway and didn't bother to reach
| feature parity between the website and the app,
| preferring the app.
| nickburns wrote:
| crazy. it's remarkable to me that lawyers actually do
| explicitly, if not expressly, account for these kinds of
| technical decisions, ultimately made in surreptitious
| fashion by the business, when drafting usage terms. i.e.,
| you would've (or, a lawyer determind, should've) been
| able to find notice of this change _somewhere_ buried in
| the new service terms. i at _least_ have faith in that
| much.
|
| i hope you switched back, lol.
| segasaturn wrote:
| Your bank doesn't have a mobile website?
| djbusby wrote:
| It does but have to use the app to deposit checks.
| neilv wrote:
| Go for a walk every day, and occasionally make your walk
| to an ATM?
|
| You can also contact your bank and tell them that you
| want to be able to deposit checks via the Web site.
|
| If enough people do this, _and don 't use the overly-
| proprietary app_, the bank might listen.
| lambdaxyzw wrote:
| >Go for a walk every day, and occasionally make your walk
| to an ATM?
|
| There are workarounds, but it sounds annoying and a
| burden. What if the closest bank branch is an hour on
| foot away? Or the OP lives in a rural place and it's half
| an hour drive? I don't have this problem since my bank
| works with graphene, but I would reconsider using it if
| most applications I use refused to load.
| NotPractical wrote:
| Minor conveniences like this are not worth the complete
| erosion of privacy, in my opinion. Just go to the nearest
| ATM to deposit checks (who uses checks anymore, btw?) and
| use the site for everything else. Not everyone even has a
| smartphone, and out of those that do, many prefer banking
| on their laptop over their phone anyway, which
| incentivizes banks to create feature-rich websites. If
| the mobile site isn't any good, usually the "desktop
| site" isn't too difficult to navigate on mobile, if you
| need to.
| nickburns wrote:
| who uses checks anymore, btw?
|
| business organizations. the rest of your points are well
| said.
| djbusby wrote:
| The nearest branch or ATM is 2+ hours driving. Desktop
| site doesn't do check deposits.
| MrDrMcCoy wrote:
| My banking apps worked for me on GrapheneOS once I
| installed Google Play services.
| codedokode wrote:
| Using banking apps on a phone is dangerous because if
| your phone gets hacked (and Linux kernel has extremely
| large attack surface), the attacker gets access to both
| the app's session and SMS codes that are used to confirm
| operations. People who use banking apps must be crazy or
| don't care about their money.
| aborsy wrote:
| Excluding phones, Linux desktop, and Windows which
| doesn't have a better record in vulnerabilities, leaves
| out essentially MacOS!
| bornfreddy wrote:
| Actually OTP hardware devices are a proper solution to
| this, but banks are mostly deprecating them,
| unfortunately.
| 1oooqooq wrote:
| and why do you think that is? *ponderingfaceemoji
|
| banks and gov sites say it's because of security, but
| accept SMS. so we know what it's really about
| xcdzvyn wrote:
| I don't. Deliberately exposing people to risk for fun?
| bornfreddy wrote:
| I think I do. It costs money and people in general don't
| appreciate it. Also while "malware on phone stealing
| money" is technically possible, it doesn't happen
| (much?), and most people get scammed in easier and more
| effective ways (see crypto) instead.
|
| I still hate it, but can't do much about it.
| sureglymop wrote:
| Can give one anecdote: I've been using Graphene for about
| a year and all banking apps work just fine. In fact, I've
| never had as little issues with any other custom rom.
| It's quite crazy just how good Graphene is.
| codethief wrote:
| I've used GrapheneOS for years and I'm doing banking on
| my phone just fine.
| CommitSyn wrote:
| The only 'banking' app I've had not work on GrapheneOS is
| Cash App, but then I just go to the website and use the
| web UI.
| lxgr wrote:
| Is android.permission.INTERNET not a thing anymore? Unlike
| iOS, Android at least used to have this one.
|
| 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!?
| adamomada wrote:
| A possible answer is it's not really a privacy setting but
| instead to save you from carrier data charges.
|
| I agree that there should be an app firewall to the point
| I'm running an older phone w the checkm8 jailbreak to have
| a firewall.
| bornfreddy wrote:
| On Android there is NetGuard which poses as a (local,
| running on the phone) VPN and allows you to deny / allow
| traffic based on process and domain. Works great, no root
| needed.
| cma wrote:
| Then you can't run another VPN right? Then raw through
| Verizon with their tracking headers and stuff for
| anything non-https unless you go through the series of
| opt outs that get periodically invalidated with a new opt
| out needed.
| jimbobthrowawy wrote:
| IIRC, there's separate permissions for web access and
| unrestricted internet access. The former is only apparent
| if you look for it on install, and isn't something you can
| disable on most ROMs.
| ThatPlayer wrote:
| On iOS it's also possible it's also possible to block Wi-fi
| data but only on iPhones sold in China:
| https://apple.stackexchange.com/a/312430
| KTibow wrote:
| I'm on OxygenOS 12 and I have the option to disable mobile
| data and/or Wi-Fi for each app, not sure if other versions
| have that though.
| codedokode wrote:
| That's what you get when you trust your device to commercial
| companies.
| yjftsjthsd-h wrote:
| That's what you get when there are no practical
| alternatives.
| CommitSyn wrote:
| Speaking of, did FairPhone get the whole "making a phone
| call" thing figured out yet?
| kernal wrote:
| That hypothetical Flashlight app, that uses location
| permission, would have never been approved in the first
| place.
|
| https://support.google.com/googleplay/android-
| developer/answ...?
| carstenhag wrote:
| This is about the continuous background location
| permission. In the past years they have cracked down on
| this, yes. But nothing forbids you from requesting the
| foreground approximate or fine location permissions.
|
| So yes, this hypothetical flashlight app can request the
| permission. The user has to allow it in some way - approx
| or precise, one-time or always. But also nowadays the users
| sees when & what app is requesting these kind of
| permissions. It's a moot point.
|
| (For background location there's an extensive form in the
| play store, you even have to send videos in many cases -
| for foreground, there's nothing)
| izacus wrote:
| Or... they can just use the builtin tile. This is such a
| bizarre offtopic theorycrafting fest based on decade old
| ideas.
| Dylan16807 wrote:
| Who said anything about location permission?
|
| Did they edit their post? I just see "They don't even allow
| disabling internet permissions on a flashlight app, the OS
| is run by an internet ad company so it makes sense."
|
| If you're implying that you need location permission to
| turn internet access into a tracking problem, you're wrong.
| infthi wrote:
| 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.
| hnburnsy wrote:
| Is that still available on recent One plus versions. I had
| that on my 5 and was appreciative.
| adamomada wrote:
| 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.
| ar-jan wrote:
| I think this finding originates with the GrapheneOS community
| [0]. Edit: I guess that may be the same user reporting both.
|
| 0: https://twitter.com/GrapheneOS/status/1782477984156311814
| strcat wrote:
| It's worth noting that the built-in VPN support doesn't have
| these leaks. We don't agree with how Mullvad is presenting this
| because it is not yet clear if the leaks with their app and
| other apps are because of bugs in these apps or the OS. Their
| own post says they've resolved part of these DNS leaks through
| changing their app to avoid not having a DNS configuration.
| Android supports many use cases of the VPN service API
| including not handling DNS and this may be a side effect of
| that flexibility. It's not necessarily a bug. If it's possible
| to set up the apps in a way that they don't leak without OS
| changes, then it was probably an app issue all along.
|
| We're aware of a separate issue unrelated to DNS leaks where
| multicast packets can leak to the local network with VPN apps.
| This appears to be an OS bug, but that's not confirmed yet. It
| will likely only be determined if it's a bug when we find a fix
| for it. This multicast leak doesn't happen with the built-in
| VPN support either.
|
| There have been plenty of VPN leaks on other platforms
| including issues that are still not really fixed without
| setting up custom netfilter or eBPF rules similar to what
| Android is trying to do on platforms where that's not done for
| you by the OS.
|
| On Android, the responsibility for preventing leaks is
| partially taken on by the OS which promotes a standard leak
| blocking feature which has gotten much better in the past few
| years. Each app trying to do this themselves is not a recipe
| for success. It's not as if Mullvad was aware of these issues
| for a long time and asking Android to fix it without action.
| exabrial wrote:
| Any system where you don't have root access in insecure by it's
| very definition. Android and ios are hilarious.
| nickburns wrote:
| 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.
|
| [0] https://en.wikipedia.org/wiki/PinePhone_Pro
| autoexec wrote:
| 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.
| nickburns wrote:
| i agree the whole concept is not too far past proof at
| present.
| fifteen1506 wrote:
| 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.
| autoexec wrote:
| 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.
| Eji1700 wrote:
| Most users click on every single download link and install
| shit they shouldn't touch.
|
| The simple problem has always been that when you're selling
| someone a $1000 piece of hardware that's supposed to "just
| work" how much do you let their ignorance fuck it all up.
|
| Now granted that's not an argument for locking away access
| from those who choose to accept the responsibility, as has
| always been the case, but the idea that there was any other
| outcome was absurd.
|
| Yes it'd be nice if everyone had some tech savvy common
| sense, but even now when we have generations growing up
| with it, actual understanding is far and few between when
| looking at the general population. People don't care, and
| don't want to, and it can make things risky.
| lyu07282 wrote:
| Well people are technological illiterates for the most
| part, but the mobile platforms are dumbed down to such a
| degree that it would be impossible for people to learn
| even if they grew up with it. It's a vicious cycle, you
| have to design these mobile platforms for infants because
| that's the only way you can keep them safe, but they will
| never learn anything about computer or network technology
| using something designed to infantilize them.
|
| The thing is, it's not that I particularly care about
| people, but it's made Android/iOS incredibly irritating
| to use, I avoid it as much as I can. It's not just that
| it wants to protect me from myself, as much as it doesn't
| let me do what I want to do, it feels like computing with
| a straightjacket on. Build a fort knox of sandboxes and
| SELinux, that's fantastic, as long as you give me the
| keys and blueprints, and for christ sake, stop pretending
| that my phone isn't a computer.
| chuckadams wrote:
| Any system that has a concept of root access is insecure by
| definition. See, I can do silly categorical statements too.
| marcosdumay wrote:
| Now you can try making true ones.
| nickburns wrote:
| categorical [?] silly
|
| ...unless you care to elaborate on why you disagree with this
| statement in substance and/or on point?
| eganist wrote:
| > categorical [?] silly
|
| In the sentence "See, I can do silly categorical statements
| too," the adjectives "silly" and "categorical" both modify
| the noun "statements" and are not themselves related to one
| another. That's why OP used both of them. If the two words
| were synonymous, only one would be required.
|
| It's fun nitpicking nitpicks.
| nickburns wrote:
| adjectives modify nouns.
|
| sure is.
| nickburns wrote:
| i see your careful edit. (i ran out of time myself.)
| they're called parts of speech. your comment makes much
| more sense now. welcome.
| Dylan16807 wrote:
| Hi please stop
| nickburns wrote:
| stop what?
| ktm5j wrote:
| Honestly I think yours makes more sense than his..
| ragnese wrote:
| I remember being chastised in some Android subreddits years ago
| for going against the (probably astroturf) opinion that having
| root access was "insecure". Sigh...
| autoexec wrote:
| 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.
| whoomp12342 wrote:
| they will never know the raw power of x86/x64 architecture
| and are limited to the mere throughput of an arm processor.
| YoshiRulz wrote:
| ISA doesn't determine speed (and not every workload is CPU-
| bound). In fact ARM, being RISC, would probably outperform
| x86 if you looked at a hardware+software stack that wasn't
| tuned for battery life above all else like Android is. For
| example, Apple Silicon Macs and Microsoft's upcoming
| Snapdragon laptops.
| switch007 wrote:
| The grapheneos devs are really, really against root. What are
| your thoughts on that?
| commoner wrote:
| Anyone who prefers root access on Android with a locked
| bootloader (on the OSes that support it) can use avbroot:
|
| https://github.com/chenxiaolong/avbroot
|
| Works great with CalyxOS and GrapheneOS.
| sureglymop wrote:
| What about OTA updates? Do they preserve it?
| strcat wrote:
| No, it's not compatible with receiving official over-the-
| air updates. Similarly to if you build and signed the OS
| properly, you'll need to make each of the updates
| yourself. Unlike building and signing the OS properly,
| you will not have the basic security model intact but
| rather will be massively rolling back security and
| trusting a huge portion of the OS with root access.
| Giving root to a massive portion of the OS destroys the
| fine grained access control and isolation model used
| throughout the OS. It makes exploitation much easier to
| do and much easier to hide. It also makes persistence a
| given since persistent root access can be given out which
| means an attacker doesn't need any verified boot bypass
| anymore. It's odd to go through all this effort to
| continue signing the OS for verified boot while losing
| the main verified boot security model which makes it
| useful.
|
| If you want root access, build and sign userdebug builds
| with ro.adb.secure=1, which is officially supported by
| GrapheneOS and only exposes root access via ADB which you
| should only use from the computer where you're building
| the OS.
|
| It would be possible to add some kind of key combination
| at boot to disable loading user installed applications,
| etc. and instead making a terminal with root access
| available. Not clear how that's really useful though.
| Instead, what these projects are doing is giving out root
| access to a massive portion of the OS in order to be able
| to give out full root access to apps. This is used as a
| shortcut to implement features in a way that massively
| reduces security even if you never use it. Implementing
| those features properly integrated into the OS following
| the principle of least privilege is the proper approach.
| Most of the features people believe they need this hack
| to achieve are doable without it, such as filtering
| traffic with your own firewall rules while also using a
| VPN which is a standard Android feature available to
| apps.
| commoner wrote:
| No, over-the-air updates are not supported. The
| instructions for flashing updates patched with avbroot
| are here:
|
| https://github.com/chenxiaolong/avbroot?tab=readme-ov-
| file#u...
| strcat wrote:
| This doesn't work with GrapheneOS but rather you can create
| a derivative of GrapheneOS without the core security model
| intact. Instead of a tiny core portion of the OS being
| trusted with root access, a massive portion of the OS is
| trusted with that. It's much easier for an application to
| compromise the OS. An attacker doesn't need exploits for
| privileged persistent compromise anymore but rather that's
| a given since the verified boot security model is no longer
| intact. The purpose of locking the bootloader is enabling
| verified boot, which is no longer intact with this
| approach. CalyxOS doesn't have a complete verified boot
| implementation for the OS like GrapheneOS and rolls back
| the standard security model a fair bit, but doing this
| rolls it back far more. You cannot have your cake and eat
| it too in this case. If you want modifications to the OS,
| you should use the official build instructions and avoid
| replacing the core of the OS with a rootkit trusting a
| massive portion of the OS to give out root access and
| trusting persistent state with root access.
| commoner wrote:
| avbroot is not officially supported by CalyxOS or
| GrapheneOS, but it does work with both OSes. The point of
| avbroot is to make root access available to trusted
| Android apps while leaving commands such as "fastboot
| flash" and "fastboot erase" disabled.
|
| There will always be a subset of users who prioritize
| functionality over security. This includes anyone who
| would root an Android device (and anyone who would use a
| desktop computer running most distributions of Linux,
| macOS, or Windows).
|
| I'll be glad to reconsider using root on Android if all
| of the functions of App Manager's "block trackers"
| feature[1] and Basic Call Recorder[2] were available on
| Android without root.
|
| [1] App Manager:
| https://github.com/MuntashirAkon/AppManager
|
| [2] BCR (Basic Call Recorder):
| https://github.com/chenxiaolong/BCR
| NotPractical wrote:
| 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].
|
| 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...
| strcat wrote:
| It's app accessible root with a massive portion of the OS
| trusted with giving out access to it that's a huge problem
| and massively rolls back OS security against compromise. It
| also means an accessibility service can trivially escalate
| to root with no way to revoke it beyond reinstalling the OS
| or doing a wipe from recovery. You also lose the main
| security properties of verified boot, which is based around
| avoiding trust in persistent state. Raising the bar for
| physical attacks is a secondary purpose of verified boot,
| not the main one.
|
| GrapheneOS already has fine-grained firewall support
| exposed to the user via the standard VPN service feature
| which despite misconceptions can be used while also using
| an actual VPN and there are multiple apps supporting this.
| It's not simply difficult to set up firewall rules where
| leaks aren't possible but rather it doesn't really work
| because not everything is done via direct socket access
| from the apps. This is why we have our Network toggle in
| the first place, which does a lot more than blocking direct
| socket access both to block indirect access and preserve
| compatibility by pretending the network is down for the
| most important APIs.
|
| These DNS leak issues which were reported to us earlier may
| be an app bug which can be worked around by the app. The OS
| could be changed to prevent this happening but that doesn't
| imply that it's an OS bug. More investigation is required
| to determine the cause and solution. We're also aware of a
| local network multicast leak that's not covered in
| Mullvad's post, which is very likely to be an Android OS
| bug but we aren't certain about that yet either. It's worth
| noting that neither the DNS leak issues or local network
| multicast leak issue impact the built-in VPN support.
| They're only happening with VPN apps. It's likely that some
| of this is caused by bugs in the Android VPN service app
| support (particularly the multicast packet leaks) but the
| DNS leaks are quite possibly an app flaw. Mullvad's post
| acknowledges they found a way to address one of the forms
| of leaks with changes to their app, which may be possible
| for the rest since there aren't leaks when the VPN is down
| but rather when it's in the process of reconnecting. It
| looks a lot like a race condition where the VPN is being
| activated before everything is in place, which could be a
| bug in the OS but could also be a bug in the app where it's
| doing something in a different order than what's intended.
| NotPractical wrote:
| > GrapheneOS already has fine-grained firewall support
| exposed to the user via the standard VPN service feature
| which despite misconceptions can be used while also using
| an actual VPN and there are multiple apps supporting
| this.
|
| Interesting, didn't know that. Maybe I should file an
| issue with the official WireGuard app asking them to
| support this. It would be nice if "multiple VPNs" was
| provided as an OS feature.
|
| > It's not simply difficult to set up firewall rules
| where leaks aren't possible but rather it doesn't really
| work because not everything is done via direct socket
| access from the apps.
|
| This only applies to rules intended for specific apps and
| not system-wide rules, no? I'd hope so, since as you said
| people are already applying system-wide (or at least
| user-wide) rules using the VPN interface.
| strcat wrote:
| > Interesting, didn't know that. Maybe I should file an
| issue with the official WireGuard app asking them to
| support this. It would be nice if "multiple VPNs" was
| provided as an OS feature.
|
| Apps have to implement it unless you mean supporting
| multi-hop WireGuard VPNs within the OS. Apps can support
| multi-hop and apps can also support doing filtering, etc.
| in addition to supporting an actual VPN. It's not
| exclusive unless the apps make it exclusive. Apps can
| also decide they want to support forwarding traffic
| through another app but they should really do that in a
| way that's secure instead of how some apps are currently
| offering this...
|
| > This only applies to rules intended for specific apps
| and not system-wide rules, no? I'd hope so, since as you
| said people are already applying system-wide (or at least
| user-wide) rules using the VPN interface.
|
| Sure, but output filtering doesn't really work well in
| general. For example, if you allow resolving any DNS
| names then you allow 2 way communication with anyone
| through your DNS resolver. The requests only go to your
| DNS resolver, but they can be for
| <data>.<random>.example.com where the name servers for
| example.com are set up to receive that data and the
| random value avoids it being served from the resolver's
| cache. The value of the DNS result can return data in the
| other direction. It's easier with a TXT record but can
| simply be an A/AAAA record too. DNS is commonly used to
| mask traffic by malware. It's not an obscure approach but
| rather very normal. Similarly, many services can be used
| as some form of proxy at least to communicate with
| arbitrary people.
|
| The main purpose of a firewall is when you're actually
| hosting services and need to filter inbound connections
| for DDoS mitigation, etc. by limiting the number of
| connections per IP or IP block, rate limiting, etc. It
| also acts as a way to prevent listening on ports you
| didn't intend to be listening on due to default-enabled
| services or services which listen on all interfaces by
| default, etc. On platforms where loopback is commonly
| used for communication, it's also a way to do access
| control based on uid, gid, SELinux context, etc. None of
| those 3 things applies much to Android. It's very rare
| for apps to use loopback for communication, although some
| do it. Hopefully they already do their own
| authentication... GrapheneOS does plan to use network
| namespaces to provide the option of per-profile or per-
| app loopback interfaces, although we could also just
| start with a toggle for access to it.
|
| Worth noting Android uses eBPF for controlling per-app
| access to the network for our Network toggle, not
| netfilter (iptables/nftables). They've gradually moved
| more and more to eBPF and away from netfilter since they
| have the resources to develop things that way.
| strcat wrote:
| 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.
| switch007 wrote:
| Always appreciate your detailed replies here. Thanks!
| whoomp12342 wrote:
| Any system exposed to the public internet is insecure by its
| very definition.
| AnarchismIsCool wrote:
| 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.
| sneak wrote:
| 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.
| lloydatkinson wrote:
| > Depending on your threat model this might mean that you should
| avoid using Android altogether for anything sensitive
|
| I once worked with someone who worked with someone that had
| previously been a major Android fanboy, but after doing some work
| that required a security clearance, they became an iPhone user
| and insisted their family get iPhones too.
| nickburns wrote:
| Apple is no less culpable of the same, they just put it behind
| the garden walls (which, in fairness, would appear to be just
| barely more trustworthy than Alphabet).
| bongodongobob wrote:
| Apple does the exact same shit. I discovered it when I first
| set up a home DNS server.
| lloydatkinson wrote:
| They switched to iPhone not for DNS reasons, but overall
| security.
| jerry1979 wrote:
| This can also be detected by using the NetGuard firewall which
| acts as a vpn. Even in full lockdown mode, some kinds of newwork
| traffic gets through.
| strcat wrote:
| NetGuard doesn't support the standard OS leak blocking like
| Mullvad and doesn't try to filter DNS so it inherently has
| leaks. There are no known remote leaks on Android 14 when a VPN
| app supporting is already active or when it's down. The DNS
| leaks in this post were partially caused by an app bug that's
| not fixed and also happen when the VPN is in the process of
| connecting. The issue with leaks when the VPN is in the process
| of connecting may be an app bug or an OS bug. It's not clear
| that it's an OS bug at this point. It was reported to us for
| GrapheneOS earlier and we've been looking into it.
|
| There's also leak issue which was reported where multicast
| packets leak outside of the VPN tunnel to the local network.
| This is highly likely to be an OS bug, unlike the DNS leak
| issue where it's not yet clear if the OS or the app is the
| problem. The OS can likely prevent those DNS leaks even if apps
| don't get fixed but it wasn't necessarily supposed to be
| responsible for it. From the OS perspective, a VPN app is
| supposed to set a DNS configuration and not setting that
| configuration results in partially using the OS DNS.
| Valery91 wrote:
| If you don't mind clarifying, currently GOS uses ASYMMETRIC
| MTE for the low overhead and to close the soft time
| constraint in ASYNC MODE. I was having a read though
| https://googleprojectzero.blogspot.com/2023/08/mte-as-
| implem... Where I had come accross possible MTE bypasses in
| ASYNC mode and I quote: 'Since SIGSEGV is a catchable signal,
| any signal handlers that can handle SIGSEGV become a critical
| attack surface for async MTE bypasses'. Moreover, "The
| concept is simple - if we can corrupt any state that would
| result in the signal handler concluding that a SIGSEGV coming
| from a tag-check failure is handled/safe, then we can
| effectively disable MTE for the process", hence having MTE as
| ineffective.
|
| Paradoxically, I don't believe this issue is faced regarding
| SYNC MODE. As you obviously know, 'in asymmetric mode, read
| memory accesses are processed as SYNC, while write memory
| accesses are processed as ASYNC'.
|
| does this mean that the signal handlers in write memory are
| exploitable?
|
| If this be true, does GOS offer a mitigation for this, or can
| it be possible to simply allow all users to have the option
| to pick SYNC MTE to bypass this attack surface?
|
| Furthermore, MTE is not enabled for the kernel, would it be
| possible to have it enabled by choice as well?
|
| Finally, regarding the OS processes to which GOS recently
| enabled MTE for as an option for its users, does it also
| include the cellular firmware, IOMMU/SMMU and the software
| stack that communicates between the isolated chip and the OS?
| I address this point because, GAL Beniamini stated that: "
| That said, up until now we've only considered the high-level
| attack surface exposed to the firmware. In effect, we were
| thinking of the Wi-Fi SoC and the application processor as
| two distinct entities which are completely isolated from one
| another. In reality, we know that nothing can be further from
| the truth. Not only are the Wi-Fi SoC and the host physically
| proximate to one another, they also share a physical
| communication interface". Nonetheless he further states: "For
| example, by going over the IOMMU bindings in the Linux
| Kernel, we can see that apparently both Qualcomm and Samsung
| have their own proprietary implementations of an SMMU (!),
| with it's own unique device-tree bindings. However,
| suspiciously, it seems that the device tree entries for the
| Broadcom Wi-Fi chip are missing these IOMMU bindings".
| Despite that the research is from a couple years, it remains
| viable evidence that IOMMU although provides adequate
| protection, it remains an insufficient mechanism on its own
| and requires further hardening on the software stack. Does
| GOS address this profound attack vector?
|
| I hope to get your perspective on the matter.
|
| Thank you in advance.
| bastard_op wrote:
| 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.
| edward28 wrote:
| Have you tried disabling "mobile data always active" in
| developer options?
| gruez wrote:
| >it'll decide to flip to cell and use those as it needs/wants
|
| Are you sure you don't have wifi assist enabled? That's
| explicitly designed to switch to cellular when wifi signal is
| poor.
| callalex wrote:
| iOS absolutely does not use Private Relay (iCloud branded VPN)
| by default. Even when it is included in a subscription, you
| must explicitly opt in.
| kccqzy wrote:
| The Limit IP Address Tracking feature is turned on by default
| and Apple makes it more annoying because it is turned on or
| off for each WiFi network.
|
| 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/io
| s/comments/uurkqr/limit_ip_addres...
| adamomada wrote:
| 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...
| rsync wrote:
| Can it be reliably configured to "fail off" ?
|
| That is, if my configuration profile Becomes invalid or is
| non-functional, Will it just cease to pass traffic?
| adamomada wrote:
| In my limited experience, when mybloxx (very rarely) has a
| problem, it blocks all network access and I have to go in
| and "reset iOS connection cache" or "reset mybloxx", two
| separate options in mybloxx that I'm unsure of what they do
| behind the curtain.
|
| I hope someone who is more knowledgeable about the
| configuration profiles can give you a definitive answer.
| threecheese wrote:
| That website ... scares me. Why are you trusting this
| product? Is there source available or some audit record?
| xvector wrote:
| This looks very sketchy. I'd recommend checking out Little
| Snitch instead.
| valianteffort wrote:
| 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.
| the8472 wrote:
| Linux has network namespaces, which can be used to isolate
| programs so they don't see any external networking when no VPN is
| available. Does android not use this for its VPN feature?
| dyingkneepad wrote:
| Lol. On the other hand, I use Linux network namespaces to make
| programs run _outside_ the VPN on a specific machine that has
| the whole system configured to go through the VPN. So yeah if
| you get namespaces you can use them to both isolate programs
| and also bypass the VPN.
| ranger_danger wrote:
| I have also noticed that when using the FoxyProxy addon under
| Firefox, even with a SOCKS5 proxy in use, it will leak DNS
| requests through the direct connection unless you also set a
| manual proxy in the regular Firefox settings as well.
| yjftsjthsd-h wrote:
| I don't suppose you can set a nonexistent manual proxy and then
| use the addon for everything?
| moose44 wrote:
| Apologies if this is a dumb question--could a service like
| NextDNS help prevent this?
| nickburns wrote:
| nope. _no_ DNS service, not even a self-hosted one, can
| mitigate what 's happening here.
|
| the matter at-hand considers Android (and iOS both) operating
| system- and kernel-level insecurities _by-design_. the
| operating system (together with all root-level or otherwise
| authorized system activity), under certain conditions--e.g.
| connectivity change, hard-coded system function, apps with
| permission to hardcode their own network functions, etc.--will
| refuse to use any NIC, whether physical or virtualized,
| _except_ the one containing the cellular carrier 's
| connection/routes. that traffic might then necessarily include
| DNS queries and any/all other private but now-leaked data.
| moose44 wrote:
| Interesting. Thank you for this.
| raggi wrote:
| NextDNS _does help_ though by way of being DoH, so while your
| packets might be traversing a less desirable path they're not
| readable.
| nickburns wrote:
| fair point. but that assumes:
|
| 1.) the system strictly respects user-configured DNS; and
|
| 2.) that the leak of _some_ private data is acceptable.
| leaked traffic is still leaked even if otherwise
| encapsulated by some other encryption mechanism outside of
| an otherwise properly-configured VPN tunnel.
|
| #1 is of course a much larger risk assumption to swallow.
| throwaway2037 wrote:
| I don't VPNs, nor Mullvad, but I do appreciate the transparency
| here. We need to support more companies like this.
| kop316 wrote:
| I've sort of suspected this the case for a while. On VPN, MMS and
| Visual Voicemail still work on Android. Both of these require
| direct mobile access or they will get rejected (sometimes they
| are only on the mobile network, or else they requests get
| rejected if they don't come from within the mobile network). I
| suspect the same is true of VoLTE. If there is a VPN, that would
| mess things up.
|
| I found this out since on Mobile Linux, if you enable VPN, the
| VPN breaks all of those.
|
| I don't think there is a clear way to fix this on Android without
| breaking a lot of expected functionalty.
| nickburns wrote:
| ironically SMS/MMS and VVS are two of _maybe_ a few other
| operations /functions (system updates maybe? _maybe_?) that are
| justifiably 'hard-coded' to the carrier connection.
|
| i've done the dance re: VVS with advanced AT&T support on
| VPN'ed iOS--so can confirm your point is not limited to
| Android.
| bestham wrote:
| No VoLTE uses a dedicated bearer (network interface) in the LTE
| stack. Not the one used for data. Different bearers can have
| different priorities/QCI (like QoS). In a congested LTE network
| VoLTE should provide a better experience than VOIP on a lower
| priority bearer.
| mise_en_place wrote:
| Luckily WireGuard doesn't have this issue on desktop peers.
| Although I did run into DNS leaking due to my peer config having
| an exception for my local network address range. The way I
| resolved that is to setup dnsmasq on the server and set that as
| my primary DNS.
|
| I will say that I wish there was a DisallowedIPs directive. It's
| fun having to subtract a /24 from 0.0.0.0/0, although there are
| calculators you can use.
| chgs wrote:
| Just have a black hole route for the subnets you don't want to
| send to
| d-z-m wrote:
| > Luckily WireGuard doesn't have this issue on desktop peers
|
| for windows split tunnels it still does, I believe.
| rkagerer wrote:
| _We have reported the issues and suggested improvements to
| Google_
|
| Isn't Android open source? Can they not fix it for them and
| submit a PR?
| nickburns wrote:
| Mullvad's not really in the business of developing for
| Alphabet. but any of us could though, sure.
| GrantMoyer wrote:
| Android is open source, but the codebase is massive and
| unapproachable. I managed to make some tweaks to Android, and
| compiled my own custom version (for one, I removed the stupid
| blur from lock screen album art), but I'm fairly confident I
| wouldn't be able to even find all the relevant code for DNS and
| VPN interactions in any reasonable amount of time.
| robertritz wrote:
| I noticed this with my Android TV. Sometimes my location would
| leak and certain streaming sites stopped working (I'm outside the
| US).
|
| Got an AppleTV and this issue stopped.
| resource_waste wrote:
| No one is going to say Apple has acceptable levels of Security.
|
| I am a bit shocked when I see politicians with iPhones, most
| are unaware that Pegasus can take over at any point.
| NotYourLawyer wrote:
| Yes, iOS is the only software with 0 days.
| eviks wrote:
| That's why it has 0 in its name!
| badrabbit wrote:
| I gave on trusting phones to secure data a long time ago. But my
| approach is, at least when on wifi, to allow access to the
| internet only if the device connects to a local vpn gateway. 100%
| leak proof and prevents almost all wifi/lan/mitm attacks.
| nickburns wrote:
| what if a system-level (read: root) process doesn't respect
| your user-configured routing table? _that 's_ the real issue
| here. only mitigation would be to _physically_ remove the
| undesirable NIC /s from the system, which is obviously
| impossible on SoC hardware.
| badrabbit wrote:
| It won't make a difference, the other end (gateway) will only
| accept vpn connections, nothing more or less. Devices that
| can't establish a connection with your wg/openvpn won't be
| able to communicate with any other device anywhere in any way
| period.
| nickburns wrote:
| we're talking here about the ability to control what NIC
| _localhost traffic_ egresses a device with multiple NICs--
| even when some of said NICs may be be virtualized, like a
| TUN interface for example. anything and everything else is
| upstream.
| Asmod4n wrote:
| 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.
| stainablesteel wrote:
| so that's what happens on when the phone is the main interface
|
| 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?
| jsheard wrote:
| 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.
| nickburns wrote:
| doesn't matter. plenty of elaboration elsewhere in the
| discussion.
| aritashion wrote:
| Doesn't rethink let you change ipv6 dns?
| bobbob1921 wrote:
| 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.
| nickburns wrote:
| 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?
|
| [0] https://en.wikipedia.org/wiki/Policy-based_routing
| autoexec wrote:
| As long as you're promoting them, have they got a good/cheap
| router with a layer 7 firewall?
|
| If only we could insert a firewall between our apps and the
| modems in our phones.
| rsync wrote:
| 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...
| justsomehnguy wrote:
| Oh, I am/was there. I have two to three phones anytime on
| me, so I can route one through the hotspot of the other.
| Still the question if the second phone route everything
| through the VPN.
|
| Edit: and GP asked specifically about Mikrotik, I think.
| They have L7 cap, but it's literally raw.
| rsync wrote:
| This type of device is referred to as a "network slug"[1] ...
| and it is a fantastic idea.
|
| 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
| Zuiii wrote:
| 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.
| aftbit wrote:
| Also apparently tethering traffic doesn't go via the VPN? That's
| a silly choice too.
| nickburns wrote:
| that's a *deliberate choice.
| marc_ranieri wrote:
| 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)
| wolverine876 wrote:
| Mullvad's security team should have found this problem on their
| own, and as soon as it appeared:
|
| Inspect security empirically - you might _think_ that your
| security must work, but that means nothing; you must investigate
| empirically: All data going to the Internet must pass through the
| gateway. Collect the packets on the gateway, not on the device,
| and inspect them for leaks. Finding leaks should be trivial at
| that point.
|
| The only trick might be cellular connections: We don't know that
| leaks aren't unique to cellular connections. I know cellular
| gateways can be setup, but are the packets inspectable at a level
| that will reveal leaks?
| kerhackernews wrote:
| Can't you just use a DNS provider that encrypts the traffic?
| spxneo wrote:
| toy with me for a bit, couldn't Mullvad be another "Encrochat" in
| the making?
|
| Encrochat was similarly marketed as absolutely trustable complete
| with experts covering "we fixed this vulnerability/exploit and
| you can trust us" vibes
| (https://www.manchestereveningnews.co.uk/news/uk-news/dads-se...)
|
| Isn't Mullvad the same thing?
|
| Do you really think they would allow terrorists like Hamas use
| Mullvad to coordinate attacks? Coincidentally, Hamas does not
| trust any sort of VPN, opting for underground land lines.
| generalizations wrote:
| > Hamas does not trust any sort of VPN, opting for underground
| land lines.
|
| I mean, duh. Like everyone always says around here, all bets
| are off when your threat model includes nation states.
|
| Timing attacks, meta data, and total access to the internet
| backbones means it's a reasonable bet that the Big Boys can
| track anything on the public internet, regardless of encryption
| or redirection. And if you're Hamas, you're probably on their
| radar.
| spxneo wrote:
| So your narrative is that they have complete access but
| choose not to act on anything they find on VPNs and other
| "privacy focused" tech?
|
| Makes sense as there has been no cases involving terrorist
| using Mullvad and such.
|
| So Mullvad is not good enough for terrorists but good enough
| for the rest? This makes no sense to me.
| pavi2410 wrote:
| What's the point for a terrorist certified VPN?
| generalizations wrote:
| What's not to understand? Nation states (read: their 3
| letter agencies) probably don't care if you're torrenting
| movies.
| throwing_away wrote:
| There's only two realistic possibilities with Mullvad:
|
| If they are a state actor, then the goal would be to use
| the intelligence only for parallel construction in the most
| severe cases like terrorism.
|
| If they are not a state actor, then the goal would be to be
| so private that if terrorists use it, nobody would ever
| know including themselves.
|
| In both cases, we see the same result as the public until
| somebody leaks.
|
| This means that you would be very unlikely to get busted
| using a state compromised VPN for torrenting movies, as
| that's typically a civil matter and would require
| additional data points for parallel construction to not
| reveal the compromised VPN.
|
| But if you are involved in terrorism, then you should
| assume the VPN is compromised in a way that will make
| digging up additional secrets about your activities trivial
| and attributable to something besides the VPN that everyone
| is fine with (like dragnet service provider data).
| anonymousab wrote:
| > but choose not to act on anything they find on VPNs and
| other "privacy focused" tech?
|
| Oh, they probably do act on it. For most things, I assume
| they use the intelligence they gather for parallel
| construction - if you know a fact about an adversary, it
| can make it easier to find other, more obvious (to that
| adversary) ways to "find" that information.
|
| I'd imagine taking direct, obvious action on information
| gleaned from front and honeypot VPN services is probably
| only done for extreme cases i.e. an active threat to the
| country/administration/agency/allies.
| maxo133 wrote:
| This is a good point. It doesn't have to be Mullvad but it's
| almost guaranteed based on what we've seen in the history (see
| CIA + swiss crypto company) that some of the major VPN
| providers are managed by intelligence agencies. Either VPN
| companies were bought via shell companies after reaching
| certain market share or they were even developed from the
| scratch.
| Remzi1993 wrote:
| Sometimes you wonder if those "bugs" are intentionally well
| placed or not. Especially since big tech has been known that they
| work together with a kinds of intelligence agencies. I just can't
| believe that so many bugs like this in Android are there "not
| intentionally" at this point since this is not the first time I
| have heard about these kinds of bugs in Android.
| sneak wrote:
| "Once is happenstance. Twice is coincidence. Three times is
| enemy action." --Ian Fleming, Goldfinger
| Rastonbury wrote:
| What if I have private dns set up on my phone?
| seany wrote:
| I really _really_ want to love mullvad, but they still don't
| ignore DMCA requests.
| chrisjj wrote:
| But why should they ignore DMCA requests?
| sneak wrote:
| APNS traffic leaks outside of the VPN on iOS as well (except
| possibly OS-supported VPNs installed with a provisioning
| profile).
|
| Apple doesn't seem to care, as they don't care about preserving
| your privacy wrt themselves.
| haisin1982 wrote:
| I like Mullvad. Just wish they used less shitty providers - all
| of them are super dodgy from xtom (super unhinged owner) to m247.
| Mullvad presents a great image but their providers would probably
| sell netflow traffic for $7 a month to any interested party. They
| really do use the scum of the earth providers instead of
| investing in their own infra
| taxesTaxi wrote:
| So, a closed source operating system can do things the user can't
| control? I don't know what's more impressive, the fact people
| don't apprehend this reality, or the fact people still rely on
| VPNs (especially a third party) for privacy or whatever.
| beefnugs wrote:
| If google wasn't evil: then the default for all permissions would
| be to mock fake data that the app could never recognize as fake.
| Then you pick and choose which apps get REAL data.
___________________________________________________________________
(page generated 2024-05-04 23:01 UTC)