COMSEC: May 2008 Archives

As you may have heard by now, Debian introduced a distribution level patch to OpenSSL that pretty much completely wiped out the PRNG, with the result that it generated predictable keys. Plenty has been written about this, but it's worth noting that this bug has been hanging around for two years and was far from hidden. On the contrary, there was an outstanding bug documenting the "problem" that resulted in the patch and it wasn't hard to find the corresponding fix in Debian SVN. So, here we have a fairly obvious (to a security expert) error in a section of code that is well known to be security critical, specifically called out in the bug database and yet it took two years for someone to notice. What does that say about how difficult it would be to insert and hide a backdoor in a piece of software?

Lauren Weinstein is rightly concerned about Charter Communications' plans to "enhance" your browsing experience by injecting banner ads into your Web pages based on analysis of your browsing habits.

If this is something you're not that thrilled about, (which I can easily understand), then you might get to thinking what your options are. Charter offers an opt-out but as far as I know there's nothing forcing them to do so, and their opt-out appears to be pretty inconvenient:

Yes. As our valued customer, we want you to be in complete control of your online experience. If you wish to opt out of the enhanced service we are offering, you may do so at any time by visiting www.charter.com/onlineprivacy and following our easy to use opt-out feature. To opt out, it is necessary to install a standard opt-out cookie on your computer. If you delete the opt-out cookie, or if you change computers or web browsers, you will need to opt out again.

You could just change ISPs, of course, if you're lucky enough to live in a non-monopoly area and your other choices don't offer this enhanced feature set.

As Weinstein observers, one possible defense is to do HTTPS connections to every server, but that requires cooperation from all the server operators which has the usual network effect/collective action problems. But there's at least one obvious way to protect yourself unilaterally: set up a VPN to some provider who promises not to mess with your packets. You'd still be getting packet carriage from Charter, but they wouldn't be able to mess with your packets much, other than to drop or delay them. Certainly, they would not be able to inject their own traffic. This technique would probably introduce some latency, but the provider could locate their VPN concentrator near a major exchange point, which would reduce the latency quite a bit. The major obstacle would be finding someone to provide this service; I know there are providers which do IPv6 tunnels, but I don't know if they do v4 tunnels.

The effect of all this is to reduce your local ISP to raw packet carriage. Effectively, you're treating them long a long wire between you and your real ISP, the tunnel provider. Obviously, local ISPs could stop you from doing this, but it's hard to see on what grounds they would do so if they don't block enterprise VPNs.

In preparation for the IETF P2P Infrastructure Workshop, I've revised and expanded this post into a "position paper submission.

Introduction

In mid-2007 it was revealed [4] that Comcast was blocking peer-to-peer traffic (most famously BitTorrent) on their network by injecting RST packets to terminate TCP [7] connections. The BitTorrent community almost immediately discovered carrying BitTorrent over an encrypted tunnel (VPN or SSH) was not subject to blocking, thus completing another cycle of the ongoing arms race between peer-to-peer implementors and network operators. This paper explores some predictable next moves in the game and their consequences for the network.

This isn't intended to be comprehensive, because the request was for short papers, but I think it hits the high points. You can find the full note here.