Gogo injects false SSL certificates for google.com domains • Hacker News Board

Re: Gogo injects false SSL certificates for google.com domains

#21

Post by jessaustin » Mon, Jan 05, 2015, 2:56 PM UTC

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.

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.

Re: Gogo injects false SSL certificates for google.com domains

#22

Post by jessaustin » Mon, Jan 05, 2015, 3:01 PM UTC

njloof wrote: post #10

This is SOP at many employers that want to snoop use of their private Internet feed.

...SOP at many employers...

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.

Re: Gogo injects false SSL certificates for google.com domains

#23

Post by AdmiralAsshat » Mon, Jan 05, 2015, 3:17 PM UTC

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.

Re: Gogo injects false SSL certificates for google.com domains

#24

Post by EvanAnderson » Mon, Jan 05, 2015, 3:47 PM UTC

diafygi wrote: post #18

furyg3 wrote: post #16

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…

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.

Re: Gogo injects false SSL certificates for google.com domains

#25

Post by HackinOut » Mon, Jan 05, 2015, 3:53 PM UTC

stubborndude wrote: post #2

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

it doesn't redirect to the signup page. i believe it's to throttle streaming, but there are better ways to do it

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

Re: Gogo injects false SSL certificates for google.com domains

#26

Post by Kliment » Mon, Jan 05, 2015, 3:54 PM UTC

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

Re: Gogo injects false SSL certificates for google.com domains

#27

Post by _red » Mon, Jan 05, 2015, 4:11 PM UTC

Seems like someone should instigate a class-action lawsuit against them for DCMA / HIPPA violations.

Re: Gogo injects false SSL certificates for google.com domains

#28

Post by pdkl95 » Mon, Jan 05, 2015, 4:13 PM UTC

diafygi wrote: post #18

furyg3 wrote: post #16

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…

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.

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?

Re: Gogo injects false SSL certificates for google.com domains

#29

Post by acdha » Mon, Jan 05, 2015, 4:22 PM UTC

furyg3 wrote: post #16

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…

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:

http://www.arubanetworks.com/pdf/technology/whitepapers/WP_P... http://www.wi-fi.org/discover-wi-fi/wi-fi-certified-passpoin...

Re: Gogo injects false SSL certificates for google.com domains

#30

Post by acdha » Mon, Jan 05, 2015, 4:30 PM UTC

diafygi wrote: post #18

furyg3 wrote: post #16

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…

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.

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.