ThePirateBay's Flawed Plan to Encrypt the Internet

Any idea what's up with this new plan from ThePirateBay to "encrypt the internet"? Is this trying to replace the TCP stack with an SSL stack -- every time you try to open a TCP connection it instead first tries to (essentially) open an SSL connection and, failing that, falls back onto regular TCP?

Amazingly, Wikipedia doesn't even have a page for it -- crazy!

This from the IPTEE website:

"As an example, when a new TCP connection is established with the 3-way handshake the crypto layer at the "initiator" will hold any pending application data and start the key negotiation process. When a session key has been established, the pending application data is encrypted and sent. All following communication on that TCP stream is then treated as encrypted traffic. Should the remote host not reply with a valid key-negotiation response, the TCP connection is closed, re-opened, and the application data passed through unencrypted."

Ug, so when this rolls out, every single TCP connection will start with a garbage request, fail, and then reconnect? This seems like it could lead to an *exceedingly* slow experience for anybody who installs this, as 99.999% of all TCP connections they attempt will fail, and probably not quickly but rather by timeout.

For example, the servers I write typically accept a TCP connection, and then keep receiving as much as possible until it gets a well-formed request. If it doesn't get a well formed request it'll eventually timeout. But -- and this is key -- a malformed request won't be instantly detected and trigger a disconnect. Indeed, this would be extremely difficult in the general case.

For example, assume your protocol used an HTTP-like structure with \r\n terminated lines, the first of which is just a big string, and each subsequent line is a "Header: value" pair, followed by a blank line (double \r\n). Super basic protocol, like this:

GET / HTTP/1.1
Host: quinthar.com

However, because the parser is general purpose, it doesn't know every possible valid "method" line. The parser takes anything that fits the pattern and passes it to a higher level for processing. This will therefore accept anything like:

Host: quinthar.com

Or even:

The quick brown fox jumped over the
Lazy: log

Normally that's fine -- after all, it's a rare situation for somebody to connect to you with a malformed protocol in the first place, and generally they're going to at least make a good effort so even if it's not totally perfect, leave it to a higher level to figure it out:

Get / Http/1.1
HOST: quinthar.com

But any user with this thing running will result in a hung connection. Rather, it's going to send some binary garbage like this:


The parser will look at this and say "ok, it looks wierd, but maybe it's good" and it'll wait until it either gets a well-formed message, or its input buffer is exceeded, or a timeout occurs. In the case of IPETEE, it'll probably always be the last one. Meaning every TCP connection opened to my server will first have this incredible timeout before it gives up and falls back to TCP.

Ok, so now you're thinking "so what David, your servers suck anyway" That may be, but I note that Apache and IIS behave the same way. This means that virtually every HTTP request you make is going to be incredibly delayed. At least, until everybody in the world adopts this.

And that's just HTTP. I'm guessing this design pattern of protocol parsing is exceedingly common. Which means basically all TCP connections of all kinds would be incredibly delayed.

And all this ignores, of course, that this encryption layer doesn't even attempt to prevent man-in-the-middle attacks, so it only provides protection against passive observation. But any ISP that is seriously curious about what's going on inside could simply intercept each end and insert a sniffter. Let's say they do this in 0.001% of all TCP connections, over time they'll figure out who the pirates are (because BitTorrent opens up so many damn TCP connections, they'll come up pretty quick).

The upshot is I'm not sure that this is really a good idea. Anybody who installs it will be horribly slowed. Anybody who runs a server will see a crapload of timeouts and dead requests. And any ISP that really cares about observing users can still easily do so.

Encryption is a really hard problem. The only thing worse than no encryption is encryption that doesn't work, as it leaves you worse off than when you started.


No comments:

- Jan 2014 (1) - Mar 2012 (1) - Nov 2011 (1) - Oct 2011 (1) - Apr 2011 (1) - Mar 2011 (3) - Feb 2011 (2) - Jan 2011 (9) - Nov 2010 (1) - May 2010 (1) - Mar 2010 (1) - Feb 2010 (1) - Jan 2010 (1) - Dec 2009 (1) - Nov 2009 (1) - Oct 2009 (1) - Sep 2009 (1) - Aug 2009 (2) - Jul 2009 (1) - Jun 2009 (4) - May 2009 (3) - Apr 2009 (3) - Mar 2009 (10) - Feb 2009 (5) - Jan 2009 (3) - Dec 2008 (5) - Nov 2008 (5) - Oct 2008 (5) - Sep 2008 (4) - Aug 2008 (5) - Jul 2008 (11) - Jun 2008 (8) - Feb 2008 (1) - Aug 2007 (1) -