Gogo Inflight Internet is Intentionally Issuing Fake SSL Certificates | Hacker News Reader

Gogo Inflight Internet is Intentionally Issuing Fake SSL Certificates

symantec.com

87 pointsdanielcorin30 comments

Okay I've never commented on my affiliation before because I don't want to advertise but this is ridiculous.

I am the one who wrote the first article and 'broke' the story about Gogo's snooping [0]. Plenty of publications also reported on it after it reached high notoriety on Reddit. Some copied parts of my article, some didn't give a source or via to me, some made it appear like they were producing original news. That's fine, I don't really care: it happens to almost every single original article I write (one time I took a screen shot of my own Desktop as an article image and the other websites copied that too with no source) and I've grown use to it - I was just happy that it was making waves and forcing Gogo to reconsider their position.

But in this case, Symantec has copied my original title verbatim. If you're going to literally copy my title verbatim, at least give a link back to it. Ridiculous. It wasn't even a good title.

[0] http://www.neowin.net/news/gogo-inflight-internet-is-intenti...

You need to list all that copying that was done on your resume. What better way to prove your skills than to show how much people are copying you.

If I was a career journalist I'd probably be more concerned, but I'm a software engineer and write just because I enjoy tech.

Original research cited by major news organizations puts you on a whole new level above just "software engineer" for salary purposes. It's resume-worthy if you have a section for academic-type accomplishments.

That's actually a really salient point. I've never considered it as 'research,' my mind just never made that connection for whatever reason. I'll keep it in mind from now on - thanks!

Slightly OT: CDNs basically perform a MITM to do what they do. The destination site's certificate (www.destination.com) is deployed throughout the CDN's servers and when DNS lookups are performed, the end user is directed to the IP address an optimal edge server where the certificate is waiting to greet them warmly. On the other side (first mile), the CDN then connects via a second SSL certificate (say, origin-www.destination.com) to the origin's datacenter(s) to retrieve the necessary data.

When I worked at a CDN company, we frequently got inquiries from customers saying that a security audit they ran threw up a red flag for MITM. And it was my job to tell them why it wasn't anything to worry about.

PS, most origin-www.destination.com origins are extremely vulnerable to DDoS since, at that hostname, there is no CDN to protect them.

While what you explain is correct, willfully giving/deploying your certificates in another server probably doesn't count as MITM

Agreed. It's only MITM if it's unauthorized IMO. If I deploy my cert to a CDN its just legitimate handshakes so I'm not sure where the man in the middle comes in.

> On the other side (first mile), the CDN then connects via a second SSL certificate (say, origin-www.destination.com) to the origin's datacenter(s) to retrieve the necessary data.

Perhaps. Not all CDNs require TLS to be used to connect to backends when the frontend is encrypted. This is completely obscured from the requesting client, and is a breach of user trust in my opinion.

> PS, most origin-www.destination.com origins are extremely vulnerable to DDoS since, at that hostname, there is no CDN to protect them.

This is a big problem that is rarely addressed until it bites you. When you're accustomed to a >90% hit rate and all of the nastiness of the Internet being handled upstream, you aren't going to be prepared for even a slight uptick in origin traffic.

I saw one place whose site was served via Akamai DSA (http acceleration service), and routinely served >5Gbps. The origin consisted of two machines behind a Cisco ASA with a 100Mbit Ethernet port.

I think the two scariest discoveries with Superfish are that Microsoft allows an OEM to ship a retail Windows computer with additional root certificates, and that Chrome is trusting the root certificates stored by Windows -- Firefox does not.

My proposed actions:

(1) Microsoft should immediately update their OEM agreements to ban all manipulation of root certificates for computers sold at retail. Further, the root certificate store should be cryptographically signed by Microsoft and this signature validated during Windows OOBE.

(2) Google should follow Mozilla's lead and have Chrome securely manage its own root certificate store. (It could be disabled for legitimate corporate deployments, but never with the regular end-user Chrome installer.)

Chrome has chosen to use the system network (proxy) settings, the system SSL stack, etc. It actually makes sense for them to use the state CA store. Firefox's legacy includes platforms where there was no system any of that. As use shouldn't need to set proxy settings or corporate CAs for every application they run.

Otoh, it is unfortunate that chrome has different SSL behavior on every platform.

When it comes to SSL/TLS, "on all platforms, [they] use NSS's libssl to handle the SSL connection logic... [and] ... platform specific APIs for certificate verification."

Further, the root certificate store should be cryptographically signed by Microsoft and this signature validated during Windows OOBE.

This is just one small step down the path of not allowing any modification to the root certificate store, and that is an even scarier situation, since users will have absolutely no control over who they decide to trust.

I would agree with you if most users understood the concept of trust as it relates to the root certificate store. Very few do, likely less than 1%.

Therefore I believe it must be Microsoft's responsibility to be the singular default trusted entity for the root certificate store shipped to retail consumers as part of Microsoft Windows.

Your slippery slope argument fails because your "small step" would be immediately rejected by the vast majority of the Fortune 500, for starters. It just couldn't happen. It would be unworkable.

Devil's advocate: But then if an OEM wants to install themselves as a root, they cannot. That's anti competitive. Why should MS be especially trusted over the OEM?

Slowly and way too late, MS has been learning that their "partners" mostly suck and hold a lot of responsibility for MS being so far behind today. MS shipped tablet PC how long before Apple? But they figured "yeah HP and Dell will handle our customer experience well, sure".

Also, how is Chrome gonna determine a legitimate deployment? Cause then the dev just needs to convince Chrome it's in a corp environment.

Or... Just ship a patched version of Chrome/FF/whatever that doesn't do cert validation.

Devil's advocate on your devil's advocate: what legitimate reason could an OEM have for installing a root certificate?

Same as MS? Maybe they feel they have a better idea on who to trust and thus add and remove certificates as necessary. Maybe they want to sign their own hardware drivers (though, I think those don't use the system CA store). Perhaps they want to offer signatures to customers or software vendors and feel current MS provided CAs are lacking.

More mundane, perhaps there's a cheaper CA that's accepted by some trusts, but not MS. Why should MS be trusted more than $OEM?

OK, fairly weak arguments, but the freedom of doing so is important. Just as it is important that users be able to verify and undo and choose their root of trust.

The concept of a global root of trust breaks down pretty fast. And the OEM can already compromise anything anyways.

> Same as MS? Maybe they feel they have a better idea on who to trust

How would the consumer know who they're trusting?

> how is Chrome gonna determine a legitimate deployment?

Terms and conditions. The corporate version can not be pre-loaded on computers sold at retail unless explicitly ordered by the customer.

> Just ship a patched version

Again, T&Cs. I believe it's already a license breach to distribute a modified or patched build of Firefox unless the branding is stripped out -- this is why Debian shipped Iceweasel rather than Firefox. The same probably already applies with Chrome/Chromium.

> Microsoft should immediately update their OEM agreements to ban all manipulation of root certificates for computers sold at retail.

You realize that Microsoft is forbidden from doing this by their consent decree, and that their argument at the time to the DOJ was that it would restrict them from stopping bad actors.

I say this not to defend Microsoft, just to state the facts. They were bullies and frankly got off with a slap on the wrist.

But it's an important lesson in the NN pseudo-debate. I am not a fan of NN because I do agree, no matter how constructed, it will retard innovation and have negative loopholes like this snapfish one on the PC. But the carriers are abusive and have been proven plenty of times to be untrustworthy so I don't know any better option.

Here's a description of the relevant part of the consent decree from a 2003 compliance memo:

Section III.H of the Consent Decree requires Microsoft to allow end users and OEMs to enable or remove access to all middleware products including web browsers, e-mail clients, and media players through a readily accessible, centralized mechanism. This mechanism must also allow end users and OEMs to specify a non-Microsoft middleware product as the default middleware product to be launched in place of the corresponding Microsoft middleware product. In order to comply with Section III.H, Microsoft created the "Set Program Access & Defaults" ("SPA&D") utility and included it in Windows XP Service Pack 1 and Windows 2000 Service Pack 3.

There are a lot of places which "spoof" or provide their own public in the TLS handshake. Top of mind is every single hotel I've ever stayed at which requires the entry of my last name and hotel room number via a captive portal. Of course in those cases the captive portal authentication page isn't the site I was originally going to visit, although some don't redirect and do leave the original destination in the address bar which is always an interesting trust issue, especially if the captive portal is asking me for my ISP password or a credit-card.

Regarding hotel portals, this is relevant: https://securelist.com/blog/research/66779/the-darkhotel-apt...

Pretty sure I remember PHK warning that (paraphrased) if you encrypt cat videos along with everything else it's just going to cause more effort to break and get around the encryption. Maybe httpbis should have actually listened to him.

Gogo is old news by now though.

I hadn't heard of it. Glad to hear about this -- MiTM attacks & SSL spoofing is an important problem in today's internet security.

Still, there will be a broken padlock icons in the browser.

As much as they can read the traffic, they can't spoofed the identity. Not without having their own root cert on the customer side.

They don't successfully spoof it; that would require a cert signed by a root CA the browser trusts, and they don't have that. So what you'll actually get is not a web page, but an SSL cert error warning from your browser. If you're technically inclined enough to click your way through to see the actual page, I think all you get is a generic "YouTube is blocked" (and blocking YouTube is the reason why they do it -- they don't have the bandwidth to support it or other streaming video).

Right. They're trying to tell you "you can't do that", but have no good way to do so. As I pointed out when this came up last time, the problem is that current network stacks and browsers don't propagate ICMP Destination Unreachable subcodes (such as "Host Unreachable - Communication Administratively Prohibited") up to the user. That's the proper way to express "you can't do that". Unfortunately, most OSs treat network errors like file errors, hammer them down to some small set of "errno" values, and lose the detail.

This is very different though, because it would throw an error.

It's training users to ignore the error, and that's bad, but yes, it's not as bad as komodia

Reply on news.ycombinator.com