New Tor Release Fixes De-Anonymization Attack

The Tor Project has released a new version of its client software to fix a serious vulnerability that allows an attacker to strip users of their anonymity on the network. The new version also includes a number of other security and privacy fixes.

The attack that enables the anonymity stripping requires a specific set of conditions to be in place and the new version of Tor removes two of those components from the equation, which is enough to prevent the attack. It relies on the fact that user clients will reuse their TLS certificates when connecting to different Tor relays, which can enable an attacker to identify a specific user by his certificate.

"The attack relies on four components: 1) Clients reuse their TLS cert when talking to different relays, so relays can recognize a user by the identity key in her cert. 2) An attacker who knows the client's identity key can probe each guard relay to see if that identity key is connected to that guard relay right now. 3) A variety of active attacks in the literature (starting from "Low-Cost Traffic Analysis of Tor" by Murdoch and Danezis in 2005) allow a malicious website to discover the guard relays that a Tor user visiting the website is using. 4) Clients typically pick three guards at random, so the set of guards for a given user could well be a unique fingerprint for her. This release fixes components #1 and #2, which is enough to block the attack; the other two remain as open research problems," the Tor Project's Roger Dingeldine said in a message announcing version 0.2.2.34.

Dingeldine said in the message that, as far as the Tor Project officials know, the attack that's fixed in this release isn't related to the one publicized by researcher Eric Filiol earlier this week. The fix for the de-anonymization attack involves preventing clients from sending the TLS certificate chain on outbound connections. There are a variety of other security and privacy fixes in the new version of Tor.

Among the other fixes:

- If a relay receives a CREATE_FAST cell on a TLS connection, it no longer considers that connection as suitable for satisfying a circuit EXTEND request. Now relays can protect clients from the CVE-2011-2768 issue even if the clients haven't upgraded yet. - Directory authorities no longer assign the Guard flag to relays that haven't upgraded to the above "refuse EXTEND requests to client connections" fix. Now directory authorities can protect clients from the CVE-2011-2768 issue even if neither the clients nor the relays have upgraded yet. There's a new "GiveGuardFlagTo_CVE_2011_2768_VulnerableRelays" config option to let us transition smoothly, else tomorrow there would be no guard relays. o Privacy/anonymity fixes (bridge enumeration):

- Bridge relays now do their directory fetches inside Tor TLS connections, like all the other clients do, rather than connecting directly to the DirPort like public relays do. Removes another avenue for enumerating bridges. Fixes bug 4115; bugfix on 0.2.0.35. - Bridges relays now build circuits for themselves in a more similar way to how clients build them. Removes another avenue for enumerating bridges. Fixes bug 4124; bugfix on 0.2.0.3-alpha, when bridges were introduced.

- Bridges now refuse CREATE or CREATE_FAST cells on OR connections that they initiated. Relays could distinguish incoming bridge connections from client connections, creating another avenue for enumerating bridges. Fixes CVE-2011-2769. Bugfix on 0.2.0.3-alpha.