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

41–50 of 52 posts

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

#41

Post by jessaustin »

acdha wrote: post #31
jessaustin wrote: post #22

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…

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.

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

#42

Post by duskwuff »

_red wrote: post #27

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

DMCA doesn't apply here; there is no copyrighted media being copied.

HIPAA doesn't apply either; the in-flight wifi carrier is not a health care provider.

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

#43

Post by chasefox »

acdha wrote: post #29
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 b…

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.

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

#44

Post by acdha »

chasefox wrote: post #43
acdha wrote: post #29

Earlier quoted context omitted.

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

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…

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.

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

#45

Post by calciphus »

AdmiralAsshat wrote: post #23

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.

If they were, it would be signed by Google, not self-issued by Gogo

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

#46

Post by chasefox »

acdha wrote: post #44
chasefox wrote: post #43

Earlier quoted context omitted.

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…

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.

so.... a captive portal again.

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.

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

#47

Post by chasefox »

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

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

#48

Post by chasefox »

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…

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.

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

#49

Post by chasefox »

Kliment wrote: 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…

captive portal != proxy

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

#50

Post by chasefox »

AdmiralAsshat wrote: post #23

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.

completely unrelated.
Post reply on HN