> We affirm our strict adherence to all relevant regulations and service terms throughout this project.
Except if you bypassed payment and used the service in a manner that was not intended, most likely you were by definition not undertaking "strict adherance" to service terms ?
> The only downside was that although we broke through the network restrictions and could access any website, the plane’s bandwidth was extremely limited, making web browsing quite painful.
Unfortunately this is also the downside of paying. Many times I have paid for internet, only to find it unusably bad. To be fair, I just flew a transcontinental flight on Air Canada the other day and the wifi was fine.
Limiting availability of third party services based on local service provider fee can only be done 100% reliably on a service side through an agreement with that provider, i.e. WhatsApp needs to disable certain functions to users coming from certain dedicated links or IP ranges, or even based on live user status metadata. There's an obvious size mismatch, and lack of incentive to implement compartmentalisation only needed for some other company. It also creates enormous shared responsibility and potential circular finger pointing clown shows, all for relatively tiny number of affected paying users.
Therefore, it is either done with least amount of work that is “good enough”, and can be done on a cheapest router (rate limit to the absolute minimum, ban connections to ports 80 and 443, maybe cut the traffic to most stable IP ranges of biggest services, and regular person is going to state that “nothing else works”), or trough very extensive commercial DPI with lots of guessing and ad-hoc rules (if this feature is important for the income, and many will try to game the system). So it's either going to be as simple as in this example, or you'll compete with the global army of detection rule authors.
Though I do like the wink-wink, nudge-nudge choice of proxy software.
If a ping to a specific IP times out, I wouldn't say the IP is blocked. It could be that ICMP specifically is blocked, following some network rules on the firewall. This is pretty common in entreprise networks to not allow endpoint discovery. I could be missing something and happy to be corrected here, but I was surprised to read that.
"All new is something already known, but well forgotten."
Escaping locked down networks by tunneling things over DNS is one of these things. We've used it back in 00's to get out of restrictive hotel networks. Not even WiFi, but the actual wired Ethernet ones.
tl;dr: The firewall on the plane allows any traffic to pass on port 53 (to allow for DNS queries) but doesn't do any state inspection or rate limiting so you can do whatever you want on it.
> My roommate spent about an hour setting up a proxy server exposing port 53 using xray 1, and sent me the configuration via WeChat:
An hour!? As opposed to just spinning up an sshd on that port and coming in using ssh -D to establish a local socks proxy?
On some networks, yes: I used to use a prepay mobile network (= buy a fixed quantity of GBs in advance, use them, once you run out, you get a restricted captive portal where you can buy more, just like on this flight). But all traffic on port 53 was allowed, it didn't need to be actual DNS traffic.
There's even some commercial VPN providers which offer openVPN on port 53.
If they had a ssh server on the remote machine they could have also done something like `ssh -g -ND 53 root@localhost` from the remote machine, which would have exposed a remote-accessible SOCKS proxy on port 53.
> Here we exploited a simple cognitive bias: not all services using port 53 are DNS query requests.
Eh, I don’t think this is a result of cognitive bias. I’m sure the people involved in creating whatever hardware or software is running the network know that you can run other stuff on ports. More likely the extra effort involved in inspecting packets was not deemed worth the risk, a decision either made by the manufacturer of the hardware/software, or someone on Air Canada‘s IT team.
If you had a window seat you could make bank with a starlink mini and undercut the Air Canada by a small amount, like $40 Canadian. Just use pfSense Captive Portal and make sure you forward any port 53 or 853 to the external interface to the local DNS.
Could y'all point at instructions for how to imitate this limited internet situation ?
I ask because, two years ago, I was able to circumvent the Windows-11-requires-internet-and-a-microsoft-account part of the set up for a new laptop computer by doing this on a flight. Apparently, connecting to the airplane wifi (without yet logging in) was enough to satisfy the OS set-up, but limited enough that my laptop didn't require a microsoft account. With windows 10 now end of life, I will probably get a new desktop computer and would like to repeat the feat at home. Thanks
I have done similar things on several long flights.
Very often, there is at least one large cloud provider or CDN (e.g. Microsoft/Azure or Amazon/AWS or Google/GCP) that is whitelisted by the in-flight Internet gateway so that it can serve static pages, and I
can get access to all the sites hosted by that provider simply by using domain fronting (which the author of this post describes as "disguise domain":
https://ramsayleung.github.io/en/post/2025/a_story_about_byp...)
Another option would be to setup a wireguard server listening on 53. Wireguard traffic is UDP so it would work even if TCP DNS requests are blocked. And it would also make the client configuration much easier, ie just connect to the wireguard server.
> Since acwifi.com is accessible but github.com is not, is it possible that the network has imposed restrictions on the DNS server, only resolving domain names within a whitelist (such as instant messaging domains)?
> If this is the case, can I modify /etc/hosts to disguise my server as acwifi.com, so that all request traffic passes through my server before reaching the target website (github.com)?
But by putting the host in /etc/hosts, you're skipping asking the planes DNS server, so how are you "disguising" an external server? And why go through the effort of proxying through acwifi.com instead of going straight to the example of github.com
Lesson for implementers: block all DNS requests from customers unless they are addressed to a onboard DNS cache (whose IP address is supplied by the DHCP response).
Planes that use the Panasonic system allow access to the full *.paypal.com domain to allow the paywall to work. If there is a way to somehow proxy all your traffic though something under paypal.com you could get free wifi on certain flight. Or you can pass the time away reading all the paypal API documentation.
34 comments
[ 4.7 ms ] story [ 35.7 ms ] threadExcept if you bypassed payment and used the service in a manner that was not intended, most likely you were by definition not undertaking "strict adherance" to service terms ?
Wake me up the first time someone gets into legitimate trouble over a little harmless computer fun like this. Until then..who cares?
Unfortunately this is also the downside of paying. Many times I have paid for internet, only to find it unusably bad. To be fair, I just flew a transcontinental flight on Air Canada the other day and the wifi was fine.
Therefore, it is either done with least amount of work that is “good enough”, and can be done on a cheapest router (rate limit to the absolute minimum, ban connections to ports 80 and 443, maybe cut the traffic to most stable IP ranges of biggest services, and regular person is going to state that “nothing else works”), or trough very extensive commercial DPI with lots of guessing and ad-hoc rules (if this feature is important for the income, and many will try to game the system). So it's either going to be as simple as in this example, or you'll compete with the global army of detection rule authors.
Though I do like the wink-wink, nudge-nudge choice of proxy software.
Escaping locked down networks by tunneling things over DNS is one of these things. We've used it back in 00's to get out of restrictive hotel networks. Not even WiFi, but the actual wired Ethernet ones.
> My roommate spent about an hour setting up a proxy server exposing port 53 using xray 1, and sent me the configuration via WeChat:
An hour!? As opposed to just spinning up an sshd on that port and coming in using ssh -D to establish a local socks proxy?
There's even some commercial VPN providers which offer openVPN on port 53.
Eh, I don’t think this is a result of cognitive bias. I’m sure the people involved in creating whatever hardware or software is running the network know that you can run other stuff on ports. More likely the extra effort involved in inspecting packets was not deemed worth the risk, a decision either made by the manufacturer of the hardware/software, or someone on Air Canada‘s IT team.
I ask because, two years ago, I was able to circumvent the Windows-11-requires-internet-and-a-microsoft-account part of the set up for a new laptop computer by doing this on a flight. Apparently, connecting to the airplane wifi (without yet logging in) was enough to satisfy the OS set-up, but limited enough that my laptop didn't require a microsoft account. With windows 10 now end of life, I will probably get a new desktop computer and would like to repeat the feat at home. Thanks
I have done similar things on several long flights.
Very often, there is at least one large cloud provider or CDN (e.g. Microsoft/Azure or Amazon/AWS or Google/GCP) that is whitelisted by the in-flight Internet gateway so that it can serve static pages, and I can get access to all the sites hosted by that provider simply by using domain fronting (which the author of this post describes as "disguise domain": https://ramsayleung.github.io/en/post/2025/a_story_about_byp...)
> Since acwifi.com is accessible but github.com is not, is it possible that the network has imposed restrictions on the DNS server, only resolving domain names within a whitelist (such as instant messaging domains)?
> If this is the case, can I modify /etc/hosts to disguise my server as acwifi.com, so that all request traffic passes through my server before reaching the target website (github.com)?
But by putting the host in /etc/hosts, you're skipping asking the planes DNS server, so how are you "disguising" an external server? And why go through the effort of proxying through acwifi.com instead of going straight to the example of github.com