Security [LWN.net]

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. But there is an additional benefit available for those applications that are willing to change: strong authentication.

Tcpcrypt has the concept of a "session ID" that is generated on both sides as part of the key exchange. This ID can be used in conjunction with a shared secret, like a password, to authenticate both ends of the communication. Because the client and server can exchange cryptographic hash values derived from the shared secret and session ID, they can be assured that each is talking over an encrypted channel to an endpoint that has the key (password). A "man in the middle" would not have access to the password and therefore can't spoof the exchange.

Even without any application changes for stronger authentication, Tcpcrypt would defend against passive man-in-the-middle attacks, like eavesdropping. Active attacks could still spoof responses that said Tcpcrypt was not supported, even if the other endpoint did support it, or even relay encrypted traffic. That would still be better than the usual situation today where a passive attacker can gather an enormous amount of clear-text traffic, especially from unencrypted or weakly encrypted wireless networks.

There is an Internet Engineering Task Force (IETF) draft available that describes how Tcpcrypt works by using two new TCP options. Those two options, CRYPT and MAC, will not be recognized by endpoints without Tcpcrypt support, and are therefore harmless. The CRYPT option is used to negotiate the use of Tcpcrypt and to exchange encryption keys, while the MAC option carries a hash value that can be used to verify the integrity of the packet data.

In addition to the IETF draft, the project has produced a paper, The case for ubiquitous transport-level encryption [PDF], that was presented at the 2010 USENIX Security conference. It gives a somewhat higher-level look at how Tcpcrypt integrates with TCP/IP, while providing a lot more information on the cryptographic and authentication algorithms. The slides [PDF] from the presentation are also instructive.

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.

While computers may be "fast enough" to handle encryption on every packet, there is still the problem of asymmetry. Servers typically handle much more traffic than clients, so Tcpcrypt is designed to put the most difficult parts of the key negotiation and encryption onto the client side. The claim is that speeds of up to 25x that of HTTPS (i.e. SSL/TLS) can be achieved by Tcpcrypt. One wonders whether mobile devices are "fast enough", but that problem—if it even is one—is probably not one for that much longer.

Overall, Tcpcrypt is an intriguing idea. It certainly isn't a panacea for all of today's network ills, but that is no surprise. Unlike other proposals, Tcpcrypt can be incrementally deployed without requiring that we, somehow, restart the internet. Since it won't break existing devices, it can be developed and tested within the framework of the existing net. If for no other reason, that should give Tcpcrypt a leg up on other potential solutions.

Comments (49 posted)

Brief items

Security quotes of the week

DRE (direct-recording electronic) voting machines are ones where voters cast their ballots by pressing buttons or using a touch screen, and the primary record of the votes is stored in a computer memory. Numerous scientific studies have demonstrated that such machines can be reprogrammed to steal votes, so when we got our hands on a DRE called the Sequoia AVC Edge, we decided to do something different: we reprogrammed it to run Pac-Man.

-- J. Alex Halderman

The Indian government has refused to let [researchers] review the machine, and insists that it's tamper-proof. Even after the initial report came out proving this not to be the case, the government has continued to insist the machines are fine and have no problems. Here in the US, it's quite troubling how much the government has relied on e-voting machines without allowing security researchers to really test them, but at least they don't arrest those who have been able to access and test the machines. This is a hugely troubling move by the Indian government, and hopefully getting more attention on such a questionable arrest will make the Indian government regret this decision -- and open up the machines for real security testing.

-- Mike Masnick on the arrest of an Indian security researcher

Of course, doing so just turns it from "Running code as X gives you root" to "Running code as X gives you root the moment someone types in a root password, even if they're on a different terminal". I accept that this is a barrier, but the only real solution is to have each X session run as a different user - and that requires Linux to gain revoke() support.

-- Matthew Garrett on why X still runs as root

Comments (2 posted)

New vulnerabilities

acroread: arbitrary code execution

Package(s):

acroread

CVE #(s):

CVE-2010-2862

Created:

August 20, 2010

Updated:

September 1, 2010

Description:

From the Red Hat advisory:

This update fixes a vulnerability in Adobe Reader. This vulnerability is detailed on the Adobe security page APSB10-17, listed in the References section. A specially-crafted PDF file could cause Adobe Reader to crash or, potentially, execute arbitrary code as the user running Adobe Reader when opened.

Alerts:

openSUSE	openSUSE-SU-2010:0573-1	2010-09-01
SUSE	SUSE-SA:2010:037	2010-09-01
Red Hat	RHSA-2010:0636-02	2010-08-20

Security

Transport-level encryption with Tcpcrypt

Security quotes of the week

acroread: arbitrary code execution

cacti: multiple vulnerabilities

freeciv: arbitrary command execution

kernel: multiple vulnerabilities

kvm: denial of service

moin: cross-site scripting

moodle: multiple vulnerabilities

mozilla: denial of service

openoffice.org: denial of service

php: multiple vulnerabilities

phpMyAdmin: cross-site scripting

qspice: denial of service

qspice-client: man-in-the-middle vulnerability

spice-xpi: symlink vulnerability

uzbl: arbitrary command execution

zabbix: cross-site scripting

zope-ldapuserfolder: authentication bypass