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.<p>It doesn't solve all CA problems, but it does soothe some.<p>[1] <a href="http://www.certificate-transparency.org/" rel="nofollow">http://www.certificate-transparency.org/</a>
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<p>1) GoGo are blocking youtube in favor of their in-flight paid media services not just for badwidth<p>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.<p>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.
Why are they even pulling this MITM trick in the first place ?<p>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 ?
The problem is not that they are doing this, but that they can.<p>This is a technology problem and it will not be fixed by shaming offenders (GoGo probably didn't have any evil intentions at all).
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" (<a href="http://www.w3.org/TR/SRI/" rel="nofollow">http://www.w3.org/TR/SRI/</a>). The "integrity" attribute is applied to links, like this:<p><pre><code> <a href="https://example.com/file.zip"
integrity="ni:///sha256skjdsfkafinqfb...ihja_gqg?ct=application/octet-stream"
download>Download!</a>
</code></pre>
This also applies to IMG, EMBED, LINK, etc - any content.<p>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 <i>cannot</i> 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.)<p>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.<p>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 (<a href="http://people.cs.clemson.edu/~jmarty/AQM/AQM-DOCSIS.pdf" rel="nofollow">http://people.cs.clemson.edu/~jmarty/AQM/AQM-DOCSIS.pdf</a>)
If you're using expensive bandwidth like a satellite channel to an aircraft, you definitely need something smarter than FIFO.<p>(I used to work on network congestion, a long time ago. See RFC 970, 1985. <a href="https://tools.ietf.org/html/rfc970" rel="nofollow">https://tools.ietf.org/html/rfc970</a>)