Measuring Tor and Iran

I've been fielding some calls from the press about Tor and Iran. Someone quoted me as saying "double the clients from Iran over the past few days". We wondered, what are the real numbers? What does our network see from Iran? Is port 443 or https:// really blocked? Here's what we've discovered in the past day of working with the new metrics we've developed to be safe to collect without compromising anyone's anonymity.

This first dataset is from one of the Directory Authorities. We have six authorities, so a plausible scaling factor is 6, assuming all authorities are seeing equal requests (it could be more or less than 6, too). We don't know if the authorities are seeing equal requests, as they listen on different TCP ports, are located in different parts of the world, and clients will chose one randomly. This graph roughly shows the number of requests from new Tor clients coming from IP addresses that our geoip database reports as Iran.

UPDATE 2009-06-24: Updated the graph with numbers through yesterday

The second dataset is from one Directory Mirror, of which there are hundreds. This mirror is only accessible on port 443, which is rumored to be blocked in parts of Iran over the past few days.

The data points in the second graph are very rough, since they're an estimate of the total number of Tor users in Iran based on numbers from only one relay. In addition, we looked at some other relays running on port 443, and they also didn't show anywhere near the spike that we see in the directory authority graph above. The authority isn't listening on 443 -- perhaps that means there's some truth to the rumors that port 443 has been blocked recently in Iran. We look forward to having more precise data later on.


September 18, 2010


A few questions and potential answers:

Bad Guys == Anyone blocking or monitoring a persons access to knowledge

Q: What is to stop operatives working for the bad guys from running tor proxies from 3rd party locations? Granted, they would only be able to sample a portion of the traffic, but traffic that they did sample could lead to identification of users. It doesn't seem like it would be that hard to match up the encrypted client side requests with the un-encrypted outgoing requests.

PA: The only solution I can think of here is centralized control of the proxy network provided by a press/media sponsorship model as opposed to the bandwidth volunteer model. It's to easy for bad guys to infiltrate the volunteer network. It would also be easier to swap in and out new proxies as they are blocked. runtime selection of alternative proxy networks would be a nice feature.

Q: I have noticed lists like: that appears to be a list of tor proxies. What's to stop the bad guys from blocking the entire proxy database? My understanding is that countries like Iran have the national ISP market under their thumb.

PA: There needs to be a way to deal out proxies to clients without the ability to easily reveal the entire network to anyone. Perhaps even semi-static assignments similar to DHCP. Of course, there is also the problem of 'blocking the dealer' similar to the P2P security issues with trackers. Ultimately, to really make this fool proof, there would need to be a way to communicate proxy dealers offline (verbally / off-network) in a concealable way.

Q: How can we address bad guys blocking port 443.

PA: Proxies should be able to hide behind other services such as 25,80,110. Also nice would be a 'spoof greeting' feature that would simulate a 'normal' service for that port before a magic code was sent. Of course, the magic code would need to be changeable (possibly dynamically by a proxy dealer).

Q: What about DPI which can provide encryption protocol info to the bad guys (if not the payload).

PA: plug-in packet obfuscation, possibly agreed upon between proxy and dealer and embedded in a magic code given by the dealer to the client then provided back to the proxy in the request header. This could be implemented by means of a tiny secure VM that ran small byte-code obfuscator programs shared between proxy and dealer and referenced by the magic code. Even though the bad guys could run the VM de-obfuscator, it would be challenging to implement at OSI levels 1-4 given current technology.

The ultimate idea would be to keep the Bad Guys busy chasing their tails and break them through over investment in competence. As they attempt to keep up with the changing methodologies they become victims of their own system of control, meanwhile they have less time to do their normal bad guy stuff. Basically, the circumvention tool itself becomes an agent provocateur.

This would be a fine email to the or-talk mail list, but unfortunately you wrote it on our blog.

At a minimum, you should read our FAQ, where most of these questions are already answered. See

You may also want to read through the active project list,, some of your PA's are already under way with a more advanced design than one can put into a FAQ style paragraph.

Agreed, sorry for the laziness, I posted this on or-talk. If you feel it's better not to have this here, please feel free to delete this post.


January 29, 2011


At the time of this writing Tor is unaccessible here in iran and all of its ports are
blocked .
I was thinking can Tor ( privoxy ) use a well known port like 21 for FTP instead of
other ports like 8080 ? This is possible if Tor is not giving FTP service to users ,
that way they can't block port 21 , because FTP service will be blocked for all users .
However it's not a big deal for iranian regime to block FTP in the whole country .
Iranian users better know what i'm talking about . lol