💾 Archived View for zaibatsu.circumlunar.space › ~solderpunk › phlog › airport-wifi-vs-opsec.txt captured on 2020-11-07 at 02:01:37.

View Raw

More Information

⬅️ Previous capture (2020-09-24)

➡️ Next capture (2023-03-20)

-=-=-=-=-=-=-

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.