cross-posted from: https://infosec.pub/post/11021006

The red padlock (at a cafe)

The captive portal of a cafe simply rendered a red padlock on with a line through it. Essentially, it was apparently telling me I am being denied access arbitrarily without using any words. There was no other screen before that. Immediately after wifi handshaking Android’s built-in captive portal detection app just went straight to a padlock. I have never been in that cafe in my life and never use my device maliciously.

Showed the screen to the staff who said “works for me on my phone”, who then noticed the airplane on my status bar and said “oh, you got the little airplane, that’s the problem”. Shit; so then I had to explain that wi-fi works in airplane mode. It was just a distraction for them. I couldn’t really convince them that the problem isn’t anything I’m doing wrong. There is no tech support for this situation -- like pretty much all captive portal scenarios. Being the customer of the customer is a very weak position to be in when the direct customer doesn’t really give a shit if it works or not.

So, has anyone seen this kind of behavior? I run into shitty broken captive portals often enough that I guess I really need to get a better understanding of them, and ways to bypass them.

TLS-encumbered captive portal (transit service)

A transit service offered wi-fi but the network forcibly redirected me to a captive portal that triggers this error:

net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH

I tried a couple browsers and tried rewriting the https:// scheme as http:// but SSL redirect was forced consistently. The error apparently implies my phone’s browser can’t do TLS 1.3.

It seems like a shitty move for a transit service to require passengers to use TLS 1.3 just to tick a fucking box that says “I agree” (to the terms no one reads anyway). Couple questions:

• I’m generally in the /protect everything by default/ school of thought. But I cannot get my head around why a captive portal where people just tap “I agree” would warrant disclosure protection that could hinder availability. In reality, I don’t really know what the captive portal at hand requests.. maybe it demands people’s phone# or email, in which case it might make sense (though I would object to them collecting that info in a GDPR region in the 1st place).

• Is there a good reason for a captive portal to require TLS 1.3? It seems either the network provider does not trust their own network, or they’re simply incompetent (assumes everyone runs the latest phones). But if I’m missing something I would like to understand it.

I still have to investigate what limitation my browser has and whether I can update this whilst being trapped on an unrooted Android 5.

Bypass methods

I guess I need to study:

• ICMP tunnel (slow, but IIUC it’s the least commonly blocked)
• SSH tunnel
• others?

Are there any decent FOSS tools that implement the client side of tunnels without needing root? I have openvpn but have not tested to see if that can circumvent captive portals. I’ve only found:

• MultiVNC - VNC over SSH
• AVNC - VNC over SSH
• ConnectBot - Can all traffic be routed over this SSH tunnel, or just a shell session?
• VX ConnectBot - same as connectBot but expanded

I’m curious if the VNC clients would work but at the same time I’m not keen to bring in the complexity of then having to find a VNC server. Running my own server at home is not an option.

My to-do list of things to tinker with so far:

• Captive Portal Controller
• ~~CaptivePortalLogin~~ (AOS 6+, and no Izzy archives on this)
• Hotspot Login

Legal options

If a supplier advertises Wi-Fi but then they render it dysfunctional by imposing arbitrary tech requirements after consumers have already bought the product/service it was included with (coffee, train/bus/plane fare, etc), then they neglect to support it, doesn’t that constitute false advertising? Guess this is out of scope for the community but I might be ½ tempted to file false advertising claims with consumer protection agencies in some cases.

And when a captive portal demands email or phone number, it would seem to be a GDPR violation. Some public libraries make wi-fi access conditional on sharing a mobile phone number which then entails an SMS verification loop.

The linked article states:

“You always have the right to a minimum 2-year guarantee if the digital content or service turns out to be faulty, not as advertised or not working as expected.”

IIUC, this means if a service is paired with software, and the API + software employs #forcedObsolescence mid-contract, they must fix or refund. Thus two example scenarios come to mind:

• If you were to pay ProtonVPN for premium service in the year leading up to June 2021 and you ran AOS 5, you would have lost service after less than an annual subscription period. ProtonVPN would have to remedy it under EU law.
• If your bank charges annual fees and they push a forced upgrade at any time that obsoletes your platform (so you cannot use the forced upgrade), the bank might be in violation of this EU consumer protection law.

Wire version 3.38.826 is apparently the last version to target Android 5. The app executes but users get a stupidly written block message:

“Important update Please install the latest version of Wire. [Download]”

Yet a piece of the app continues to function: messages that arrive are still decrypted and sent to the notifications panel. But users are only allowed to see as many words as will fit in the width of screen.

There’s a lot of incompetence and embarrassment here:

• Quite early obsolescence: AOS 5 users were sabotaged around 2019. (so AOS 5 dropped probably ~7-8 years after it was introduced)
• Security nannying. Only the user or user’s admin has knowledge of the use case and threat model. Wire cannot possibly know this. Yet they take the liberty of nannying and misplacing power.
• If there really is a serious security vuln that calls for such drastic measures as forcing people to throw away their hardware and buy a new phone, then why is it ok to process messages for the notification panel?
• The block screen does not bother to check the AOS version, so it offers users a false option that can only lead to defeat.
• #Wireapp can normally be fetched directly from wire.com so deGoogled users can reach it. But the block screen tries to force users into Google Playstore, which means the update mechanism is broken for deGoogled users.
• The app was never in an F-Droid repo, so apparently there is no archive of old versions.

Going forward:

• It’s FOSS, so if the API did not change then perhaps version 3.38.826 can be hacked to remove the offending code or even just give a fake user-agent string to the server.

• Software Conservatory should perhaps be tipped off that Wireapp should be archived. And ideally binaries too although I don’t suppose that’s in the normal scope of their role.

cross-posted from: https://slrpnk.net/post/8092448

ProtonVPN did an API bump in this version: Version 2.7.56.1 (2021-06-18) which left everyone with an Android version older than AOS 6 in the dust. So I went to the archives and grabbed the version just before that one. Ran it for the first time, configuration wizard had no issues but as soon as I tried to reach out to the server it refused to stand up a tunnel saying my version was too old. Not only did they leave permacomputing folks behind for sustaining their still-quite-functional devices, but they proactively sabotaged us from the server side.

AFAIK they made no excuses for the API bump. The usual excuse is “for security reasons”... yeah.. bullshit. Anyway, here’s the workaround:

The absolute latest openvpn app still supports AOS 5 (somewhat suggesting there is no compelling security reason to force AOS 5 users to throw away their devices). Or if you have AOS 4 you can take the openvpn version from 2 years ago. ProtonVPN distributes openvpn config profiles and the openVPN app can simply import those.

Also worth noting that F-Droid warns of anti-features on the ProtonVPN app but OpenVPN is free of anti-features. That said, I got an authentication error, but I doubt that’s related to this procedure.

update

ProtonVPN is possibly breaking EU law. If someone subscribed to service less than two years before the forced obsolescence, ProtonVPN is obligated to continue service as long as necessary to serve the consumer for 2 years.