Random guess - this is probably because many people have a their homepage as a SSL'd google site. In order to be able to show the "login or pay" message to someone when they fire up their browser, Gogo needs to have a cert to communicate over 443 without the browser refusing to display a page.
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.
That wouldn't work, popular browsers like Chrome pin the SSL certificate for Google domains (see for instance https://www.imperialviolet.org/2011/05/04/pinning.html), so the homepage would just show an error message (IIRC when the certificate is pinned there's no button to ignore the error).
The most probable explanation is that it's a "transparent" proxy which MITMs everything, and the original poster used youtube as an example.
That would be true only if the screenshot showed the "login or pay" page. Those things work by issuing a fake SSL cert for the initial request in order to redirect you to the inflight.gogo.com page to login or pay.
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.
not true. most captive portals work using a redirect. The first time a new device tries to request a webpage, the network gateway will intercept that traffic and reply with some sort of HTTP redirect (perhaps a 303?). This will cause the browser to request a new page with a new URL. Following the redirect, the address bar will show the URL of the captive portal -- not that of the original page requested.
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.
They just cloned the list of SANs in the standard Google certificate, which YouTube also uses.
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.
It allows them to scan for (and block) malware - which is increasingly being served over HTTPS to evade detection.
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.
Any such lawsuit would immediately run into the problem that your employer gives you a computer to work for them, not to conduct your personal online banking and you'd need to be willing to lose your job banking on that lawsuit succeeding and generating a large enough settlement to be worth it.
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.
> 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.
That's only true for generic public proxies. In the context we're talking about, however, it's too easy to imagine a company which has patient records installing a corporate monitoring proxy but configuring it in some way which either revealed data to people who shouldn't have it or failed to retain mandatory records like audit logs. Some places feel corporate proxies are necessary for compliance auditing but they're enormously risky since you're creating a single point of failure which has access to almost everything.
Sure it's possible that all the employment contracts have been drawn up to completely protect the firm, but not all firms are so on the ball. If network security engineers can screw up, so can lawyers.
I wonder if there is any trademark/service mark issue here? They are issuing a certificate that identifies itself as Google's, but it is not.
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.
Captive portals really need to die. Fake DNS entries, URL redirects, injected html/javascript, false certificates, all are very annoying essentially train users on bad behavior, and provide opportunities for nefarious actors (either by the hotspot provider themselves or attackers spoofing hotspots)
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?
Captive portals are fine if you use a VPN. When I go on a flight, I visit a non-https site, get redirected to the WiFi login-or-pay, pay, and then connect to my VPN. All traffic after that (to the airline) is encrypted. Plus, airlines would never start blocking VPNs because you would lose all of your business customers.
Try getting non-technical users to understand how to do that. Captive portals have been an unending source of frustration for my clients over the years.
Captive portals need to die not because of any technical reason - they have the same problem as the "UAC" pop-up showing up far-too-frequently: it teaches people to ignore what should be a serious security warning. A SSL certificate suddenly changing to a strange new signing authority is the kind of problem that should be a serious warning. By de facto teaching that it is ever valid to ignore important security measures, captive portals badly hurt the real education that needs to happen about how to handle computer security.
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?
Maybe certificate pinning needs to include being able to forbid clicking through a warning. WiFi services would change their methods fast if they got sudden drop in users.
In addition to the obvious usability and cost drawbacks to that approach, it still doesn't help you with cache pollution. I've had to tell many people how to force a reload or even clear the cache because they got the captive portal response and it was never refetched after logging in.
captive portals don't work with VPNs. A captive portal is simply a redirect to a login page for the purpose of authorizing a device to use a network. No VPN will work until the device has had a chance to open a web browser and pass through the captive portal. Once the device is approved to pass traffic through the network, the captive portal no longer plays any role.
what gogo did was make some very poor decisions regarding proxying. in which case, yes, VPN can circumvent that.
802.1x works for devices which already have an account – e.g. corporate networks, etc. This has been supported by Windows, OS X, etc. for many years.
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:
But what about non-free hotspots? For example, captive portals are commonly used in hospitality to generate revenue. There needs to be a way to associate the device with a user for billing purposes. Captive portals provide this mechanism while making it easy for guest devices to join the network.
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.
It's not clear but the documents do specifically mention the ability to send people to login / signup pages. I'm pretty sure that's not being ignored so much as being buried in marketing/carrier-speak.
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.
This is a mistake on Gogo's part. I can't think of anything legitimate they could do using this that they couldn't also do in a more reasonable way. The illegitimate things they could conceivably do with this (if they wanted to do, which seems unlikely), they can't do reliably or without getting quickly discovered. A lot of people are going to see the pinned browser warning and wonder what's up.
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.
Could be completely unrelated, but I seem to recall that anyone who bought certain lines of Chromebooks was supposed to be given 10 free complementary wifi sessions through Gogo. I wonder if Gogo was given the cert by Google for that.
I wonder if it's related to this workaround that allowed access to some Google IPs to bypass the captive portal, which someone managed to then use to access app engine, and a proxy running there to reach the entire internet: http://bryceboe.com/2012/03/12/bypassing-gogos-inflight-inte...
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."
Well they would be facing the unforeseen consequences while not even filtering the HTTP host header (the youtube page is displayed). Unless they forgot to disable the MITM once the user is granted full internet access...
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?)
DMCA is more than copyright....its also about "Anti-circumvention", the idea that a supposed secure connection being circumvented.
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?
According to tweet author[1], this happened only with Youtube, and was not related to captive portal mechanism whatsoever. So I would side with her on the why: Poor plane internet access was overloaded by videos streamed from Youtube and somebody hacked together a very ugly solution that's going to have bad consequences...
I'm not sure what all of the fuss is about. They didn't somehow obtain a copy of Google's real certificate; they made a fake one with the same contents, but not signed by a certificate authority your browser trusts. Your browser erects the standard "woah wtf" alert. There is a ton of infrastructure built into your browser to make sure you are aware of this.
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).
On gogo wifi right now and I'm not able to replicate the results. After paying for access I've tested several google services with no certificate issues(checked with latest Chrome, and openssl's s_client).
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.
51 comments
[ 4.3 ms ] story [ 110 ms ] threadNot 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
https://twitter.com/__apf__/status/551096550516994048
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.
[0] http://imgur.com/a/C8Tf4
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.
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.
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.
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.
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.
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?)
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?
[1] https://twitter.com/__apf__/status/551132865555996673
https://twitter.com/__apf__/status/551096550516994048
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).
"@__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.
https://twitter.com/moyix/status/542079755659390976
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.