Ars Technica mentioned in a post that GoGo, the primary “airplane Internet Access provider” is breaking HTTPS security with a fake certificate in order to prevent access to YouTube over HTTPS when using GoGo to access the Internet. Many are already pointing out that this damages all of Internet security by playing on a known security “hole” in HTTPS deployment (not in the actual protocol itself).
I have a very strong reaction to this for two reasons: a) because most individuals believe that all content on the Internet must not be the subject of Surveillance by Internet Access Providers, and b) because GoGo’s “rationale” for solving their problem in this way is false. It’s not the only way to solve their problem, and in fact it is not even the best known way. The best known and tested way to deal with their underlying business problem doesn’t require content-type detection at all!
Fixing the surveillance problem
This story highlights a known weakness of the “https” design that most non-security people don’t understand. That is alluded to briefly in passing, but to be more specific – https security is “one way” – the destination you reach can decrypt the message, so your browser must tell you reliably whether the destination is the site you talk to. If that destination is pretending, your security is thin.
The thin reed your security depends on has two parts:
I point these out because the news stories (including the Ars Technica one) almost never highlight these weaknesses, which have been known for years, and which have been under attack for years by bad guys, so they should be fixed, which would leave GoGo looking for a less intrusive solution, anyway. A commercial company depending on a security hole is bad practice, at the very least.
So for one thing – we desperately need a better solution for browser-to-service integrity than HTTPS. The problem is not the encryption but the terrible weakness of the certificate-based authentication. (and DNSSEC doesn’t fix this… though it fixes another hole in HTTPS). Good solutions are known, but there is a hurdle to be overcome, and the hurdle is high because users and service providers don’t want to change away from HTTPS. [of course there is no one who has decided to make this a cause to get the engineering and evangelism needed to roll out a new standard, not even Google]
Fixing GoGo’s Overload Problem (caused by streaming or anything else)
I understand GoGo’s concern about streaming – they don’t have enough capacity for bulk data transfer to airplanes, whether streaming or not. Their service gets disrupted by video-rate streaming, making everyone unhappy.
But it is the wrong solution (not just because of my main point), and there’s a technically better one. I use GoGo a lot. I’ve discovered that their system architecture suffers from “bufferbloat” (the same problem that caused Comcast to deploy Sandvine DPI gear to discover and attack bittorrent with “forged TCP” packet attacks, and jump-started the political net neutrality movement by outraging the Internet user community). Why does that matter? Well, if GoGo eliminated bufferbloat, streaming to the airplane would not break others’ connections, but would not work at all, with no effort on Gogo’s part other than fixing the bufferbloat problem. [The reason is simple - solutions to bufferbloat eliminate excess queueing delay in the network, thereby creating "fair" distribution of capacity among flows. That means that email and web surfing would get a larger share than streaming or big FTP's, and would not be disrupted by user attempts to stream YouTube or Netflix. At the same time, YouTube and Netflix connections would get their fair share, which is *not enough* to sustain video rates - though lower-quality video might be acceptable, if those services would recode their video to low-bitrate for this limited rate access].
It should be noted that once the FCC slapped Comcast’s hands about their content/destination discrimination by Sandvine attacks, Comcast’s engineering team invested a lot of time in getting a “bufferbloat fix” into the DOCSIS 3 modem deployment standards suggested by CableLabs. Rich Woundy, an SVP of Engineering there, personally made this his issue to solve. (however, the rate of deployment of their fixes to the field left something to be desired, and most other Access Providers have not deployed these fixes with any urgency, probably because an alternate, partial solution, urging customer’s to buy “fatter pipes” is more directly profitable). GoGo could pursue this approach. (and they don’t have the ability to sell “fatter pipes”…)
What could be done, which would be a lot better
I’ve mentioned two problems. One for the Internet community, and one for GoGo and other Internet Access Providers who suffer from bufferbloat, but don’t understand it can be fixed. Here’s what can be done.
There are off-the-shelf solutions for GoGo to deploy, today. I use a router software package called CeroWRT that embodies a mechanism for buffer management called “FQ Codel”, based on some brilliant work in router queue management today. FQ Codel can also drive ECN signalling, a feature of IP that signals congestion. The combination of these two have been demonstrated in actual real-world experiments to eliminate bufferbloat, solving the problem GoGo currently experiences. GoGo should hire Dave Täht, perhaps, who is one of the ringleaders of CeroWRT development. That improvement would certainly make my life, and other’s, on airlines using GoGo better! Some days GoGo just really sucks, appearing to be completely unresponsive, and when I check why, it’s because I’m getting multi-second Ping times, but no lost packets – the defining signature of a bad bufferbloat state – which can be caused by many other things than streaming from YouTube or Netflix. There’s no need for it to be unresponsive when the connection is up – the problem is that when queues get to be multiple seconds in latency, nothing works well, especially the Web browser experience. This problem is caused by GoGo’s bufferbloat, not by the users….
PS: I’d hate to see GoGo brought before the FCC in another en banc hearing on Broadband Network Management where their hacking into customer’s secure connections is part of the evidence that would have to be considered – that sounds like a hearing GoGo would not enjoy. I would be available as an expert to testify, as I did before with Comcast, in the prior hearing. I could explain why breaking encryption when they don’t have any need to do so is not needed to manage their network. But … I’d rather they just solve the problem with good engineering. Perhaps their engineers have more sway, and their managers are less cocky than Comcast’s PR people were. Calling all users who upload too much data “pirates” is a PR move that just made many of us less inclined to help them than Comcast’s use of DPI-based attacks already did.