Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Add support for TCP Fast Open to prevent false negatives #1204
Nmap currently discards SYN-ACK packets having the TCP Fast Open option (RFC 7413) set. Thus leading to false negative results.
Running nmap with
In Wireshark, I saw that the TCP Fast Open option was enabled.
I know that TCP Fast Open option should not appear in SYN-ACKs if the option was not present in the prior SYN. However, this is what I observed on my client's network...
You can test it against the following scapy code, after preventing the default behavior of the kernel with
#!/usr/bin/python from scapy.all import * a=sniff(count=1,filter="tcp and host 127.0.0.1 and port 8000") TCP_SYNACK=TCP(sport=8000, dport=a.sport, flags="SA", seq=a.seq, ack=a.seq+1, options=[(34, "ABCDEF"),('MSS', 1460)]) # triggers false negative ANSWER=send(IP(src="127.0.0.1", dst="127.0.0.1")/TCP_SYNACK)
With the current nmap, you get:
And with the patch:
Thanks for this patch! I thought about this a while and decided that it's best that we do proper TLV checking for all TCP options except EOL and NOP (which are single-byte options). Doing it this way, there's no special case for Fast Open. The purpose of this function is to validate that known-length options have those lengths, and Fast Open is a variable-length option, so it can't really be checked in the same way. I just pushed an alternate change that does this, and I'll credit you with discovering the problem in the CHANGELOG.
…ailing validation. See #1204