Iran gets one-up on online dissent?
Published: March. 18, 2011 at 5:43 PM
LONDON, March 18 (UPI) -- Iran appears to have developed a system for identifying
computer users on a network designed to block surveillance, a member of the Tor
Tor software, distributed free, hides computer IP addresses and encrypts e-mail and
other communication on the Internet. The software was originally developed at a U.S.
military lab and is now open source.
Andrew Lewman, Tor's executive director, said Iran apparently has obtained Deep
Packet Inspection, equipment that allows the reading of Internet traffic as it is
transmitted. He said Tor has known for years it was vulnerable but did not take steps to
thwart that type of technology in advance.
"We're trying to have an arms race really slowly," he said.
Lewman said the number of Tor users in Iran more than doubled to 2,800 after the 2009
presidential election. Mahmoud Ahmadinejad's election to a second term was widely
perceived as fraudulent and it set off a wave of protest in Tehran and some other cities.
Iran now appears to have advanced a step beyond China in its ability to track or block
dissidents online, Lewman said.
TOR: Bug Doors In TOR's SSL Layer
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.  This memo
examines a whole new array of vulnerabilities, this time in Tor's SSL layer. Editors note (
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 . 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  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
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
), 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,  and are trivially
adapted to identifying Tor traffic.
Tor's Draft Proposal 179  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,''  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.  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
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?
 < viewtopic.php?f=2&t=415&p=587&sid=3ce4e2bc13a6e12e15f6a5fc239958ed#p587 >
 < https://secure.wikimedia.org/wikipedia/ ... kets_Layer >
 < http://ngrep.sourceforge.net/ >
 < https://secure.wikimedia.org/wikipedia/ ... inspection >
 < http://www.spamhaus.org/faq/answers.las ... Issues#131 >
 < https://gitweb.torproject.org/torspec.g ... zation.txt >
 < https://gitweb.torproject.org/erinn/tor ... ocking.pdf >
 < http://news.bbc.co.uk/2/hi/technology/8112550.stm >
 < http://online.wsj.com/article/SB124562668777335653.html >
WIKILEAKS: AppelBaum: How TOR Has Been Crippled Described
by : Anon
Note* This post received from Anon, describes vulnerabilities engineered into TOR.
Two months ago, the Iranian government dealt a strong blow to Tor. A breakdown follows.
Tor claims that their software protects users in two ways: i) Tor protects your communications
from ``traffic analysis;'' and ii) Tor provides ``anonymity.'' Neither of these is true, but the latter
is where the Iranian government chose to strike, and is the subject of this memo.
Tor uses a public key exchange protocol called Diffie-Hellman  to establish an initial
encrypted connection between the user and an ``entry node.'' However, the parameters to this
exchange -- which are sent unencrypted on the wire -- were chosen to be those defined as the
``Second Oakley Group'' (RFC 2409). No other web software uses these parameters. Thus, if
traffic on the wire is observed to be communicating these parameters, it is almost certainly
traffic generated by Tor. In other words, the use of these specific parameters is a unique
signature which identifies Tor traffic from all other encrypted traffic. And this, in a nutshell, is
how the Iranian government caused Tor usage in Iran to plummet from 10,000 users per day, to
zero -- overnight.  Note that the Diffie-Hellman parameters in Tor were since updated to
match those used by the most popular web server on the Internet (Apache), between versions
0.2.1.29 and 0.2.1.30 of the stable branch. 
What does this mean for Tor users in Iran? It means the Iranian government knows exactly who
was using Tor in Iran -- and at exactly which times. The contents of the communications remain
purportedly secure, but the fact that the communication took place is established, which in
itself could be a death sentence in Iran. The Iranian government chose to use the information
about Tor's traffic signature to block it -- a more patient government would have not have
blocked Tor, but simply logged the identities and times of Tor users' access to the network.
A hacker employed by the Tor Project, ``phobos,'' has since admitted in no uncertain terms that
this particular vulnerability in Tor has been known ``for years,'' but that a decision had been
made that it would remain unpatched  -- until now. Now that the Iranian government had
begun exploiting it publicly. It is interesting to note that the developer assigned to tune Tor's
Diffie-Hellman parameters in order to un-block Tor in Iran is Jacob Appelbaum -- a hacker who
recently garnered criticism for urging fellow hackers to insert ``bug-doors'' in their software.
This logically leads to the question of whether this serious vulnerability was one such ``bug-
door,'' patched only when another government begins exploiting it...
 < https://secure.wikimedia.org/wikipedia/en/wiki/Diffie%E2%80%93Hellman_key_exchange
 < https://blog.torproject.org/blog/update-internet-censorship-iran>
 < https://gitweb.torproject.org/tor.git/blob/release-0.2.1:/ChangeLog#l26 >
 < https://blog.torproject.org/blog/update-internet-censorship-iran#comment-8848 >
Appelbaum: TOR U.S. Spent Millions On Compromised Anonymity Software
Photo: Andrew Lewman Executive Director TOR project: aka "phobos"
Note* Maria Technosux has identified the hacker "phobos" as Andrew Lewman, Executive
Director of TOR. See: http://maria-technosux.livejournal.com/173870.html it was phobos who
indicated that the vulnerability described here: http://bit.ly/gAdHZq had been known for years,
yet no attempt had been made to fix it. This included the time slot during which the US
Government was increasing funding in order to provide extended anonymity support for Iranian
WASHINGTON - The Obama administration is poised to dramatically increase funding aimed at
helping Iranian activists circumvent government controls on the Internet, according to
Congressional aides, marking a new wave of US support for Web-based dissent at a time when
the Iranian regime has clamped down on street protests. The funding, which is set to double
from $15 million in 2009 to $30 million next year for Iran and other countries that block free
speech on the Internet, puts the US government in an unlikely alliance with counterculture
computer activists - some of them in the Boston area - who have launched spirited volunteer
efforts to help Iranian reformers.
The new funds, part of a budget proposal that Congress is slated to approve, could be a windfall
for nonprofit organizations that provide Iranians with ways to view websites blocked by the
regime, for software developers who train dissidents on how to e-mail in ways that cannot be
traced, and for Iranian activists living outside the country who have launched Web-based
forums on strategic protests, democracy, and human-rights violations.
But the funding increase has raised eyebrows on Capitol Hill, where some in Congress question
whether the effort is consistent with Obama’s stated goals of engaging, rather than
antagonizing, the Iranian regime. Iran, which has repeatedly accused the United States of trying
to engineer a revolution inside its borders, cracked down on street demonstrators protesting
the results of a June 12 election that kept President Mahmoud Ahmadinejad in power. The
proposal for additional US money for Internet activities predated the unrest.