Tcpcrypt is a protocol that attempts to encrypt (almost) all of your network traffic. Unlike other security mechanisms, Tcpcrypt works out of the box: it requires no configuration, no changes to applications, and your network connections will continue to work even if the remote end does not support Tcpcrypt, in which case connections will gracefully fall back to standard clear-text TCP. Install Tcpcrypt and you'll feel no difference in your every day user experience, but yet your traffic will be more secure and you'll have made life much harder for hackers.
- Intercepting communications today is simpler than ever because of wireless networks. Ask a hacker how many e-mail passwords can be intercepted at an airport by just using a wifi-enabled laptop. This unsophisticated attack is in reach of many. The times when only a few elite had the necessary skill to eavesdrop are gone.
- Computers have now become fast enough to encrypt all Internet traffic. New computers come with special hardware crypto instructions that allow encrypted networking speeds of 10Gbit/s. How many of us even achieve those speeds on the Internet or would want to download (and watch) one movie per second? Clearly, we can encrypt fast enough.
- Research advances and the lessons learnt from over 10 years of experience with the web finally enabled us to design a protocol that can be used in today's Internet, by today's users. Our protocol is pragmatic: it requires no changes to applications, it works with NATs (i.e., compatible with your DSL router), and will work even if the other end has not yet upgraded to tcpcrypt—in which case it will gracefully fall back to using the old plain-text TCP. No user configuration is required, making it accessible to lay users—no more obscure requests like "Please generate a 2048-bit RSA-3 key and a certificate request for signing by a CA". Tcpcrypt can be incrementally deployed today, and with time the whole Internet will become encrypted.
How Tcpcrypt works
Tcpcrypt is opportunistic encryption. If the other end speaks Tcpcrypt, then your traffic will be encrypted; otherwise it will be in clear text. Thus, Tcpcrypt alone provides no guarantees—it is best effort. If, however, a Tcpcrypt connection is successful and any attackers that exist are passive, then Tcpcrypt guarantees privacy.
Network attackers come in two varieties: passive and active (man-in-the-middle). Passive attacks are much simpler to execute because they just require listening on the network. Active attacks are much harder as they require listening and modifying network traffic, often requiring very precise timing that can make some attacks impractical.
By default Tcpcrypt is vulnerable to active attacks—an attacker can, for example, modify a server's response to say that Tcpcrypt is not supported (when in fact it is) so that all subsequent traffic will be clear text and can thus be eavesdropped on.
Tcpcrypt, however, is powerful enough to stop active attacks, too, if the application using it performs authentication. For example, if you log in to online banking using a password and the connection is over Tcpcrypt, it is possible to use that shared secret between you and the bank (i.e., the password) to authenticate that you are actually speaking to the bank and not some active (man-in-the-middle) attacker. The attacker cannot spoof authentication as it lacks the password. Thus, by default, Tcpcrypt will try its best to protect your traffic. Applications requiring stricter guarantees can get them by authenticating a Tcpcrypt session.
How Tcpcrypt is different
Some of us already encrypt some network traffic using SSL (e.g., HTTPS) or VPNs. Those solutions are inadequate for ubiquitous encryption. For example, almost all solutions rely on a PKI to stop man-in-the-middle attacks, which for ubiquitous deployment would mean that all Internet users would have to get verified by a CA like Verisign and have to spend money to buy a certificate. Tcpcrypt abstracts away authentication, allowing any mechanism to be used, whether PKI, passwords, or something else.
Next, Tcpcrypt can be incrementally deployed: it has a mechanism for probing support and can gracefully fall back to TCP. It also requires no configuration (try that with a VPN!) and has no NAT issues. Finally, Tcpcrypt has very high performance (up to 25x faster than SSL), making it feasible for high volume servers to enable encryption on all connections. While weaker by default, Tcpcrypt is more realistic for universal deployment.
We can easily make the bar much higher for attackers, so let's do it. How much longer are we going to stay clear-text by default?
