The Grumpy Troll

Ramblings of a grumpy troll.

TCP FastOpen Security

A colleague recently enthused about TCP FastOpen being in the Linux kernel; being a grumpy old fart, this troll had ignored such things as always being security holes, such as T/TCP proved to be. So I just looked back over LWN’s article on the topic, to better understand why we might want to enable this on our webservers.

As far as I can see, if you have a path link where others can observe Server→Client traffic, but not influence its routing, and can inject packets without being subject to BCP 38 Network Ingress Filtering, then TCP FastOpen lets an attacker send data, using a purloined TCP cookie, and have it acted upon by a server without the server verifying that the stated IP really did send the traffic, bypassing source-bound security checks. Eg, using HTTP cookies which are bound to client IP, etc.

So given older cable modem networks, where the bulk of traffic from upstream is broadcast unencrypted over the last mile and relies upon cable modems using MAC filtering to keep the traffic from being visible to customer networks, any neighbour of a victim who uses the same Cable ISP and who has taken control of the cable modem in their home, can attack any TCP FastOpen site used by the victim.

DOCSIS 3, with encryption actually turned on, obviates this attack.

Similarly, open unencrypted WiFi networks share the same problem. If you are on the same open WiFi network as your victim, you can observe the L3 TCP cookies used to spoof opening a connection as from that victim, spoof source MAC and state on one single packet outbound through the WiFi network and take action as the victim.

So it seems as though it would be extremely unwise to enable TCP Fast Open on a webserver unless the site is HTTPS-only, with no authorisation cookies shared with HTTP modes, so that the application-layer cookies must be private to that end-user’s browser. Similarly, anyone considering deploying TCP Fast Open for non-HTTP protocols needs to be aware that connections can be maliciously opened from others and unless there’s something in-stream which the client needs to handshake and acknowledge, you’re more open to attack than you would be otherwise, as you don’t get the RST protection to detect a spoofed connection request.

It seems to boil down to “don’t enable TCP Fast Open on any service not protected by TLS or IPsec”.

Bemused,
-The Grumpy Troll