Bypassing problematic captive portals. Cafe gave me a red padlock; transit svc has broken TLS captive portal, etc…

Submitted ⁨⁨4⁩ ⁨weeks⁩ ago⁩ by ⁨coffeeClean@infosec.pub⁩ to ⁨cybersecurity@infosec.pub⁩

The red padlock

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 without using any words. There was no other screen before that. Connect… Android sign-in 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”, who then noticed the airplane 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.

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

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 found:

I’m curious if those would work but at the same time I’m not keen to bring in the complexity of then having to find a VNC server.

My to-do list ATM: tinker with:

source

Comments

Sort:hotnew top

slazer2au@lemmy.world ⁨4⁩ ⁨weeks⁩ ago

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

Wait you are still using Lollypop? Your first priority should be to get on an android version from this decade. Lollipop came out in 2014 and went eos in 2016.

As for your liability comment. I highly doubt the vendor had any liability or or requirement to support such on old os.

source
- coffeeClean@infosec.pub ⁨4⁩ ⁨weeks⁩ ago
  
  Your first priority should be to get on an android version from this decade.
  
  My first priority is to not financially support systems of premature forced obsolescence. That would make me part of the problem. I am writing this comment from a machine that was made in 2008. My AOS 5 device still uses the original battery. Only incompetence could explain inability of /software/ to outlive a /battery/.
  
  As for your liability comment. I highly doubt the vendor had any liability or or requirement to support such on old os.
  
  Captive portals are a messy hack. You do not need a captive portal to supply Wi-Fi in the first place. The suppliers do not advertise “we have a captive portal”. They advertise “Wi-Fi”, which my oldest phone (AOS 2.3) and my Nokia n800 (pre-smartphone) supports out of the box. They still connect to wi-fi today. You might be right that a pusher of forced obsolescence by way of incompetently implemented captive portal can argue in court that their advertising has immunity to old devices, but this won’t fool engineers who know they’ve needlessly drawn an arbitrary line. If the truth-in-advertising outcome would be that their “Wi-Fi” sign has to become “Wi-Fi only for new phones”, I would be fine with that.
  
  source
x3i@kbin.social ⁨4⁩ ⁨weeks⁩ ago
Whenever you accept the TOS, your device is somehow registered/authenticated against their servers. Such a session establishment of course should be secured through TLS, just like all web traffic in general. Frankly, I see the issue here clearly on your side; you have to make sure your device supports up-to-date cryptography standards.

I saw in a different comment that you do not want to replace your phone but you definitely have to replace your software. Find an older build of lineageOS (well, probably even CyanogenMod in this case) and migrate to that. Even if it is based on Android 8, it would still be much more in line with modern security than what you are running now.
Btw, the complaint of you not being able to do banking through your browser anymore while it does not support TLS 1.3 really made me laugh, thank you!

I don't think you realize just how big the risk is that you are putting yourself in with such old software.

source
- coffeeClean@infosec.pub ⁨4⁩ ⁨weeks⁩ ago
  Btw, the complaint of you not being able to do banking through your browser anymore while it does not support TLS 1.3 really made me laugh, thank you!
  
  You’re confusing different situations. The TLS 1.3 issue has nothing to do with the bank. Desktop computers are not trapped on old software. Androids are. The bank requires customers to:
  
  buy a smartphone (because the bank’s app detects when it is running on an Android emulator)
  
  subscribe to mobile phone service (which requires showing national ID to the mobile carrier)
  
  share their mobile phone number with a power abusing surveillance capitalist who promotes the oil industry (Google / Totaal)
  
  create a Google account and agree to their terms (which includes not sharing software that was fetched from the Playstore jail)
  
  share their IMEI# with Google
  
  install proprietary non-free software and trust the security of non-reviewable code
  
  I don’t think you realize just how big the risk is that you are putting yourself in with such old software.
  
  You don’t seem to realize Android phones are designed for obsolescence and desktop PCs are not. The elimination of web access ensures users will be accessing their accounts with older software. Why would you endorse that? Not sure you realize that using an Android emulator ensures the ability to constantly run bleeding edge updated software. But the bank won’t have it. You also overestimate the security of code you cannot see to satisfy your threat model. How do you know the bank itself does not have spyware in their app? Of course they do. They want to KYC.
  
  source
baritone_edge@lemmy.ml ⁨4⁩ ⁨weeks⁩ ago
I have had issues with these portals before. I’ve never gotten s VPN to work to bypass them though and I’ve tried.

However, when I do have issues I can usually log in to the router’s home page (usually 192.186.1.1) and it will bring up the captive portal for me.

source