Hacker News Reader

Comment by stubborndude | Hacker News Reader

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.

View on HN

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

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.

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

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

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.

My samsung tablet is aware of login and opens browser after it connects to wireless network.

My guess is caching (thats in airplane).

Apple does the same thing (apparently they request https://www.apple.com/library/test/success.html and see if it returns the correct SSL and contents).

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.

Reply on news.ycombinator.com