Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A story about bypassing air Canada's in-flight network restrictions

ramsayleung.github.io

Post reply on HN
Print view View original

131–140 of 169 posts

Re: A story about bypassing air Canada's in-flight network restrictions

#131

Post by brailsafe »

hluska wrote: post #107
eps wrote: post #22

Earlier quoted context omitted.

> breaking the law Not law per se. More like contractual obligations taken upon by connecting to the flight's WiFi.

This is theft. Stealing is illegal. Giving a blueprint for how you stole is the icing on the prosecutorial cake because you can’t claim lack of knowledge if you create a conspiracy to enable the theft. This may be the dumbest write up I have ever read.

The nature of the non-transaction was such that they were given access to a service that was constrained in certain ways. They used the service, and the constraints that AC technically applied still applied. They used what was available to them under the constraints and weren't required to pay for any other service but the removal of the constraints. I don't see how any theft occurred.

Likewise illegality is just a boring and simple way to dismiss someone on moral grounds, but laws are only as effective as the level of agreement people have with them. Drinking in the park is technically illegal, but I don't care, the police don't care, nobody cares, unless someone needs to care, and I'm going to do it anyway, because the law does not make drinking in the park inherently wrong, it just provides a framework for telling you to stop if you're interfering with others in a way that relates to alcohol consumption.

Re: A story about bypassing air Canada's in-flight network restrictions

#132

Post by kulahan »

EvanAnderson wrote: post #39
ajd555 wrote: post #10

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.

I find it's important to remember, too, that a failed PING tells you nothing other than your echo request did not receive a response. If the remote host received your request, and if it responded, are both things a failed PING can't tell you, because both of those things could be true but you still end up with a failed PING. I've seen technicians get tripped up in troubleshooting thinking that a failed PING tells the…

I've always assumed that in situations like this, a traceroute is better. You can get more information simply by reaching the next stage in the trace, even if you're given zero information beyond "I'm now at the next server".

Re: A story about bypassing air Canada's in-flight network restrictions

#133

Post by joshheyse »

I’m guessing the speeds were slow because QOS was limiting the slowed for what was speed to be a chat only connection.

What not just spoof the MAC address of “machine” that has paid.

I had written a utility that monitors MAC address on the network and tries them each until it finds on that is allowed.

Looks like someone released an app to do just that.

https://github.com/t-mullen/wififox

Re: A story about bypassing air Canada's in-flight network restrictions

#134

Post by jacquesm »

dylan604 wrote: post #121
jacquesm wrote: post #96

Earlier quoted context omitted.

Wow. That's a classic. We were quite motivated because we were the ones that got the automated alerts. I still see them in my nightmares: "chopper is down". The machine was called chopper, I'll never forget, it's been close to 30 years. My buddy Jasper and me spent multiple nights trying to track it and when we finally found it we still couldn't believe that that was it. But a simple swap was proof.

Did someone yell for you to "Get to the choppa! Do it! Now!!"?? Please say that's not been wasted!

I think we were past the point of humor during that particular episode but there was a reason it was named like it was.

Re: A story about bypassing air Canada's in-flight network restrictions

#135

Post by dylan604 »

jacquesm wrote: post #134
dylan604 wrote: post #121

Earlier quoted context omitted.

Did someone yell for you to "Get to the choppa! Do it! Now!!"?? Please say that's not been wasted!

I think we were past the point of humor during that particular episode but there was a reason it was named like it was.

if it wasn't an Arnie reference, could it have been a Stand By Me reference, "Chopper, sick balls"? or Eric Bana's Chopper: "if you keep stabbing me, I'm gonna die"?

clearly, i'm the type where everything is a movie reference, or it's a missed opportunity

Re: A story about bypassing air Canada's in-flight network restrictions

#136

Post by zem »

ballenf wrote: post #68
Aurornis wrote: post #65

Earlier quoted context omitted.

Most countries will have laws covering cases of unauthorized access, theft of services, and computer misuse. The user agreement helps define the service as a paid service with defined access cases. Going around those would put the user in violation of some laws. An analogy would be showing up to a paid event venue and noticing a back door was left open. Going into the building without paying is not okay, even though…

If the user routed all traffic through a WeChat or other messaging service, they would just be using messaging.

I would have had far more positive feelings towards the hack if they had done that - e.g. had their roommate configure a bot to monitor a wechat room and respond to url requests by sending back a webpage. tunneling over DNS feels icky because the reason DNS traffic goes into a separate accounting pool is so that the basic infrastructure of the internet can be kept working smoothly, so this is getting firmly into tragedy of the commons territory.

Re: A story about bypassing air Canada's in-flight network restrictions

#137

Post by thwarted »

cmehdy wrote: post #127
ceejayoz wrote: post #63

Earlier quoted context omitted.

> It is one of the weirdest IT problems I've ever encountered and it makes me wonder how much of what we rely on is actually marginal. Vernor Vinge had a character who was a "Programmer-Archeologist" on a relativistic starship. Feels more and more prescient as time goes on.

I work at a company that invented an internal syntax to compile into C++ code, that still relies on c-shell and conventions taken when OS/2 was in use there, and with a web of Jenkins instances and homemade wrappers and DBs to build that stuff. I can safely say that title exists already. And I value my current experience as a humbling example of what is to come as software becomes an older industry, and not just a wo…

The way you describe this system is exactly how I'd describe a system I worked on in the early 90s at PW (before it was PWC).

Re: A story about bypassing air Canada's in-flight network restrictions

#138

Post by barbs »

Can someone please explain what project X/Xray is? Judging from the context I imagine it's some sort of proxying software but I can't seem to find out more. The website and github seem to be littered with vague jargon or is in Chinese and Googling brings up something called XTLS?

Re: A story about bypassing air Canada's in-flight network restrictions

#139

Post by avidiax »

NoahZuniga wrote: post #109

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 we…

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".

Re: A story about bypassing air Canada's in-flight network restrictions

#140

Post by pstuart »

kulahan wrote: post #132
EvanAnderson wrote: post #39

Earlier quoted context omitted.

I find it's important to remember, too, that a failed PING tells you nothing other than your echo request did not receive a response. If the remote host received your request, and if it responded, are both things a failed PING can't tell you, because both of those things could be true but you still end up with a failed PING. I've seen technicians get tripped up in troubleshooting thinking that a failed PING tells the…

I've always assumed that in situations like this, a traceroute is better. You can get more information simply by reaching the next stage in the trace, even if you're given zero information beyond "I'm now at the next server".

Traceroute uses ICMP and can encounter the same problem ping does.

This has come in handy instead -- https://linux.die.net/man/1/tcptraceroute

Disclaimer: not a network engineer but dependent on packets going from A to B.

Post reply on HN