Pluggable transports bundles 2.4.17-beta-2-pt3 with Firefox 17.0.9esr
There are new Pluggable Transports Tor Browser Bundles with Firefox 17.0.9esr. They are made from the Tor Browser Bundle release of September 20 and contain important security fixes.
- Windows (sig)
- Mac OS X (sig)
- GNU/Linux 32-bit (sig)
- GNU/Linux 64-bit (sig)
The bundles contain flash proxy and obfsproxy configured to run by default. If you want to use flash proxy, you will have to take the extra steps listed in the flash proxy howto.
These bundles contain the same hardcoded obfs2 bridge addresses as the previous bundles which may work for some jurisdictions but you are strongly advised to get new bridge addresses from BridgeDB.
Comments
Please note that the comment area below has been archived.
I could never get the obfs2
I could never get the obfs2 bridge addresses to work, even the ones I got from the BridgeDB. It's always stuck on trying to establish an encrypted connection.
In China, last I checked,
In China, last I checked, they DPI for obfs2 connections, do active folllow-up probes, confirm that they're obfs2 bridges, and block them.
And they don't do that to obfs3 (currently).
Hi, I am using
Hi,
I am using 0.2.4.17-rc-beta2 and noticed following behaviour, if this is a bug can someone open a ticket?
I start tor, works perfectly, then I stop it and watch how tcp connections slowly die in my iptables. I restart, works fine. During the day I repeat this start stop few times, always I look that iptables are clear. But at some point my router goes unresponsive during stopping relay. I think it cant be a circuit storm, while I have a living tcp connection to my router. I watch online how tcp connection live....
I have repeated this four times, always the same issue. Am i the only one or can someone else reproduce the problem?
This sounds like a bug in
This sounds like a bug in your router, not a Tor bug. The Tor behavior is simply "uses your router more actively than it was expecting".
See also
https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#Mycabledslmode…
why are we still using obfs2
why are we still using obfs2 if it has proven to be easily defeated?
It works everywhere but
It works everywhere but China currently.
And there are a lot more obfs2 relays out there than obfs3 relays.
The game isn't just about DPI-resistance but also about address variety.
This shouldn't be about
This shouldn't be about DPI-resistance and "not being blocked". This should be about not being identified in the first place. Blocked may mean almost identified. If you are blocked even once (in China, etc.), how soon before the close monitoring/investigation starts?
Re: so few obfs3 bridges:
From the operator point of view, do the obfs3 bridges have some known drawbacks, comparing to the regular ones?
If not, why not advertising the obfs3 bridge need, promoting and influencing the bridge operators more actively?
Mention the advantages and post the links to the obfs3 version anywhere the normal version is downloaded.
Make some incentives to run obfs3 bridges. Especially if/when anybody ever gets funding for running the relays.
For those operators preferring the stable version and simply staying away from the alphas, perhaps there should be a stable version featuring obfs3 (not to replace all stables, but offer a healthy choice).
These are just quick thoughts. Others may have other and better obfs-promoting ideas.
In the age of the global govt-spying, obfs bridging may be arguably the best implementation of Tor. Something probably can be done to focus on it more. Please look at what can be done.
Having a transport that
Having a transport that blends in even when somebody is looking for it is quite a bit tougher. For example, neither obfs2 nor obfs3 is going to protect you from somebody doing packet timing and volume analysis to realize that it's Tor underneath. Similarly, Flashproxy does a websockets handshake and then it's just vanilla Tor flow after that.
I encourage everybody to get involved in the research field -- and there are a huge number of interesting papers on anonbib about it -- but it is far from solved.
Why not make ALL TBBs
Why not make ALL TBBs pluggable transport?
I'd like to get to that
I'd like to get to that point eventually.
You might like https://trac.torproject.org/projects/tor/ticket/8019
Why do all/most of the obfs
Why do all/most of the obfs bridges run on the unusual 5-digit ports? It seems like the operators are construed to using them.
To me, that just helps identifying the connections. E.g., why not the obfs bridge appearing to be the the mundane HTTPS on port 443?
Aside from disappearing in a sea of the HTTPS connections, it will also help those who's corporate firewalls allow only ports 80 and 443.
Please help us solve
Please help us solve https://trac.torproject.org/projects/tor/ticket/7875
Tails is great, highly
Tails is great, highly recommended!
Firefox is configured to use
Firefox is configured to use a proxy server that is refusing connections.
Sounds like maybe you have
Sounds like maybe you have an over-jealous antivirus that is preventing local applications from talking to themselves.
i use http proxy to connect
i use http proxy to connect to my network
i used the required settings but the following message was displayed:
Vidalia was unable to apply your Network settings to Tor.
Unacceptable option value: You have configured more than one proxy type. (Socks4Proxy|Socks5Proxy|HTTPSProxy|ClientTransportPlugin)
when I seleced Http/https from the dropdown menu. please help.
Your problem is that
Your problem is that pluggable transports don't support proxy settings.
That is, the pluggable transport *is* your proxy from Tor's perspective, and there isn't any way currently for Tor to tell the pluggable transport to use a proxy of its own.
See https://trac.torproject.org/projects/tor/ticket/8402 for progress (but there hasn't been progress lately, so it could use your help!)