Main menu

Iran blocks Tor; Tor releases same-day fix

The short version: Tor relays and bridges should upgrade to Tor 0.2.2.33 or Tor 0.2.3.4-alpha so users in Iran can reach them again.

Yesterday morning (in our timezones — that evening, in Iran), Iran added a filter rule to their border routers that recognized Tor traffic and blocked it. Thanks to help from a variety of friends around the world, we quickly discovered how they were blocking it and released a new version of Tor that isn't blocked. Fortunately, the fix is on the relay side: that means once enough relays and bridges upgrade, the many tens of thousands of Tor users in Iran will resume being able to reach the Tor network, without needing to change their software.

How did the filter work technically? Tor tries to make its traffic look like a web browser talking to an https web server, but if you look carefully enough you can tell some differences. In this case, the characteristic of Tor's SSL handshake they looked at was the expiry time for our SSL session certificates: we rotate the session certificates every two hours, whereas normal SSL certificates you get from a certificateauthority typically last a year or more. The fix was to simply write a larger expiration time on the certificates, so our certs have more plausible expiry times.

There are plenty of interesting discussion points from the research angle around how this arms race should be played. We're working on mediumterm and longer term solutions, but in the short term, there are other ways to filter Tor traffic like the one Iran used. Should we fix them all preemptively, meaning the next time they block us it will be through some more complex mechanism that's harder to figure out? Or should we leave things as they are, knowing there will be more blocking events but also knowing that we can solve them easily? Given that their last blocking attempt was in January 2011, I think it's smartest to collect some more data points first.

It's too early to have cool graphs showing a drop in users and then the users coming back a day or so later. I'll plan to add these graphs once things play out more. [Update: here is the graph as of Sept 16]

Actually I remembered reading something about this but couldn't think where... cryptome.org. So, after re-reading that and checking out tor-talk I see you're aware of the problem.

So, how about setting some friendly hackers against those numerous IT/ES/BR/IL/... addresses to ID what they're running? Shouldn't take long at all, there's surely enough of 'em to find a sploit or two in... Hey, some of em' even host websites replete with nice convenient contact details... ;)

Sorry, just ain't gonna be running a bridge node like this. Threw up a monitor for a short while and logged around 16,000 inbound connection attempts in approx. 6 hours...

Thank you so much torproject.
Last time, I managed to reach tor network via proxy (Settings -> Network -> I use a proxy to access Internet) when they attempted to block Tor in january. This time it was different. I tried many anonymous , elite and transparent proxies with different ports but it did not work at all.

"you didn't had to spoil everything you did because the goverment is not idiot.
they will see this post and will think of new ways to filter the traffic."

Exactly what do you think the Iranian government will learn from this blog post, that they don't already know? It will be obvious to them that Tor has been updated, and it will be obvious to them how it has changed.

They're not idiots, so they don't need this post to think of new ways to filter the traffic — or to realize that we would change Tor to get around their filter, like we already did in January. At the same time, I think it's valuable to let our users know what's up, and to help other people working on circumvention tools (now and in the future) get a better sense of how these arms races play out.

Thanks for the quick reaction.
As to your question of what to fix preemptively, my take would be that the clues which allow a government to detect someone is using tor ought to fixed asap. If no such risks exist it may be smarter to wait and see.
FWIW

Yes, you'll be able to get it the same way as before (email gettor@torproject.org with 'windows' in the body of your message). The new Tor Browser Bundles aren't ready yet though -- stay tuned for a follow-up blog post.

If you're in Iran though, note that you don't actually need to upgrade to get your Tor working again. It's the relays that need to upgrade. At this point enough of them have upgraded that things should be working again on your side, even without the latest Tor.

The reason the Allies were able to continue breaking Enigma through WWII is because the Germans made incremental improvements. Had they done them all at one the Allies would have been screwed, would have been cut off from intelligence for a long period of time instead of many short periods, and may even have moved men to work on more fruitful ciphers.

Fixing all the flaws in Tor at once could deal such a set back to Iranian geeks that they may give up or lose funding and leadership support if they have no progress for a long period of time, while incrementally fixing them would keep them rewarded psychologically, bureaucratically and financially.

They could come up with something smart, but it seems like the incremental approach would at best delay the day that happens, and at worst keep more people working towards that day and thus ensure that day comes.

The problem with analogies is that unless it is the same problem, the same solution may not be the right one. The subtle difference in this case is for the Enigma it was finding the decryption key due to poor implementation by its users allowing the message to be decoded. If they implemented everything strongly from the start, or if they just used it properly, it would of taken much much longer to break.

In this case it is detecting non-standard messages are being used. They will look for things so subtle that the people behind tor might take months to figure out a way around, once all the easy methods are off. The technology to check out a timestamp in a certificate is much less complex then one that calculates entropy and other metrics.

Of course this discussion might be pointless, eventually these countries, since they don't believe in freedom, just cut off the Internet, work on a white list, or create there own private internet, which I hope the some long term solution will help mitigate this, although it is outside the scope of tor.

I sincerely believe that the Tor Project developers should approach this problem of future blocking of Tor traffic by government entities as if it were a game of poker. Don't show your hand, and keep good cards (patches) ready to use. Any theoretical weaknesses can have patches written for them and essentially fixed _now_, but to rule out weaknesses publicly by putting the patches out there immediately is doing some of the work for enemies of Tor. You can potentially make it frustrating and intimidating work to block Tor traffic by making them afraid of how much work must done until the Tor Project runs out of patches.

I must admit that I giggled a bit at the comments here. "Iran will do this", "Iran will do that", "Iran isn't stupid", etc.

In this cat and mouse game it's not Iran that we're playing against. We're playing against Iran's censorware vendors, our peers in silicon valley who frequent the same coffee shops and web-forums everyone else here does. I expect the person responsible for this blocking, the person who added the cert age check to some "enterprise" product with improbably high scale a few months back is reading this very post. I wonder if they even realize that we're talking about them?

It's probably futile to argue the ethics of this to the people who are responsible from the technology— burred behind N levels of sales and product management they feel no culpability or at least those who did self-selected them out of the business. So I'll skip the admonishment...

To those who remain, I'll just leave the reminder that playing both sides will not only improve the cause of civil rights without decreasing your income it will probably increase your income as your customers keep returning to you for the next half-assed step in the cat and mouse game.

It does appear whoever implemented that change on the border routers went for the low-hanging fruit. Whether this type of small issue are fixed now or later is essentially idempotent: the result is almost identical which ever order the changes are applied and the same conclusion will be reached fairly quickly.

I would assume there are more robust methods of filtering, which would be substantially more tricky to bypass. A naive approach would be to monitor all SSL/TLS connections then pass that list of IPs to a script that pulls the certificate chain from each SSL/TLS service; if the returned certificate chain is signed by a normal CA then it is put in the "accept" bin and if not, the "block" bin. After a few days, the corpus would reflect those IPs which are from normal websites/secure SMTP/etc and those which come from applications such as Tor. The actual filtering can be performed very quickly on the router as it is supplied as an IP list, i.e. no deep packet inspection required. I've seen far more difficult setups implemented within a few days at ISP level, so it cannot be too difficult. There are also a few reasonably easy counters to defeat that sort of construction (and I would imagine it may hurt businesses as well, so probably not a first-line option).

It looks like we're going to see a bit of an arms race going on. Having said that, I suspect the more insidious issue of side-channels will be what oppressive governments will focus on - something that is all together more difficult to protect against. These sort of blocking attempts are more likely implemented as a rough-and-ready means to reduce the amount of work they have to do.

I'd say wait for them to try to block you, then apply the fix. This would have the effect of driving them completely mad as well as waste their time, effort, and money. If you fixed everything first however, they'd have to expend less resources on blocking you next time. This whole matter is a bit of a war, and it's wise to make the battle more expensive for your enemy then it is for you.

thanks again.a problem that me and other friends have is that:tor bundle and it 's firefox portable version can't show and play flash contents!there is not any flash player plugin/active x installed!it is possible to add the latest version of flash player packed with tor bundle?thanks

we used to watch many videos of our green movemenet's against islamic murderer regime of iran in youtube
and now we can not watch this kind of videos in recent versions of tor
previously we can configure opera or ie to use with tor and this was our remedy for our problem

The newer versions of Tor do seem to have that kind of trouble, but there may be a workaround. Some stuff will not work with the HTTP proxy, but will work with the Socks proxy. You might want to look for a program like SocksCap or ProxyCap, configure it for your Socks proxy (which is 127.0.0.1, port 9050, unless you have changed any settings), and then have it make everything from your browser go through the Socks proxy.

Barring that, you can try and find an older version of Tor, which will allow streaming audio or video on the HTTP proxy.

Hi! There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.3.3.2-alpha from the usual place on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release some time in February.

Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.

Tor 0.3.3.2-alpha is the second alpha in the 0.3.3.x series. It introduces a mechanism to handle the high loads that many relay operators have been reporting recently. It also fixes several bugs in older releases. If this new code proves reliable, we plan to backport it to older supported release series.

Changes in version 0.3.3.2-alpha - 2018-02-10

Major features (denial-of-service mitigation):

Give relays some defenses against the recent network overload. We start with three defenses (default parameters in parentheses). First: if a single client address makes too many concurrent connections (>100), hang up on further connections. Second: if a single client address makes circuits too quickly (more than 3 per second, with an allowed burst of 90) while also having too many connections open (3), refuse new create cells for the next while (1-2 hours). Third: if a client asks to establish a rendezvous point to you directly, ignore the request. These defenses can be manually controlled by new torrc options, but relays will also take guidance from consensus parameters, so there's no need to configure anything manually. Implements ticket 24902.

Major bugfixes (netflow padding):

Stop adding unneeded channel padding right after we finish flushing to a connection that has been trying to flush for many seconds. Instead, treat all partial or complete flushes as activity on the channel, which will defer the time until we need to add padding. This fix should resolve confusing and scary log messages like "Channel padding timeout scheduled 221453ms in the past." Fixes bug 22212; bugfix on 0.3.1.1-alpha.