I posted this on insecure WIFI from 39,000 ft altitude
I posted this on insecure WIFI from 39,000 ft altitude
This post was sent from a 39,000 ft altitude on an Emirates Airbus A380–800 (quad-jet) while flying back from Bahrain to Los Angelos. I connected to the onAir insecure WIFI which means all L2 frames are sent in plaintext. My iPhone got the private IP 172.19.128.53 from the DHCP server access point gateway 172.19.128.1. The subnet mask is /22 (255.255.252.0) which gives this aircraft an IPv4 address range for hosts of 2¹⁰ (1024 hosts). This means no more than 1024 devices (well, 1022 removing the broadcast and zero address until this RFC get approved) can be connected to this access point on the aircraft. This should be enough for the number of passengers on an A380.
I opened
https://substack.com
to write this story. A DNS query is sent to find substack.com IP address to the default resolver which is the access point on a UDP datagram in plaintext (DoH isn’t enabled). Next I establish a TCP connection to the IP address where substack.com resolved to. After that I create a TLS session which encrypts the communication. Up until this point the access point and frankly anyone with network sniffer on that aircraft could read all my frames so far because the WIFI isn’t encrypted. However frames that are sent after the TLS session is established won’t be readable to sniffers or Emirates access point and this include this post. The access point knows I’m sending something to Substack from the IP and domain name but they don’t to get to see what it is.
What can the access point admin of onAir network see?
ports, so it can allow certain messaging features and disable other. That is how they can allow whatsapp messaging but disable web browser on the free WIFI package. Whatsapp uses different port for each service.
IP addresses
Domain names through DNS, so it can block or throttle Traffic. This is why when I enabled my VPN on their WIFI I got no throttling browsing YouTube. If encrypted DNS is used, the access point can still get the domain from TLS SNI extension. Encrypted client hello should hide that.
MAC addresses, they can use this to track me across different WIFI, but thankfully my iPhone can generate a private MAC for each WIFI.
All HTTP (unencrypted traffic)
Insecure WIFI are not as scary as they used to be 10 years ago. With the abundance of HTTPs and private MAC addresses, we can rest assure we are safe. Can the access point terminate TLS and serve me a wild card certificate for the domain I’m visiting? Sure, but my device will reject it, because whoever signed that certificate won’t be trusted. Unless my phone was explicitly configured to trust a shady ROOT cert. hmmm I got to be careful not hand my phone away.
Learn more about the fundamentals of network engineering, grab my udemy course
https://network.husseinnasser.com
