
Gogo Inflight Internet is Intentionally Issuing Fake SSL Certificates - danielcorin
http://www.symantec.com/connect/blogs/gogo-inflight-internet-intentionally-issuing-fake-ssl-certificates
======
stevenjohns
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...](http://www.neowin.net/news/gogo-inflight-internet-is-
intentionally-issuing-fake-ssl-certificates)

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

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

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

~~~
stevenjohns
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!

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

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

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

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

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

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

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

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

How would the consumer know who they're trusting?

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

~~~
tyrfing
Regarding hotel portals, this is relevant:
[https://securelist.com/blog/research/66779/the-darkhotel-
apt...](https://securelist.com/blog/research/66779/the-darkhotel-apt/)

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

------
yuhong
Gogo is old news by now though.

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

~~~
ubernostrum
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).

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

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

