Live data from Hacker News

Gogo injects false SSL certificates for google.com domains

twitter.com

31–40 of 52 posts

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

#31
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.

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.

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

#32
post #28
post #18

Earlier quoted context omitted.

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

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.

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

#33
post #26

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

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?)

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

#34
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...

[1] https://twitter.com/__apf__/status/551132865555996673

https://twitter.com/__apf__/status/551096550516994048

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

#35
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).

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

#36
post #31

Earlier quoted context omitted.

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

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…

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

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

#37
post #31

Earlier quoted context omitted.

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…

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

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.

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

#38
that funniest thing is the comment from David Aronchick about midway down:

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

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

#39

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... [1] https://twitter.com/__apf__/status/551132865555996673 https://twitter.com/__apf__/status/55…

Correct! I've checked and it's also doing it for Vimeo, DailyMotion and probably other video sites.
Post reply on HN