The Obfuscated TCP Project

Hello, Jeff Forristal here. In my last post I talked about the desire of some folks to use SSL for encryption purposes but forego the authentication components (via the use of self-signed SSL certificates). Overall it’s not a very good idea, since removing authentication from the process renders the benefit of the encryption moot for all but the most trivial (and lazy) threat vectors (passive eavesdropping).
So earlier this week I ran across a mention of the Obfuscated TCP project (a.k.a. ObsTCP), developed by Adam Langley of Google. The project is self-described as:
Obfuscated TCP is a transport layer protocol that adds opportunistic encryption. It's designed to hamper and detect large-scale wiretapping and corruption of TCP traffic on the Internet.
This sounds like an ideal potential alternate for all of those who wish for an 'encryption without (expensive public CA certificate-based) authentication' solution. The ObsTCP idea is simple: use light-weight and fast encryption functions to obfuscate all TCP data streams, in an effort to thwart passive eavesdropping. Processors are fast enough these days that the additional overhead to perform the data obfuscation is negligible. And (from my interpretation of the project’s documentation), the idea isn’t to be cryptographically secure transport and/or replace SSL…it’s just to obfuscate TCP data enough to make passive eavesdropping difficult to do. We are already seeing similar approaches deployed via P2P clients to bypass ISP-based throttling based on packet/protocol inspection; the obfuscation employed isn’t robust to survive a targeted cryptographic attack, but it is enough to make high-speed protocol detection and classification difficult. The project has produced a video (hosted on Youtube) that goes over the basic goals and reasoning behind them.
Looking at the project's history, the original intent seems to be for ObsTCP to be added into the TCP/IP protocol stack (ISO layer 4) for transparency. However, apparently the ObsTCP project approached the IETF with a draft, and, ... well ..., it got a chilly reception. So ObsTCP changed gears and instead moved up the stack to the application layer (ISO layer 7), and is now focusing on HTTP as their first high-value protocol target. So the original project description of ObsTCP being a "transport layer protocol" is a bit misleading when considered in the context of the project's new implementation direction.
So how does ObsTCP work? Well, it requires an ObsTCP-capable client and server. The server admin essentially embeds the server's public key (and some meta information) in a DNS entry related to the server. The client retrieves the server's public key, opens a connection to the ObsTCP port of the server, and then uses a Diffie-Helman authentication exchange to negotiate a key to use for subsequent encryption. Right now the project is offering proof-of-concept patches for Firefox browser, and Apache and lighttpd web servers to make them ObsTCP-capable. They also offer an ObsTCP-to-normal-TCP proxy which can be placed in front of TCP services to make them ObsTCP-capable.
Overall, how does ObsTCP compare against the threat vectors previously listed in my "SSL encryption without authentication debate" post? We already mentioned that passive eavesdropping would be thwarted, as that's the purpose of ObsTCP to begin with. But what about a more active man-in-the-middle (MitM) attack? My cursory review of the ObsTCP documentation and design indicates that it does not directly mitigate that specific threat vector—however, it does make it harder for an attacker to pull off. This is because the server's public key is distributed via DNS, separate from the TCP connection. That means an attacker has to intercept both DNS request and the TCP connection in order to successfully pull of a MitM attack. Further, the DNS records can be cached at various points around the Internet, making it further difficult for the attacker to spoof a DNS response. The attacker would likely have to employ separate specific DNS attacks (such as the recent Kaminsky brouhaha) just to inject the right info into DNS in order for the TCP intercept/MitM to correctly work. The amount of effort and coordination to pull this off is far greater than a single TCP intercept/MitM attack by itself.
Overall the ObsTCP project is in alpha stages, but the idea is intriguing. It does seem to fill a need that is growing and becoming more vocalized (i.e. encryption without authentication). It will be interesting to see whether the project becomes adopted enough to start gaining public traction and attention. We figure it will be the usual circular catch-22 situation often encountered with new Internet technology: server admins forego deploying the technology because not enough clients support it, and clients forego implementing the technology because not enough servers support it. Oh well, it’s still a good idea.
- Jeff