https://eta.securesslhost.net/~pgpboar/viewtopic.php?f=2&t=416&p=588&sid=bbfa23d8538371baaee609c88ff45761#p588

TOR: Bug Doors In TOR's SSL Layer

by altaylor

Mar 21, 2011

by: Anon

Note* Anon continues his tour of engineered bug doors in TOR. In this overview anon describes the vulnerabilities in TOR's SSL layer, and how anyone with access to DPI technology could identify TOR users. He goes on to show how with just two lines of Linux code were enough to completely log then block all Tor traffic. (AT)

This is a follow-up to the previous disclosure of Tor's Diffie-Hellman vulnerability. [1] This memo examines a whole new array of vulnerabilities, this time in Tor's SSL layer. Editors note ( http://bit.ly/gAdHZq )

Firstly, a quick background on SSL, and specifically SSL 'certificates'. SSL stands for ''Secure Sockets Layer'' and is the de facto protocol for establishing a secure communication channel between a server and a client on the web. Gmail, PayPal, etc., all depend on SSL to secure their customers' communications. Central to the SSL protocol are SSL Server Certificates (a.k.a. X.509 certificates). When a client wishes to open a secure communications channel (e.g. HTTPS) with a server, it requests that server's SSL Server Certificate during the initial 'handshake', which contains various meta-data. For more information, see [2]. The important point here is that this certificate is sent unencrypted.

For example, when visiting the TorProject.org website, the server presents you with an SSL Server Certificate with the 'Common Name' field set to '*.torproject.org' -- the asterisk being a wild-card, meaning that this certificate is valid for any sub-domain under torproject.org, such as 'gitweb.torproject.org', 'blog.torproject.org', and so on. Readers may see the contents of this certificate themselves using the 'ngrep' tool [3] on a Unix machine, as follows:

# ngrep -d eth0 DigiCert

where 'eth0' is the network device in use. After issuing this command, navigate to https://check.torproject.org/ in a web browser. The ngrep tool will then dump to the terminal any traffic containing the keyword DigiCert (which is the issuer of the Tor Project's SSL Server Certificate).

What does this have to do with Tor? Tor uses SSL to secure communications between Tor nodes and clients. When a Tor client wishes to connect to a Tor node (including 'bridge' nodes), the node presents the client with an SSL Server Certificate. The problem is that the Common name field in this certificate is literally gibberish. The Tor node fills this field with a domain name generated at random, i.e. one that does not actually exist. For example, a typical Common Name field in a Tor node SSL Server Certificate could be ''www.s4ku5skci.net.'' If one were to try to resolve this domain (e.g. using the command 'nslookup http://www.s4ku5skci.net'), an error would be returned, since this is not a real domain name. Recall that SSL Server Certificates are sent unencrypted on the wire -- before an encrypted connection is established.

This behaviour (filling certificate fields with gibberish) is unique to Tor, i.e. no other SSL-capable server software does this; not Apache or any of its derivatives, not Microsoft's IIS, not Oracle's iPlanet... Even self-signed SSL Server Certificates (used by people who cannot afford one signed by a Certificate Authority) typically contain either an IP address in the Common Name field, or an empty Common Name field.

Therefore, all an ISP or government observer would need to do to unmask Tor traffic is to look for connections where SSL Server Certificates are being sent (this is trivial with DPI technology [4]), attempt to resolve the domain(s) in the Common Name field, and if that fails, mark that connection as being Tor traffic, or block it altogether. Moreover, Common Name fields in Tor SSL Server Certificates all begin with 'www.' and end with '.net'. This sort of traffic analysis is based on long established techniques that have been used to fight spam, [5] and are trivially adapted to identifying Tor traffic.

Tor's Draft Proposal 179 [6] goes on to enumerate many other ''bug-doors'' in Tor's SSL mechanism. Tor users and governments alike are encouraged to read that document. Here's a hint to the Tor developers (and other interested parties): randomization in Tor SSL Server Certificate fields will only make Tor stand out even more than it already does, i.e. Proposal 179 merely replaces one set of bugs with even more obvious ones. Furthermore, even if Tor manages to spoof legitimate SSL Server Certificates for all its nodes, active (as opposed to passive) traffic analysis using rDNS will see right through them.

As with previous ''bug-doors,'' [1] the contents of Proposal 179 were no secret to any of the developers. In fact, this is a vulnerability Freegate successfully planned and currently defends against. Yet no attempt to inform Tor users was ever made, even after this proposal was put in writing, and once this proposal is implemented, the changes will probably be referred to as ''minor feature enhancements'' in the official documentation. Note the pattern; Tor has a long history of non-disclosure of such critical vulnerabilities.

This is yet another example of why Tor is not safe for those users who would want to keep the fact that they are using Tor a secret. The ''bug-doors'' documented in Proposal 179 are not even the most egregious. Consider the technical report titled ''Design of a blocking-resistant anonymity system,'' dated November 2006, compiled by Roger Dingledine and Nick Mathewson, head developers of Tor. [7] In it, they state:

''Right now Tor uses some predictable strings in its TLS handshakes. For example, it sets the X.509 organizationName field to ''Tor'', and it puts the Tor relay's nickname in the certificate's commonName field.''

That's right -- circa 2008 and prior, Tor software would actually mark its own SSL Server Certificates with the keyword 'Tor' in the Organization Name field, for the world to see. Any government with access to DPI technology at the time -- American, European, Chinese, and even the Iranian government (c.f. [8,9]) -- knew exactly who was using Tor and when, by simply looking for the keyword 'Tor'. In fact, at the time, two simple Linux firewall commands were enough to completely log then block all Tor traffic (including to/from super-duper secret 'bridge' nodes) on any network:

# sudo iptables -D INPUT -m string --algo bm --string Tor -j DROP
# sudo iptables -D INPUT -m string --algo bm --string Tor -j LOG

Is it still any wonder why the Egyptian Facebook-averse revolution succeeded, when the Iranian Haystack-and-Tor-phile Green Movement failed and continues to fail miserably?

[1] https://eta.securesslhost.net/~pgpboar/viewtopic.php?f=2&t=415&p=587&sid=3ce4e2bc13a6e12e15f6a5fc239958ed#p587
[2] https://secure.wikimedia.org/wikipedia/en/wiki/Secure_Sockets_Layer
[3] http://ngrep.sourceforge.net/
[4] https://secure.wikimedia.org/wikipedia/en/wiki/Deep_packet_inspection
[5] http://www.spamhaus.org/faq/answers.lasso?section=ISP%20Spam%20Issues#131
[6] https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/179-TLS-cert-and-parameter-normalization.txt
[7] https://gitweb.torproject.org/erinn/tor.git/blob_plain/d245d413a94e97e65cd882aa43dc4af4b440f940:/doc/design-paper/blocking.pdf
[8] http://news.bbc.co.uk/2/hi/technology/8112550.stm
[9] http://online.wsj.com/article/SB124562668777335653.html

eof

Alan Taylor
PGPBOARD Administrator
London, England