

GoGo does not need to run “Man in the Middle Attacks” on YouTube - declan
http://www.reed.com/blog-dpr/?p=174

======
sandstrom
Certificate Transparency[1], a public log that makes maliciously issued
certificates easier to detect, will roll out in Chrome [for EVs to begin with]
this spring. FF will probably follow.

It doesn't solve all CA problems, but it does soothe some.

[1] [http://www.certificate-transparency.org/](http://www.certificate-
transparency.org/)

~~~
tptacek
You don't need CT to detect this; Gogo was using self-signed certificates,
which browsers reject all by themselves.

------
barnaby
This post assumes that GoGo are doing a MITM simply to block YouTube in order
to prevent their network from being congested. My assumptions would be that

1) GoGo are blocking youtube in favor of their in-flight paid media services
not just for badwidth

2) GoGo's MITM attack has little to do with media content but rather more
about being able to read all the communications of passengers for "national
security" purposes.

If they are decrypting and logging your traffic (including passwords) and
communications, then I assume their scheme can be defeated by a VPN. If you
want to send intimate messages to your lover, or discuss a political protest
while in flight, without some nosy GoGo employee reading it, then probably
using OTR (like Cryptocat or pidgin/adium), PGP (like mailvelope, enigmail),
and ZRTP (Redphone/Signal) are a pretty good idea.

~~~
declan
But there's no evidence that either of your assumptions is true. Gogo has said
publicly[1] that they're trying to "shape bandwidth" to YouTube and other
streaming sites. Let's not spread conspiracy theories about "national
security" on HN when the truth about the NSA's domestic surveillance hijinks
is disturbing enough.

I say this even though I've criticized Gogo[2] and suggested ways in which
they may be legally liable as a result of their fake *.google.com cert.

For those who may not be familiar with his work, David Reed, the author of the
linked post, helped with the early development of what would become the modern
Internet. That includes UDP and IP signaling, which is one reason (I believe)
he won an ACM hall of fame award.

[1] [http://concourse.gogoair.com/technology/statement-gogo-
regar...](http://concourse.gogoair.com/technology/statement-gogo-regarding-
streaming-video-policy)

[2]
[https://twitter.com/declanm/status/552365531798716417](https://twitter.com/declanm/status/552365531798716417)

~~~
xnull1guest
"In designing its existing network, Gogo worked closely with law enforcement
to incorporate functionalities and protections that would serve public safety
and national security interests"

"Although FCC rules “do not require licensees to implement capabilities to
support law enforcement beyond those outlined in CALEA…,” Hastings noted,
“[n]evertheless, Gogo worked with federal agencies to reach agreement
regarding a set of additional capabilities to accommodate law enforcement
interests. Gogo then implemented those functionalities into its system
design.”"

[http://www.wired.com/2014/04/gogo-collaboration-
feds/](http://www.wired.com/2014/04/gogo-collaboration-feds/)

[http://www.wired.com/wp-content/uploads/2014/04/Gogo-
Letter-...](http://www.wired.com/wp-content/uploads/2014/04/Gogo-Letter-to-
FCC.pdf)

------
whyleyc
Why are they even pulling this MITM trick in the first place ?

Can't GoGo just "blacklist" streaming sites at a DNS level and deal with the
problem before a connection is even made to a high-bandwith destination ?

~~~
wtallis
It's commonplace for savvy users to never trust the DHCP-provided DNS servers,
and DNSSEC is available to detect when responses from your trusted DNS server
are being hijacked and replaced with lies.

~~~
Panino
DNSSEC offers no protection against censorship because it's not encrypted. All
GoGo would have to do is drop the query or return SERVFAIL.

~~~
wtallis
DNSSEC protects against the hard to detect forms of DNS fraud. A SERVFAIL or
ignored query already makes it completely obvious that your DNS server isn't
behaving, and if you're trying to use an otherwise-reliable DNS server, it's a
major red flag that the network is working against you. What DNSSEC protects
against is a DNS server returning information that it wants you to think is
valid; a SERVFAIL is never going to look like the right response.

There's a lot more than just censorship that can be accomplished by messing
with DNS responses, and censorship done solely through DNS is actually pretty
half-assed censorship.

~~~
Panino
Right, but the comment that prompted this sub-thread was:

> _Can 't GoGo just "blacklist" streaming sites at a DNS level and deal with
> the problem before a connection is even made to a high-bandwith destination
> ?_

Clearly the word here is "censorship." Or if you prefer, "blocking," which
doesn't have a politial connotation. DNSSEC was then proposed as a
countermeasure to this blocking, and I showed why it's not a countermeasure.

DNSCrypt would be more effective here because it's encrypted.

~~~
wtallis
DNSCrypt on its own accomplishes nothing. What you're really saying is to use
DNSCrypt and configure it to masquerade its traffic by not using port 53 so
that it's less likely to be blocked. Without using a non-standard port, the
results for DNSCrypt will be the same as from DNSSEC: an error in trying to
look up the domain, which is identifiable as being different from an error
trying to access the server pointed to by the DNS record.

You don't need DNSCrypt to be able to do DNS lookups on a non-standard port.
DNSCrypt just happens to offer a list of a few servers that respond (using
their protocol) on non-standard ports. The list is short enough (16 IPs to
block!) that it could easily be included in the malicious gateway's firewall
rules, rendering DNSCrypt useless for working around the blocking and still
less useful than DNSSEC for deducing the nature of the interference.

~~~
Panino
I think you've misunderstood what _whyleyc_ wrote above. OP asked why GoGo
doesn't just "blacklist" ie censor the mentioned sites via DNS, explicitly
_excluding_ a MITM attack:

> _Why are they even pulling this MITM trick in the first place ?_

> _Can 't GoGo just "blacklist" streaming sites at a DNS level and deal with
> the problem before a connection is even made to a high-bandwith destination
> ?_

So no MITM, just GFW of China style blocking. Which is trivial for unencrypted
packets like DNSSEC. Observe, by the way, that China supports DNSSEC -- it's
not a problem for them!

[http://dnsviz.net/d/cn/dnssec/](http://dnsviz.net/d/cn/dnssec/)

And it wouldn't be a problem for GoGo, either, because DNSSEC is not encrypted
and blacklisted sites can be dropped on the floor. Or GoGo could trivially
return SERVFAIL. But the whole thing is moot anyway because youtube.com
doesn't support DNSSEC and probably never will.

~~~
wtallis
Blocking DNSCrypt entirely and forcing a fallback to the approved (censored)
DNS servers is still not any harder to accomplish than censoring unencrypted
DNS with or without DNSSEC. DNSCrypt as it currently exists is not any more
censorship-resistant except where it is completely unknown to the censoring
party. The only real security (against censorship) that it offers is security
through obscurity, so saying that DNSSEC's problem is a lack of encryption is
complete bullshit.

------
cornewut
The problem is not that they are doing this, but that they can.

This is a technology problem and it will not be fixed by shaming offenders
(GoGo probably didn't have any evil intentions at all).

------
Animats
What we need is not "HTTPS Everywhere" (which I sometimes call "Security
Theater Everywhere") for static content. We need content signing without
encryption for bulky content. The W3C proposal for this is called "Subresource
integrity" ([http://www.w3.org/TR/SRI/](http://www.w3.org/TR/SRI/)). The
"integrity" attribute is applied to links, like this:

    
    
        <a href="https://example.com/file.zip"
         integrity="ni:///sha256skjdsfkafinqfb...ihja_gqg?ct=application/octet-stream"
           download>Download!</a>
    

This also applies to IMG, EMBED, LINK, etc - any content.

This is a huge win for caching systems. Any cache in the path from browser to
server, seeing that, can use a cached version of the content. Because cache
content validity is defined by the sha256 hash, there's no cache expiration
time issue. You can load JQuery once and use it all week. Caching systems can
even index their cache by hash, and deliver data loaded from a different site.
What a cache _cannot_ do is change even one bit of the content. Such data
tampering will be caught by the browser. (W3C is trying to figure out what to
do about streaming data.)

As for "bufferbloat", that's usually mis-identifying the problem. The real
problem is usually bad queue ordering at a choke-point router. FIFO queuing at
a choke point will not work well. At a router where there's significantly less
outgoing bandwidth than incoming bandwidth, you need some kind of fair
queuing, so that big flows don't starve out little ones. Most Cisco routers
support that. On the other hand, there's nothing wrong with buffering up lots
of content for a single flow if you have the space. If you're loading a big
image or a video stream, temporarily stashing a full TCP window of it in the
router is just fine. It will be delivered and will play out eventually.

Ideally, you'd like full fair queuing, but it's somewhat computationally
expensive. There are approximations to fair queuing that work reasonably well,
and are being designed into DOCSIS cable routers. See
([http://people.cs.clemson.edu/~jmarty/AQM/AQM-
DOCSIS.pdf](http://people.cs.clemson.edu/~jmarty/AQM/AQM-DOCSIS.pdf)) If
you're using expensive bandwidth like a satellite channel to an aircraft, you
definitely need something smarter than FIFO.

(I used to work on network congestion, a long time ago. See RFC 970, 1985.
[https://tools.ietf.org/html/rfc970](https://tools.ietf.org/html/rfc970))

~~~
Animats
After looking at what GoGo is doing, it seems that all they really want to do
is just block YouTube. The problem is telling the user what they're doing, so
they don't bitch at the flight attendants. Technically, they should send back
an ICMP Type 3 message, "Destination Unreachable" with code 10 (Communication
with Destination Host Administratively Prohibited) or code 13 (Communication
Administratively Prohibited by Filtering). But that info won't make it up to
the browser in either Windows or Linux. About the best you can get through to
the client program is a "Host Unreachable" error code.

So, in the style of most web intermediates, they're trying to do this at the
HTTP level. Which doesn't work well for HTTPS requests. One of the annoying
features of HTTPS is that there's no standard way for a site to say "I don't
speak HTTPS". I run a crawler, and responses to HTTPS requests include timing
out, sending non-HTTPS data confusing the SSL/TLS layer, and refusing to open
a TCP connection.

About the most legit thing they might do is open an HTTPS connection using a
cert signed for a domain name such as "YOUTUBE-IS-BLOCKED-BECAUSE-YOU-ARE-ON-
AN-AIRPLANE.NET". The HTTPS open will fail due to domain mismatch, and the
browser popup will have some useful info. If the user actually lets the
connection open, they can be given a page on why satellite links don't have
enough bandwidth to let everyone on a plane watch cat videos.

