For many years in the IT community, it was assumed that time spent travelling on an airplane was wasted. At best, you could make do with expensive and often-unreliable cell network coverage for connectivity. Even that was an issue, though, because of the airline's histrionic and decades-out-of-date concern that electronic devices interfered with flight navigation equipment. On top of having to pay a premium for unreliable service, you had to be sneaky about it, as well.
So when in-flight internet services first started to become integrated to major airline fleets en masse, many tech people applauded. Those of us who had to attend trade shows, travel to meet customers or were responsible for multiple data center locations could get things done as we bounced back and forth across the country. The bandwidth was every bit as expensive as roaming cell network charges, regularly more expensive, but the planes were being equipped with some basic antennae to improve reception, and you didnt need to hide your computer from overzealous flight attendants.
One of the services that made this possible was Gogo Inflight Internet. And the whole deal seemed pretty reasonable. Sure, it was expensive and the service was unreliable at best, but there were serious financial, technical and regulatory obstacles to overcome in making airplanes into giant wireless antennae. It wasn't perfect, but it wasn't a scam, either - and it was getting better.
But then one savvy Gogo Inflight Internet user noticed something troubling. The customer was Adrienne Porter Felt, a Google engineer. As Ms Felt attempted to access Youtube, she noticed that the SSL provided on behalf of Youtube was forged.
To help illustrate whats going on I've included some more detailed images below.. Note that the interfaces are a bit different because the first image was taken on a computer running Windows and the second image was taken on a Mac; the aesthetic differences aren't relevant.
In the first image's SSL certificate, we see the certificate is signed by Google Inc. and that the Common Name is listed as *.google.com (in the Subject line, the first item is the Common Name or CN).
In the second image, the Organization is listed as "Gogo" and the Common Name is a private IP address, 10.240.31.12.
This behavior is consistent with a Man in the Middle exploit. Requests for Youtube are being re-routed to 10.240.21.12, which is serving a forged SSL certificate for Youtube.
Internet Service Providers are required by awful pieces of legislation like the Telecommunications Act of 1996 to provide law enforcement with what are referred to in the Telco industry as "lawful intercepts" at the expense of the ISP. However, what is occurring here appears to be far above and beyond the normal exercise of a lawful intercept.
For one thing, lawful intercepts are targeted at specific customers. There is no indication here that the man-in-the-middle exploit being used here is executed in a targeted fashion; if targeted traffic interception was the goal, such an exploit would be a bizaare way to go about it, because all traffic would regardless be collected. Targeting using such an exploit would involve discarding traffic from non-targeted customers, as the NSA claims it does in the company of the particularly credulous.
There is another reason to believe that something untoward is afoot here. And that is a recent FCC filing in which the nudity-obsessed Federal agency blatantly declared that Gogo Inflight Internet was cooperating with law enforcement in ways not required by law. You can review that filing here:
In their own defense, Gogo has claimed that the SSL forging and the traffic interception it is designed to cover-up has nothing to do with surveillance at all. Their CTO Anand Chari had this to say:
Over the course of my career, I have had to address exactly the sort of problem that Chari claims this matter is a response to. Before I explain why Chari's response is preposterous, I should start by phrasing the problem in a way that is more understandable.
Most companies have a limited amount of bandwidth. Bandwidth, after all, is expensive. For small businesses of just a few people, its not so hard to tell that one of your workers is downloading from Pirate Bay instead of attending to his work, and in the process ensuring that no one can so much as check their email. But what if there are 500 workers? And what if the bandwidth use isnt intentional; what if its being caused by malware? Thats when a more technical response is called for.
This is a problem that has existed in commercial IT for decades; its a problem that predates streaming media, it predates the world wide web for that matter. Because the problem is so old, there are dozens of different approaches to resolving it, depending upon what kinds of resources are available and the overall structure of the network in which the problem is being addressed.
One of the many solutions to this kind of issue would be to implement a technology called Quality of Service. In a nutshell (this is a very simplified explanation), Quality of Service enables network administrators to give a priority to certain types of traffic over others. This function is extremely useful, if we think about it for a moment. Consider email and video streaming, for a moment. When you send and receive email, its not such a big deal if it takes a few extra seconds for the email to be transferred. If there is an extraordinarily long delay of many minutes, it can become annoying. But a delay of seconds is not noticeable to a user, and email applications are designed (when correctly configured) to deal with delays so that they aren't a problem. Now take streaming video. If you introduce a few seconds delay as a user is watching a video, such a delay would completely spoil the experience. If the delay is long enough, it will even crash the video player software. So we have established that delays are more important to video than email.
So let's imagine another circumstance. We are in a real world environment - an office, with a limited amount of bandwidth. One employee is playing a video, and another employee attempts to send an email with a large attachment. There is enough bandwidth for only one of these operations, but not both. What do we do?
By implementing QoS, we can give the video a higher priority than email; allowing the video to finish playing before sending the email. This ensures that both users have a good network experience, and no errors are introduced into the application layer. We can introduce QoS in such a way that we do not have to break encrypted services, as Gogo has done. Certain protocols can be prioritized, but we can also prioritize users and connections, accounting for a limited amount of bandwidth.
Not only would such a solution ensure the privacy of users, but it also tends to be faster and more reliable when scaling large amounts of traffic than what Gogo claims they are doing - which involves more than just routing and switching network "packets". Information sent over a network is divided into small packets that share certain standardized properties. This standardization allows for the packets to be handled consistently and reliably, even when the information iinside of the packets is unique. Handling packets as they travel is, in most circumstances, less resource-intensive than opening the packets up and dealing with the stuff inside of them. Consider the difference between your home wireless router, which handles the standardized packets in transit, and your home computer, which deals with the unique information inside of packets.
The gist of the story is this - information you send while using Gogo Inflight Internet is almost certainly being snooped on; its also possible, though not yet proven, that other similar services are also snooping. Do not trust SSL connections that are provided to you by Gogo; to avoid their snooping, VPN connections could help, but further research is needed to determine which VPN solutions can be compromised by Gogo's setup.
ht to read/write
 |
| Some of us handled the situation better than others |
One of the services that made this possible was Gogo Inflight Internet. And the whole deal seemed pretty reasonable. Sure, it was expensive and the service was unreliable at best, but there were serious financial, technical and regulatory obstacles to overcome in making airplanes into giant wireless antennae. It wasn't perfect, but it wasn't a scam, either - and it was getting better.
But then one savvy Gogo Inflight Internet user noticed something troubling. The customer was Adrienne Porter Felt, a Google engineer. As Ms Felt attempted to access Youtube, she noticed that the SSL provided on behalf of Youtube was forged.
hey @Gogo, why are you issuing *.google.com certificates on your planes? pic.twitter.com/UmpIQ2pDaU
— Adrienne Porter Felt (@__apf__) January 2, 2015
To help illustrate whats going on I've included some more detailed images below.. Note that the interfaces are a bit different because the first image was taken on a computer running Windows and the second image was taken on a Mac; the aesthetic differences aren't relevant.
In the first image's SSL certificate, we see the certificate is signed by Google Inc. and that the Common Name is listed as *.google.com (in the Subject line, the first item is the Common Name or CN).
In the second image, the Organization is listed as "Gogo" and the Common Name is a private IP address, 10.240.31.12.
This behavior is consistent with a Man in the Middle exploit. Requests for Youtube are being re-routed to 10.240.21.12, which is serving a forged SSL certificate for Youtube.
 |
| This is what a Youtube SSL certificate normally looks like |
 |
| This is what the Youtube SSL certificate looked like as provided to Ms Felt by Gogo Internet |
Internet Service Providers are required by awful pieces of legislation like the Telecommunications Act of 1996 to provide law enforcement with what are referred to in the Telco industry as "lawful intercepts" at the expense of the ISP. However, what is occurring here appears to be far above and beyond the normal exercise of a lawful intercept.
For one thing, lawful intercepts are targeted at specific customers. There is no indication here that the man-in-the-middle exploit being used here is executed in a targeted fashion; if targeted traffic interception was the goal, such an exploit would be a bizaare way to go about it, because all traffic would regardless be collected. Targeting using such an exploit would involve discarding traffic from non-targeted customers, as the NSA claims it does in the company of the particularly credulous.
There is another reason to believe that something untoward is afoot here. And that is a recent FCC filing in which the nudity-obsessed Federal agency blatantly declared that Gogo Inflight Internet was cooperating with law enforcement in ways not required by law. You can review that filing here:
In their own defense, Gogo has claimed that the SSL forging and the traffic interception it is designed to cover-up has nothing to do with surveillance at all. Their CTO Anand Chari had this to say:
Whatever technique we use to shape bandwidth, it impacts only some secure video streaming sites and does not affect general secure internet traffic. These techniques are used to assure that everyone who wants to access the Internet on a Gogo equipped plane will have a consistent browsing experience… We can assure customers that no user information is being collected when any of these techniques are being used.Chari's excuse sounds quite reasonable to those with no experience with networking and system administration. To those that are familiar with solving bandwidth restricition delimmas, Chari's explanation is, at best, the ramblings of a man who is completely incompetent and, at worst, an outright lie.
Over the course of my career, I have had to address exactly the sort of problem that Chari claims this matter is a response to. Before I explain why Chari's response is preposterous, I should start by phrasing the problem in a way that is more understandable.
Most companies have a limited amount of bandwidth. Bandwidth, after all, is expensive. For small businesses of just a few people, its not so hard to tell that one of your workers is downloading from Pirate Bay instead of attending to his work, and in the process ensuring that no one can so much as check their email. But what if there are 500 workers? And what if the bandwidth use isnt intentional; what if its being caused by malware? Thats when a more technical response is called for.
This is a problem that has existed in commercial IT for decades; its a problem that predates streaming media, it predates the world wide web for that matter. Because the problem is so old, there are dozens of different approaches to resolving it, depending upon what kinds of resources are available and the overall structure of the network in which the problem is being addressed.
One of the many solutions to this kind of issue would be to implement a technology called Quality of Service. In a nutshell (this is a very simplified explanation), Quality of Service enables network administrators to give a priority to certain types of traffic over others. This function is extremely useful, if we think about it for a moment. Consider email and video streaming, for a moment. When you send and receive email, its not such a big deal if it takes a few extra seconds for the email to be transferred. If there is an extraordinarily long delay of many minutes, it can become annoying. But a delay of seconds is not noticeable to a user, and email applications are designed (when correctly configured) to deal with delays so that they aren't a problem. Now take streaming video. If you introduce a few seconds delay as a user is watching a video, such a delay would completely spoil the experience. If the delay is long enough, it will even crash the video player software. So we have established that delays are more important to video than email.
So let's imagine another circumstance. We are in a real world environment - an office, with a limited amount of bandwidth. One employee is playing a video, and another employee attempts to send an email with a large attachment. There is enough bandwidth for only one of these operations, but not both. What do we do?
By implementing QoS, we can give the video a higher priority than email; allowing the video to finish playing before sending the email. This ensures that both users have a good network experience, and no errors are introduced into the application layer. We can introduce QoS in such a way that we do not have to break encrypted services, as Gogo has done. Certain protocols can be prioritized, but we can also prioritize users and connections, accounting for a limited amount of bandwidth.
Not only would such a solution ensure the privacy of users, but it also tends to be faster and more reliable when scaling large amounts of traffic than what Gogo claims they are doing - which involves more than just routing and switching network "packets". Information sent over a network is divided into small packets that share certain standardized properties. This standardization allows for the packets to be handled consistently and reliably, even when the information iinside of the packets is unique. Handling packets as they travel is, in most circumstances, less resource-intensive than opening the packets up and dealing with the stuff inside of them. Consider the difference between your home wireless router, which handles the standardized packets in transit, and your home computer, which deals with the unique information inside of packets.
The gist of the story is this - information you send while using Gogo Inflight Internet is almost certainly being snooped on; its also possible, though not yet proven, that other similar services are also snooping. Do not trust SSL connections that are provided to you by Gogo; to avoid their snooping, VPN connections could help, but further research is needed to determine which VPN solutions can be compromised by Gogo's setup.
ht to read/write