Gogo injects false SSL certificates for google.com domains
twitter.com
twitter.com
Plus the user experience is awful, sometimes when I join a network the portal shows up immediately, sometimes I only get it when I open a browser. Sometimes I open my mail first and get 10 error messages about incorrect certificates.
Is there any good alternative / standard that could serve the purpose without all of the current drawbacks?
Worse, this is another example of where laziness and convenience tend to promote these bad habits. Never-mind the average user - way too many technical people[1] fall into these bad habits - including programmers and sysadmins that really should know better. This isn't just WWW/HTTPS - did you always use a VPN? With a properly secure login that you know does not involve a MitM?
[1] I mean in the general, statistical sense - any resemblance to people posing in this thread is an unintended coincidence.
> never start blocking VPN
That's easy - you just push PKI (alreadyd used in many places) and make up some excuse why this new version is needed for "airplane security". We live in an age where airlines (w/ the TSA/.gov) make a big deal about confiscating water bottles and regularly steal from luggage; do you really expect "business customers" to get angry over VPNs while allowing the past decade of security theater?
what gogo did was make some very poor decisions regarding proxying. in which case, yes, VPN can circumvent that.
If you want the classic signup flow for a service where the user can't already be assumed to know about it, I believe you're talking about “Wi-Fi Certified Password” or “Hotspot 2.0” which appears to cover a slew of features related to devices discovering networks and being able to do things like detect which networks you have an existing roaming relationship with:
http://www.arubanetworks.com/pdf/technology/whitepapers/WP_P... http://www.wi-fi.org/discover-wi-fi/wi-fi-certified-passpoin...
Passpoint appears to provide a bypass for devices with a pre-existing, approved carrier; it does not appear to address the foreign/unknown device dilemma -- how to easily allow the unknown device onto the network and collect revenue from it.
to clarify, I'm not defending what gogo did to SSL. That's wrong and horrible. but captive portals had nothing to do with it.
edit: my reading of passpoint is that it provides a way for mobile devices to join wifi networks without making the user go through the process of selecting the proper SSID. Instead, the mobile device sees information about the network and joins automatically. but once the device is on the network, passpoint is complete and if the network is captive portal'd, the device will then have to visit the login page to proceed.
Not condoning the practice, but thats my guess at the motivation. I also imagine it doesn't work very well, as many new browsers will refuse to display if the cert chain is broken.
My guess is caching (thats in airplane).
Why does no-one ever seem to use 802.11u for this?
The most probable explanation is that it's a "transparent" proxy which MITMs everything, and the original poster used youtube as an example.
The fact that the screenshot shows they are not rediecting with the fake cert makes it clear this is an intentional Man in the Middle attack.
https://twitter.com/__apf__/status/551132865555996673
EDIT: Still from same author:
no, had already been logged in for hours; and only happened on YouTube
quote from that article:
"There is, of course, one other possible solution: Gogo could man-in-the-middle the desired Google web services in order to perform filtering on the HTTP host header. However, this approach could have unforeseen consequences. Therefore, I do not recommend it."
EDIT: Those are two nice insights about what Gogo does behind the scene, but I would bet the fact Google is involved with both is a coincidence (or is it considering the multiplicity of Google's Services?)
Of course, that this is a mistake doesn't mean it will be corrected soon, so VPN is probably the way to go, which maybe it is anyway.
EDIT: perhaps this is intended to plug the hole mentioned here: http://bryceboe.com/2012/03/12/bypassing-gogos-inflight-inte... That really should be only applicable to people who haven't paid, however.
Note that if Google sued over this, Gogo would not be able to use anything in its TOS as a defense, because the TOS is between Gogo and its users, not between Gogo and Google.
"@__apf__ i love that people are trying to explain to you what's going on - do you folks know who she is? :)"
So I'm like, who is this girl? I've never heard her? What's the big deal with people taking guesses about what is going on?
Then I check her profile on twitter:
Engineer & usable security researcher. Google Chrome security team.
Yep... sometimes when you throw your two cents in, you get hit in the head with a quarter.
I personally MITM my own connection and redirect the traffic through a filtering proxy for the same reason. There is probably something in Gogo's ToS which mentions it.
Of course they could be using the data for other malicious purposes, but I don't think that is the case here. If you don't like it, you either don't use their service or just tunnel through.
That's true, and I can't believe we still haven't seen someone suing an employer over leaked personal banking creds. Many firms just have the proxy running, and haven't actually thought very hard about what assets (and whose) that proxy sees.
The far more likely grounds for a ruling against a sloppy proxy operator will come from something like a HIPAA violation or perhaps one of the financial trading companies.
In general, I don't think a proxy operator would be covered by HIPAA; if there's any HIPAA issue there, its with the HIPAA covered entity with which the user is communicating using a communication mechanism vulnerable to an MITM attack in the first place.
I opened another laptop(I travel with two), and without paying I started testing outbound connections with openssl's s_client and curl. It appears that the gogo wifi system will allow between 5-10 ssl connections before starting to block all outbound ssl connections. Without paying all http requests include a redirect to the captive portal, but at no time did I see a self signed cert for any of the https connections attempts.
I suppose the main reason to be concerned is that, sadly, many people will click through this; generally, though, they are the same people who will download random software and install it, join untrusted wifi networks, click on attachments, etc etc -- in other words, they are already victims of clicking-before-thinking or clicking-without-understanding.
This is less horrible than silently modifying pages, injecting JavaScript, etc -- at least you get a warning and can go to a non-ssl page and pay for your wifi (and then use a VPN if you so desire). It isn't just GoGo that does this. Various other public WiFi, such as hotels, airports, etc, often do things like this as well (though usually just to extract payment rather than selectively block certain sites).
The certificate has SAN entries for things like google-analytics.com, android.com, *.cloud.google.com, goo.gl, g.co, urchin.com, and a plethora more[0].
If they wanted to just block YouTube, there are ways to do that without forging certificates. For example, modern browsers will send the domain name in plain-text even for HTTPS connections for SNI to function. They could easily block based on that.
Captive WiFi portal (or some sort of traffic-shaping) is likely the right answer, as the other poster above points out.
Given that the issuer is an internal IP I'm pretty sure they are just proxying HTTP(S) requests, grabbing the remote certificate, duplicating the subject and signing it, allowing them to on-the-fly MITM any HTTPS traffic. Trying this with a different HTTPS site will easily show this, I don't think they're specifically targeting Google directly.
HIPAA doesn't apply either; the in-flight wifi carrier is not a health care provider.
For HIPAA: What happens when you search google for your healthcare issue that they intercept? Since they have your name (from your credit card info), now their severs have sensitive healthcare info...are they HIPAA compliant?