[ http://lwn.net/Articles/401943/ ] [ http://tcpcrypt.org/draft-bittau-tcp-crypt.txt ] [ http://tcpcrypt.org/tcpcrypt-slides.pdf ]
Interesting development. One potential problem may be how the application/system handles connections that switch between plain-text and tcpcrypt-encrypted ones during a session (possible man-in-the-middle attack): do you alert the user and if so, how? ===== Transport-level encryption with Tcpcrypt By Jake Edge August 25, 2010 It has been said that the US National Security Agency (NSA) blocked the implementation of encryption in the TCP/IP protocol for the original ARPANET, because it wanted to be able to listen in on the traffic that crossed that early precursor to the internet. Since that time, we have been relegated to always sending clear-text packets via TCP/IP. Higher level application protocols (i.e. ssh, HTTPS, etc.) have enabled encryption for some traffic, but the vast majority of internet communication is still in the clear. The Tcpcrypt project is an attempt to change that, transparently, so that two conforming nodes can encrypt all of the data portion of any packets they exchange. One of the key benefits that Tcpcrypt offers is transparency. That means that if both endpoints of a connection support it, the connection will be encrypted, but if one doesn't support Tcpcrypt, the other will gracefully fall back to standard clear-text TCP/IP. No applications are required to change, and no "new" protocols are required (beyond Tcpcrypt itself, of course) as applications will send and receive data just as they do today. [...] One of the basic premises that underlies Tcpcrypt is that computers have gotten "fast enough" to handle encrypting all internet traffic. Doing so at the transport level, rather than in application protocols (e.g. ssh), can make it transparent to applications. In addition, Tcpcrypt can work through NAT devices, which is something that another lower-layer encryption protocol, IPSec, cannot handle. Because Tcpcrypt keys are short-lived, non-persistent public/private key pairs, it does not require the public key infrastructure (PKI) that other solutions, like HTTPS, need. That means that endpoints can communicate without getting certificates signed by centralized authorities. Of course the existing PKI certificates will work just fine on top of Tcpcrypt. [...] ===== -- Soh Kam Yung my Google Reader Shared links: (http://www.google.com/reader/shared/16851815156817689753) my Google Reader Shared SFAS links: (http://www.google.com/reader/shared/user/16851815156817689753/label/sfas) _______________________________________________ LUGS Mailing list - [email protected] List FAQ: http://wiki.lugs.org.sg/LugsMailingListFaq Info page: http://www.lugs.org.sg/mailman/listinfo/slugnet To unsubscribe send an empty email to: [email protected]
