[NoahZuniga]

I'm not following the reasoning here:

> 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

[avidiax]

It could be that they allow any HTTP/HTTPS request that has

  Host: acwifi.com

regardless of whether the IP address destination of the request is valid for acwifi.com.

You see these sorts of shenanigans being used to get around country-wide firewalls. Plenty of deep packet inspection is unable to handle edge cases like the "Host:" header being misleading, having it fragmented into two TCP packets, etc. See "domain fronting".

[mixdup]

it's extremely unlikely that the plane wifi would be configured that way. trying to use a host file to make github.com respond on acwifi.com was definitely a red herring. It led to figuring out 53 was open, but was definitely not how the filtering was working

[NoahZuniga]

Also, this doesn't resolved the non sequitur in the OP. It claims there might be DNS blocking, not deep packet inspection. Also cloudflare has encrypted client hello turned on by default and the only domain that shows up for https connections in this case is cloudflare-ech.com, so if any Cloudflare website is whitelisted it would have to allow this domain, and consequently any other Cloudflare website.