The reason behind the "nnCoection" HTTP header | Hacker News Reader

The reason behind the "nnCoection" HTTP header

forums.aws.amazon.com

93 pointsthere8 comments

Those "misspelled" Connection headers (nnCoection, Cneonction, X-Cnection, etc) are used by load balancers (Citrix NetScaler, F5 BIG-IP, etc).

IMHO better explanation is available here: http://support.f5.com/kb/en-us/solutions/public/6000/900/sol...

I work for Citrix Netscaler, and can confirm this. It is the most efficient of invalidating one of the standard headers.

There has to be more processing done than the simple 'it adds up' explanation because of a number of problems.

1. The TCP checksum is a 16-bit checksum so you can't simply permute the characters in Connection and always expect to get the same answer.

2. The position at which Connection starts may not be on a 16 bit boundary and thus the permutation would have to take into account this positioning.

3. The header could be split across packets making this much harder.

In the example given nnCoection makes sense because the 16-bit words nn and Co have been swapped which will not alter the checksum as long as Connection was starting on a 16-bit boundary.

1) False, CRC does not detect byte shuffling

2) TCP is a byte oriented protocol, so there is no endian or word boundary problems.

3) Nothing is going to split a IP package between the backend servers and and the frontend balancer, where the later sees the "Connection". If something between the balancer and the client splits, it is its problem to recompute the new CRC

TCP doesn't use a CRC, it uses the algorithm described in RFC 1071 (http://www.ietf.org/rfc/rfc1071.txt) which relies on ones-complement summing of 16-bit word values. Thus the position at which Connection appears does matter, as does the swapping of characters.

I really love these abuses of TCP. Over the weekend I setup my router to do TCP proxying, and I noticed that a lot of sites do not emit valid TCP streams (making them inaccessible to machines behind the router). Metafilter, in particular, emits a valid stream if the page is not cached (like submitting an article), but it's hit or miss if the page is cached.

Presumably this is because the load balancer hijacks the raw TCP connection, but is not smart enough to use valid sequence numbers:

http://readlist.com/lists/openbsd.org/misc/9/45511.html

The side effect of the Internet violating the TCP standard is that TCP becomes a lot less resistant to man-in-the-middle attacks. And, my firewall has to deal with various strange things, like packets in the middle of a TCP stream that have a TTL such that they don't get routed, but do affect the firewall's state table. But hey, at least your load balancer doesn't have to establish two TCP connections! Imagine the latency that would introduce!

This is actually really annoying. The same thing happens with isohunt.com, at least, if I disable the scrub feature of my PF firewall I can get to isohunt.com, if I enable the scrub feature I can no longer get to isohunt.

Now, like you mentioned there seem to be quite a few sites that are doing this. It irks me that this abuse of TCP/IP happens which makes it harder to write proper firewalling software and rules.

Yeah. I wish people would use UDP instead of misusing TCP.

Yes, the three-way-handshake involves an extra round-trip. Yes, ACKs introduce latency. So don't use TCP. :)

Reply on news.ycombinator.com