FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 9:04 UTC (Thu) by richdawe (subscriber, #33805)
Parent article: Transport-level encryption with Tcpcrypt

It's not clear to me how this works with protocols like FTP which embed port-numbers into their commands. For protocols like FTP, I thought NAT devices had to rewrite the data within the protocol.

I'm guessing that FTP-over-tcpcrypt doesn't really work in the presence of NAT devices. How would the NAT device decrypt the data, rewrite FTP commands, and re-encrypt?

to post comments

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 9:15 UTC (Thu) by ilmari (guest, #14175) [Link] (7 responses)

Seeing as there is no authentication, the NAT device could do a man-in-the-middle "attack" on the control connection and de- and re-encrypt the traffic while rewriting it.

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 13:24 UTC (Thu) by djao (guest, #4263) [Link] (6 responses)

Tcpcrypt supports authentication, it's just not mandatory. This is not the same thing as no authentication. As I wrote in my first comment, I believe mandatory authentication is one of the biggest mistaken design decisions of all time.

But even when using an authenticated connection, tcpcrypt works with NAT. It accomplishes this feat by not encrypting or authenticating the port numbers. This design allows for some attacks (such as traffic analysis on port numbers), but the tradeoff seems to be worth it. The USENIX paper discusses this issue in some detail.

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 13:55 UTC (Thu) by ilmari (guest, #14175) [Link] (5 responses)

Not authenticating or encrypting port numbers still doesn't help when you need to inspect and rewrite port numbers and IP addresses in the payload of the packet, as with FTP (PORT and EPRT commands), IRC (DCC connections) and a whole bunch of other protocols (see the various conntrack modules in netfilter).

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 14:32 UTC (Thu) by djao (guest, #4263) [Link] (4 responses)

I thought my statement was pretty clear, but it seems that I'll have to clarify. Tcpcrypt does not encrypt or authenticate the portions of the TCP header in the IP payload that encode port numbers and IP addresses. Neither does the (optional) authentication portion of tcpcrypt rely on port numbers or IP addresses, which in any case are easily forged. Present-day encryption protocols such as SSL and SSH already work fine over NAT -- there's no inherent reason why NAT is incompatible with strong authentication or encryption.

Besides the conference paper, the protocol has been implemented on Windows/Mac/Linux, and the implementation itself is publicly available on the web site under the GPL. The implementation demonstrably works over NAT, and it works with FTP and IRC and DCC and all those other problem cases that you cite. I suggest taking a look at the working implementation rather than arguing about whether or not the software works.

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 15:31 UTC (Thu) by bboissin (subscriber, #29506) [Link]

See http://en.wikipedia.org/wiki/File_Transfer_Protocol#NAT_a...

some NAT routers modify the TCP *payload* to let active FTP connection work (same for DCC I guess). So if the content is encrypted there's no way for the router to modify the payload.

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 15:50 UTC (Thu) by imitev (guest, #60045) [Link] (2 responses)

I guess what ilmari had in mind is that there are protocols which give indication of port numbers in the *payload*.
In the case of FTP passive, you usually connect to port 21 (control channel), and if you up/down something (or even ls ?) the server replies (in the payload) with "ok, connect to port 12345" ; port 12345 is random and is for the data channel.

Now in the case of NAT, if you want - say - to match RELATED packets with iptables, you need the ftp conntrack helper which will *read* the payload/data for ftp connections (control channel) so that what would be a NEW connection to the data channel on the random port supplied by the ftp server is actually matched by the connection tracking logic, and labelled as RELATED.
Having the headers clear text doesn't help here, you really need to be able to read what's in the payload.

I may be wrong though, it's been a long time I dealt with that stuff.

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 16:02 UTC (Thu) by djao (guest, #4263) [Link]

Right, I didn't think about that. Thanks for the explanation.

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 17:05 UTC (Thu) by imitev (guest, #60045) [Link]

replying to myself: I mentioned NAT but it has nothing to do with matching RELATED connections, I mixed the nat helper and the conntrack helper.
Anyway, in both case you still need to read what's in the payload.

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 9:44 UTC (Thu) by jengelh (subscriber, #33263) [Link]

Incentive to use smarter protocols and programs then. Say, SCTP with its multistream feature, or foo-over-SSH2 transports like rsync does.

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 15:01 UTC (Thu) by sync (guest, #39669) [Link] (1 responses)

Like FTPS it doesn't work with NAT.
You have to use a sane protocol.

FTP with Tcpcrypt vs. NAT

Posted Aug 26, 2010 19:08 UTC (Thu) by RobSeace (subscriber, #4435) [Link]

Or, better yet, go for full sanity by just eliminating NAT... (Yeah, I know, it's not really possible in the current IPv4 world... I can't wait for IPv6, and hope that sounds NAT's death knell once and for good, though...)