💾 Archived View for zaibatsu.circumlunar.space › ~solderpunk › phlog › airport-wifi-vs-opsec.txt captured on 2020-09-24 at 01:53:21.
-=-=-=-=-=-=-
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.