Airport WiFI vs OpSec


First phlog from Suomi!

On the one hand, it's great that almost every airport on Earth now has free

WiFi, which can make long layovers somewhat less awful. On the other hand, I've

always found actually using the WiFi at airports to be stressful and

problematic. The procedure is no doubt optimised to work as quickly and easily

as possible for the average user, but if you're somebody who puts some effort

into maintaining online privacy or reducing your dependence upon untrusted third

parties, things fall apart incredibly quickly.

Airport WiFi (and sometimes hotel WiFi) is usually based around some kind of log

in portal, which intercepts your first HTTP request and redirects you to a

page where you have to agree to Terms of Service, provide a WiFi voucher code,

or something like that. I have the EFF's "HTTPS Everwhere" extension installed

in Firefox, which means that there is a high probability that the first HTTP

request is in fact an HTTPS request. Some WiFi portals respond to this by

attempting a MITM attack (which browsers are making it increasingly difficult to

click past). Others simply terminate the connection, leaving you at a browser

error page rather than the login page.

So, you disable HTTPS everywhere and hopefully remember to re-enable it later.

Then your request gets redirected to some login URL, but this usually is at some

non-public subdomain of the airport's website which is only served up by the

airport's own DNS server. If you let your DHCP client overwrite your

/etc/resolv.conf when you connected, this is fine. But if you're careful about

who you make DNS requests to have your /etc/resolv.conf file immutable and

always pointing at, say, a locally running caching server on 127.0.0.1 or a list

of public servers from the OpenNIC Project, then you probably once again end up

at a browser error page.

So, you make your /etc/resolv.conf mutable, and either disconnect from the wifi

and reconnect to find out the airport's DNS servers IP, or if you've been there

before you do a quick cp /etc/resolv.conf.changi /etc/resolv.conf and hope the

network setup has not changed.

Now you can load the login page and agree to the terms or whatever. You're

online! Naturally you immediately want to connect to a VPN so the airport can't

snoop on your browsing, especially if you're at Changi who only hand over a WiFi

coupon code after you give them a phone number (no fake number, because they

text the code to you) or let them scan your passport, which means your internet

session is trivially linked to your real world identity. But now you're trying

to send your DNS requests to the airport's private DNS server from a VPN exit

point on the public intenet, which doesn't work, so now you're once again

getting name lookup failure error pages for everything.

So you change your /etc/resolv.conf back to what it was before, and make it

immutable again immediately after, because otherwise the DHCP client will, for

some reason, periodically clobber it.

Then you get in 5 or 10 minutes of blissful secure internet usage before your

connectin to the heavily overloaded WiFI network drops out and you have to go

through the entire rigmarole again from the top, and all this while tired after

a long flight and grumpy because the security people made you take off the exact

same boots that they didn't make you take off the last time you flew through the

exact same airport.

Proxy Information
Original URL
gemini://zaibatsu.circumlunar.space/~solderpunk/phlog/airport-wifi-vs-opsec.txt
Status Code
Success (20)
Meta
text/plain; charset=utf-8
Capsule Response Time
404.787162 milliseconds
Gemini-to-HTML Time
0.594875 milliseconds

This content has been proxied by September (ba2dc).