Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gogo injects false SSL certificates for google.com domains

twitter.com

Post reply on HN
Print view View original

11–20 of 52 posts

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

#11

Post by AlyssaRowan »

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…

Can't stand this, it's as bad as RST injection.

Why does no-one ever seem to use 802.11u for this?

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

#12

Post by userbinator »

njloof wrote: post #10

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

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.

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

#13

Post by userbinator »

RKearney wrote: post #9
iancarroll wrote: post #4

I said this on reddit as well: could this just be them trying to block YouTube and other streaming services?

I doubt this is them trying to block YouTube. 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…

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.

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

#14

Post by cesarb »

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…

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.

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

#15

Post by tzs »

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.

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

#16

Post by furyg3 »

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?

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

#17

Post by diafygi »

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…

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.

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

#18

Post by diafygi »

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.
Post reply on HN