Tor offers SSL obfuscation for users behind censorship walls

On February 10, the Tor project posted reports from users inside Iran that the country's government had begun blocking all SSL/TLS traffic, a major escalation of firewall policies that had already cut off users from specific services. Tor responded by pointing readers to obfsproxy, its comparatively-little-known project that can disguise SSL traffic to evade detection by the deep packet inspection (DPI) filters used to flag and shut down encrypted connections.

Word from users in Iran was that the government SSL-blocking effort appeared to be DPI-based, because of the fact that connections were being terminated only after the first few steps of the SSL handshake. Other methods to bypass the firewall, including VPNs, were still functional, although they are an impractical (and sometimes expensive) solution for the majority of Iranian Internet users. However, the block prevents standard Tor usage in particular, because the system relies on an encrypted connection between the user's machine and the first relay in the Tor network.

Earlier filtering techniques, such as blocking access to specific IP addresses, had been bypassed by using bridges — Tor relays that ran on unpublished IPs. Reports indicated that the SSL-block varies by ISP, and had not affected the entire country, but the project's metrics showed a sharp decline in the number of Tor users originating from Iran, starting around February 9. Alongside the announcement of obfsproxy, the Tor project asked users to help restore connectivity for people in the region by setting up obfuscated bridges — but cautioned that drawing too much public attention to the project could prompt authorities to implement countermeasures.

It rolls right off the tongue: "obfsproxy"

Obfsproxy — which, although just announced to the public, has been in development since early 2011 — offers relief from DPI filtering. It is a transport proxy that encapsulates protocol traffic between endpoints within an "innocent-looking" wrapper. The system is modular enough that the project says it can be used with a variety of protocols, but the default usage is designed to wrap SSL traffic between a Tor client and Tor bridge inside another application-layer connection. Furthermore, within those faux application-layer packets, the genuine SSL packets are encrypted by a stream cipher, making their contents immune to detection by DPI filters (which catch protocols by matching characteristic strings or regular expressions in the TCP stream).

Obfsproxy's default module is called obfs2, and merely disguises SSL traffic as unencrypted SOCKS traffic. It does not itself provide authentication, confidentiality, or guarantee data integrity. Those features must be provided by the traffic being obfuscated (e.g., SSL and Tor). Nor does it protect against protocol fingerprinting using other means (such as timing or packet size), nor against attackers looking specifically for obfsproxy itself. The threat model document in the project's Git repository outlines the assumptions and characteristics in specific detail, and argues that although the scope is limited: it "protects against many real-life Tor traffic detection methods currently deployed, since most of them currently use static SSL handshake strings as signatures."

Tor executive director Andrew Lewman told Forbes magazine that other protocol wrappers are a possibility for future releases, including XMPP and vanilla HTTP, and described a simpler client-side interface. At the moment, however, he described the project as "very much a work in progress, and the various pluggable transports are still in design and development."

The anatomy of obfs2

Obfsproxy is a recent addition to Tor, and although the project has released updated Tor Browser Bundle binaries pre-configured to use it, for most existing Tor users it requires compiling and running the client code — as well as knowledge of a Tor bridge also configured to run obfsproxy. Still, Tor reports that users in Iran are taking advantage of the code to successfully restore their lost connectivity.

Masking a Tor connection between client and bridge requires both participants to be running obfsproxy, but the client-bridge connection is the only one involved in the obfuscation — no general-purpose Tor nodes (including exit nodes) are required to install obfsproxy or need to alter their configuration.

Interested client and bridge users should fetch obfsproxy from the Tor project's Git repository and compile it with Autogen and GNU make. All versions of Tor newer than 0.2.3.11 can be configured to use obfsproxy simply by editing the Tor configuration file. Clients must add the IP address and port number of an obfsproxy-aware bridge and path to the obfsproxy executable. Bridge operators must start Tor and watch their logs, because Tor randomly selects an open, higher-numbered TCP port for obfsproxy to listen on the first time it is run. Older versions of Tor can use obfsproxy, too, using additional steps to configure a localhost-only relay between Tor and the obfsproxy program.

Whichever setup is involved, the obfs2 protocol operates in the same manner. It is based on Bruce Leidl's older work to obfuscate SSH handshakes. The client and the bridge first exchange session keys with each other, after which they "superencipher" their SSL session by encrypting it with 128-bit AES.

By default the protocol uses a relatively weak key-exchange method that could be compromised by an eavesdropper listening to both sides of the conversation — although the use of a pre-shared secret to strengthen this step is supported as well. It may sound as if the weak key exchange method undermines the whole process, but the important thing to remember is that the obfuscation protocol's only goal is to defeat automatic detection by pattern-matching DPI filters. Furthermore, the seed values that the client and bridge exchange are concatenated with constants and then hashed with SHA256, a step that does not make them unrecoverable, but that is computationally expensive to perform on the class of high-throughput networking hardware generally used to do DPI traffic analysis.

Obfuscation for all

To the paranoid, obfs2 may sound like an imperfect solution to the filtering crisis. After all, it could be defeated by closer inspection of packets or filtering out SOCKS traffic. In that sense, obfsproxy might be likened to steganography — its goal is to hide the traffic of estimated tens-of-thousands of Tor users in a censored region like Iran among the connections of millions.

The Tor project reports that it has performed experiments of its own, and found obfsproxy to be effective "in all censored countries" when used as-is. However, as Jacob Appelbaum mentioned in the call for obfsproxy bridges, "it might even only last for a few days at the rate the arms race is progressing, if you could call it progress." Then again, thanks to the modular design of obfsproxy, the obfs2 module itself can be replaced or upgraded in future releases, both to disguise traffic better, or to implement completely different security features. The sudden crackdown on all SSL traffic in Iran might have hit before a perfect system was in place, but obfsproxy is still a welcome relief for those who are affected, and have no other practical options.