Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[tcpcrypt-dev] tcpcrypt userland tests 3 and 6 fail

Daniel Kahn Gillmor dkg at fifthhorseman.net
Wed Jul 23 10:06:16 PDT 2014


On 07/23/2014 01:20 AM, Andrea Bittau wrote:
> 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.

OK, i think i can confirm that the "middlebox" in question was the kvm
userspace networking translation layer (which makes sense, since it
wouldn't be capable of setting TCP options as a non-privileged user on
the forwarded traffic).

I've successfully used the latest build of tcpcrypt now from the network
here at IETF-90.

> The good news is that tcpcrypt wouldn't cause your internet to die -
> i.e., it gracefully fell back to vanilla TCP.

yep, that's a sensible approach.

> 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?

i think that's reasonable for now.  we should talk about what you think
the right packaging strategy should be.  I'm thinking the approach
should be something like (these are sequential steps):

 0) create one package, tcpcrypt with just tcpcryptd and tcnetstat and
libtcpcrypt.so.0 and test/tcpcrypt, without any sort of system
initialization. To do this, it would be really nice to have some
documentation, even if just simple manpages.  i can write up some pod if
that would be useful and we can feed it through pod2man, or we could add
--help and --version options to the executables directly and use help2man.

 1) create a tcpcrypt-dev package that has a libtcpcrypt.so symlink  and
the header files (and maybe tcs) -- this package will help people who
want to link their tools into libtcpcrypt.

 2) create a systemd .service file and/or a sysvinit script which sets
up the iptables-based redirection.

 3) look into packaging the kernel modules (for debian, this is likely
to be a dkms [0] source package).  I expect this to come later -- we can
focus on the userspace tools first.

note that debian also has two ports that use the freebsd kernel -- i'm
not sure what the right approach to packaging tcpcryptd on that
platform, it may take a bit of gymnastics.

Any suggestions or concerns?

	--dkg

[0] https://wiki.debian.org/KernelDKMS

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.stanford.edu/pipermail/tcpcrypt-dev/attachments/20140723/981e8b79/attachment.asc>


More information about the tcpcrypt-dev mailing list