New Name for Obfsproxy Tor Browser Bundles

Some days ago we released new Pluggable Transport Bundles which aim to
replace the old Pyobfsproxy/Flashproxy bundles and the even older
Obfsproxy bundles.

Users are encouraged to upgrade to the new bundles since they support
all the currently deployed pluggable transports and the latest
versions of Firefox and Torbutton.

The new bundles also contain the latest release of the Python version
of Obfsproxy, which replaces the legacy version that was written in C.

Finally, from now on Obfuscated bundles will be called "Pluggable
Transport Bundles" and each new version will contain all the deployed
pluggable transports. Users need to use http://bridges.torproject.org
to get bridges with pluggable transports ("obfuscated/obfsproxy
bridges") for their bundles.

Anon

March 22, 2013

Permalink

Thanks for the information, but Tor is only for anti-freedom script kiddies who want to try to hack and expose other Tor users, so I won't bother to upgrade.

Anon

March 23, 2013

Permalink

Well I for one appreciate the Tor Project's hard work and I'm enjoying the new Pluggable Transport Bundles. I like the new name better too.

Anon

March 25, 2013

Permalink

Should we use these Pluggable Transport Bundles even in places where we don't need bridges to connect to the Tor network?

That won't be necessary. The main point of this bundle is to circumvent censorship. It should make it very difficult for deep packet inspection boxes and other censorship systems to see that you are using Tor.

In that case, the pluggable transport bundle might be a start, yes.

Keep in mind, however, that a censor could still find out that you are using Tor. One way would be to actively probe suspicious connections and see what the server returns. The Great Firewall of China is known to do this. Another way would be to monitor flow information such as packet sizes. Tor traffic will exhibit many 568-byte packets. So by using pluggable transports, you make it more difficult but by no means impossible for a censor to see that you are using Tor.

So how likely would you say it is, for someone using the pluggable transport bundle to have the fact that she is using Tor detected by her (typical U.S.) ISP?

What about when using regular TBB with bridges?

And, how DOES it appear to an ISP when bridges are used?

Surely the traffic still must appear differently than ordinary traffic, no?

I have searched without success for this info.

That's difficult to answer because I don't know how interested U.S. ISPs are in detecting whether somebody is using Tor or not. As mentioned earlier, regular TBB traffic would be fairly easy to classify as Tor. Assuming somebody is actually interested in doing that. ISPs might not be.

And what is your understanding of "ordinary" traffic? Every application which interacts with a network tends to have a unique signature of some sort. Be it strings inside the payload, packet sizes, bursts etc. If you have the skill and resources, you can narrow down and identify almost anything. Highly undetectable/steganographic communication comes at the cost of very high overhead. Most pluggable transports trade off this (often unnecessarily) high security for more throughput and usability.

"And what is your understanding of "ordinary" traffic?"

That which does not go through Tor, a VPN or any other form of circumvention but over a direct connection to one's ISP. What the overwhelming majority of ISP subscribers do; the default.

As is well-known, all such traffic is logged by ISPs and can readily be viewed by them at any time.

"regular TBB traffic would be fairly easy to classify as Tor."

Yes, I understand that an ISP can easily see when someone connects directly to Tor (no bridge). I believe this is also the case for connecting to a VPN.

What I do not understand is what an ISP can see when one uses a bridge to connect to Tor.

Now, if I understood correctly what you wrote, it sounds to me that it's like this:

Traffic from someone who used Tor via a bridge would appear the same or very similar as that of someone who used a VPN-- on the surface. But closer inspection would reveal differences and if enough sufficiently expert inspection and analysis were done, Tor bridge users could be distinguished from VPN users.

Is that more or less accurate?

"I don't know how interested U.S. ISPs are in detecting whether somebody is using Tor or not."

Well, is there any reason to believe that any major U.S. (or U.K., Australia, Germany...) is/would be any better than the telcos in the wiretapping scandal were? IOW, happy to oblige the wishes of any powerful enough government entity.

Thank you very much for replying. Much appreciated.

down

03 03:54:43.019 [Notice] Your Guard 3VXRyxz67OeRoqHn=86FA348B038B6A04F2F50135BF84BB74EF63485B is failing to carry more streams on its circuits than usual. Most likely this means the Tor network is overloaded or your network connection is poor. Use counts are 45/58. Success counts are 101/207. 162 circuits completed, 22 were unusable, 39 collapsed, and 23 timed out. For reference, your timeout cutoff is 60 seconds.

why use python over c ?

Python makes it much easier and safer to write pluggable transport modules than C.

Anyone could make this bundle work behind a local/network proxy?

why the hell are you connecting to all the default bridges at start??? I have added the bridge obtained from BridgeDB at top of the list and still have compromised my entire connection because of that damn public list of bridges the bundle comes with. Someone could pay with his life, entire. Add the bloody .txt to PTB explaining what people are risking and how by default, wouldn't cost the whole router and the legs to someone who don't have the time to know how Vidalia is behave with Bridges. Censorship here comes after the first fault that is all these default IPs at once!