Search Mailing List Archives
[tcpcrypt-dev] tcpcrypt userland tests 3 and 6 fail
bittau at cs.stanford.edu
Tue Jul 22 22:20:36 PDT 2014
great - if the code works properly, it basically means that the CRYPT
option was stripped by a middlebox on your SYN to our check server.
err 670 means that tcpcrypt was expected, but you got a plain-text TCP
connection back. Flags 0 means that the server did not see the SYN
CRYPT option (it got stripped along the way). This should be more
human readable, I know.
The good news is that tcpcrypt wouldn't cause your internet to die -
i.e., it gracefully fell back to vanilla TCP.
The implementation is now super aggressive and disables tcpcrypt if
all tests don't fully pass. Maybe I should change the code to disable
tcprypt only if tcpcrypt fully fails: e.g., connections HANG rather
than being downgraded. What do you think?
You can disable network tests with -f
We are very interested in the results of these tests and hence why we
need deployments. It will basically tell us whether tcpcrypt ever
breaks something. The IETF was concerned that if you send non-HTTP
traffic on port 80 middleboxes will drop it. The good news however
seems to be that middle boxes strip unknown options (like in your
case), so tcpcrypt falls back gracefully to TCP without hanging. The
more data we gather the better.
On Tue, Jul 22, 2014 at 10:09 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> I've built tcpcrypt in a demo system running debian unstable on amd64
> (x86_64) from git commit f319e3e6ecd0159be949177fce0c0dc1b659dcfc. But
> i get the following error from the launch_tcpcryptd.sh:
> root at sid:/home/dkg/src/tcpcrypt/tcpcrypt/user# ./launch_tcpcryptd.sh
> Tcpcrypting port 80 and 7777...
> iptables -I INPUT -p tcp --sport 80 -j NFQUEUE --queue-num 666
> iptables -I OUTPUT -p tcp --dport 80 -j NFQUEUE --queue-num 666
> iptables -I INPUT -p tcp --dport 7777 -j NFQUEUE --queue-num 666
> iptables -I INPUT -p tcp --sport 7777 -j NFQUEUE --queue-num 666
> iptables -I OUTPUT -p tcp --dport 7777 -j NFQUEUE --queue-num 666
> iptables -I OUTPUT -p tcp --sport 7777 -j NFQUEUE --queue-num 666
> Testing network via 18.104.22.168
> No timestamp provided in packet - expect low performance due to calls to gettimeofday
> Test result: port 80 crypt 0 req 0 state 3 err 0 flags 0
> Test result: port 80 crypt 0 req 1 state 3 err 0 flags 0
> Test result: port 80 crypt 1 req 2 state 2 err 670 flags 0
> Test result: port 7777 crypt 0 req 0 state 3 err 0 flags 0
> Test result: port 7777 crypt 0 req 1 state 3 err 0 flags 0
> Test result: port 7777 crypt 1 req 2 state 2 err 670 flags 0
> Tests done! 3 6 failed [2/6]!
> Disabling tcpcrypt for 30 minutes
> Any recommendations for what would be a useful next steps for debugging?
> tcpcrypt-dev mailing list
> tcpcrypt-dev at lists.stanford.edu
More information about the tcpcrypt-dev