Tor Browser 3.5.2.1 is released

The 3.5.2.1 release of the Tor Browser Bundle is now available on the Download page. You can also download the bundles directly from the distribution directory.

This release fixes the localization of the non-english bundles.

Please see the TBB FAQ listing for any issues you may have before contacting support or filing tickets. In particular, the TBB 3.x section lists common issues specific to the Tor Browser 3.x series.

Here is the list of changes since 3.5.2. The 3.x ChangeLog is also available.

  • All Platforms
    • Bug 10895: Fix broken localized bundles
  • Windows:
    • Bug 10323: Remove unneeded gcc/libstdc++ libraries from dist
Anonymous

February 15, 2014

Permalink

nice fixing, hopefully the darknet will recover over time again after most sites are sadly gone for now :´(

Anonymous

February 15, 2014

Permalink

How do you disable the automatic updates? There's no longer a simple option to do that either, or are they automatically disabled now?

In your browser:

Edit » Preferences » Advanced » Update » Never check for updates (not recommended: security risk)

There seem to be a problem with the (New update) notice.

Firstly (TorBrowser updates:) are disabled by default when installing a new version
wich i think (Check for updates, but let me choose whether to install them) should be enabled by default.

Secondly, i never got any notice about the latest update about: Tor Browser 3.5.2.1
release. Only found this release because i keep myself regulary updated on this blog.

Hope you found this answer helpful, best regards

Anonymous

February 15, 2014

Permalink

What I don't understand, is how do you guys/gals released a update that was so obviously broken? Do you not fully test the builds before you release them?

I guess Tor people will just ignore my question, eh? Not like it would take more than 2 minutes for someone to describe the QC testing before each release.

But, I guess taking 2 minutes out of their life to let people know they're doing their job correctly is asking too much . . . sigh.

I guess it's far better to release a broken update then to describe how such a broken update was released, eh?

Hole in sand . . . meet Tor people . . . their head is looking for a place to locate.

If I knew I wouldn't have asked, twice.

There is only one passing mention of a ticket about this being Mozilla's fault. Nice to blame someone else, I guess. Mr. Perry stated they don't check for this issue.
https://trac.torproject.org/projects/tor/ticket/10895

I don't like relying *only* on the automated tests for TBB. Before each release is published at least *one* TBB team member person build it and test it out *themselves*.

I've been using Tor for more than 10 years, and I can count on (at least) one hand all the times TBB has been released in a *broken* state. That's really quite poor history of broken releases.

BTW, I'm the person who came up with the idea for TBB and I'm the first one to start creating it, then Mr. Murdock took over and created the first TBB. I'm also the person that came up with idea for updating TorButton (from it's original state years ago; during the Privoxy Tor years), and I started hacking on the original TorButton but I'm not good, so Mike took over.

A perfect example of this issue of continually releasing broken TBB's is *me* telling Mike over a period of 3 TBB releases that it's broken for Windows (TBB 3.0). And I even told Mike the changes that had to be made in TBB's Firefox. We'll, he didn't seem to care and it took me and lots of other people bitc*ing about it before Mike fix the issue. This was the issue when the new TBB 3.0 would start on Windows only to show a blank window.

And one time Mike even tried to claim a bug was a feature! When the TBB 3.0 wouldn't show the windows theme. Ugh.

I admire Mike _a lot_, I think he's a hero, but I also really dislike the way TBB gets released in a BROKEN, and how Mike is quite arrogant at times when he doesn't want to admit something is broken.

is google analytics blocked in torbrowsetbundle?

perhaps as a js file, Google analytics is already blocked by noscript.

otherwise, the lightest way to block the 3 (?) Google analytics domains is to put the domains into HOSTS file http://msmvps.com/blogs/hostsnews/

google-analytics.com
ssl.google-analytics.com
www.google-analytics.com

does Tor us the hosts file? that would be a risk?

Tor does not use /etc/hosts, no. (That would imply asking the local resolver to do dns resolution for you, and it's too hard to predict what your local resolver would do.)

Tor connects ok, but try to check status, or visit torproject and instantly get

Firefox can't establish a connection to the server at check.torproject.org.

or

Firefox can't establish a connection to the server at www.torproject.org.

why?

What antivirus/firewall? Try to disable firewall functional for test.

I can access torproject pages on the clearnet, just not through the TBB. Tor isn't blocked by my vc. I can access the onion sites, just not Tor (or google) the search facility on the TBB main page also bombs out.

TOR=NSA

Anonymous

February 17, 2014

In reply to by Anonymous (not verified)

Permalink

Your ALU is broken. Those strings are different.

Hi there, I'm having problem connecting to tor network using the latest TBB. The browser just stuck at 'connecting to directory server' stage.Strangely TBB 3.5.0 works fine on this computer, but both TBB 3.5.2 and TBB 3.5.2.1 won't connect.

All three bundles using exactly the same settings (bridges,port, etc). I checked the log file, and found the following lines of interest:

Feb 16 15:02:08.000 [warn] We were supposed to connect to bridge '173.246.104.81:45698' using pluggable transport 'obfs3', but we can't find a pluggable transport proxy supporting 'obfs3'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
Feb 16 15:02:08.000 [debug] channel_change_state(): Changing state of channel 00EA3C68 (global ID 0) from "opening" to "channel error"
Feb 16 15:02:08.000 [info] circuit_handle_first_hop(): connect to firsthop failed. Closing.
Feb 16 15:02:08.000 [info] circuit_build_failed(): Our circuit died before the first hop with no connection
Feb 16 15:02:08.000 [info] connection_ap_fail_onehop(): Closing one-hop stream to '$0000000000000000000000000000000000000000/173.246.104.81' because the OR conn just failed.
Feb 16 15:02:08.000 [debug] circuit_increment_failure_count(): n_circuit_failures now 1.
Feb 16 15:02:08.000 [info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
Feb 16 15:02:08.000 [info] connection_ap_make_link(): ... application connection created and linked.
Feb 16 15:02:08.000 [debug] connection_add_impl(): new conn type Directory, socket -1, address 173.246.104.81, n_conns 6.
Feb 16 15:02:08.000 [debug] fetch_bridge_descriptors(): ask_bridge_directly=1 (1, 1, 0)
Feb 16 15:02:08.000 [debug] directory_initiate_command_rend(): anonymized 0, use_begindir 1.
Feb 16 15:02:08.000 [debug] directory_initiate_command_rend(): Initiating server descriptor fetch
Feb 16 15:02:08.000 [info] connection_ap_make_link(): Making internal direct tunnel to [scrubbed]:47456 ...
Feb 16 15:02:08.000 [debug] connection_add_impl(): new conn type Socks, socket -1, address (Tor_internal), n_conns 7.
Feb 16 15:02:08.000 [debug] circuit_get_open_circ_or_launch(): considering 1, $0000000000000000000000000000000000000000
Feb 16 15:02:08.000 [debug] onion_pick_cpath_exit(): Launching a one-hop circuit for dir tunnel.
Feb 16 15:02:08.000 [info] onion_pick_cpath_exit(): Using requested exit node '$0000000000000000000000000000000000000000~0000000000000000000 at 23.239.140.214'
Feb 16 15:02:08.000 [debug] onion_extend_cpath(): Path is 0 long; we want 1
Feb 16 15:02:08.000 [debug] onion_extend_cpath(): Chose router $0000000000000000000000000000000000000000~0000000000000000000 at 23.239.140.214 for hop 1 (exit is 0000000000000000000000000000000000000000)
Feb 16 15:02:08.000 [debug] onion_extend_cpath(): Path is complete: 1 steps long
Feb 16 15:02:08.000 [debug] circuit_handle_first_hop(): Looking for firsthop '23.239.140.214:47456'
Feb 16 15:02:08.000 [info] circuit_handle_first_hop(): Next router is [scrubbed]: Not connected. Connecting.
Feb 16 15:02:08.000 [debug] channel_tls_connect(): In channel_tls_connect() for channel 00EA3C68 (global id 1)

Feb 16 15:03:36.000 [info] compute_weighted_bandwidths(): Empty routerlist passed in to consensus weight node selection for rule weight as guard
Feb 16 15:03:36.000 [info] smartlist_choose_node_by_bandwidth(): Empty routerlist passed in to old node selection for rule weight as guard
Feb 16 15:03:36.000 [info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)

I've been posting to both blogs and stack exchange for a few days, am still waiting for a response. Please, someone with technical background take a look at the logs and figure out what's going on with my TBB, any input would be greatly appreciated.

PS: I use win XP SP3 with all necessary patches, Kapasky AV. And I need to stress that TBB 3.5.0 works fine, but both TBB 3.5.2 and TBB 3.5.2.1 won't connect. That rules out network and hardware issues. All bundles passed the signature check.

Are you tries to use obfs3 bridge with non Pluggable Transport bundle? Working 3.5 was Pluggable Transports-capable TBB (pt-bundle) actually?

For those of us who were using TBB 3.5.2 before 3.5.2.1 was released, was our anonymity compromised?

As far as I can tell, this is not a mandatory update. Neither bug it fixes appears to be critical from a security POV. Nowhere in the release announcement does it say that "all users must" or "are strongly urged" "to upgrade as soon as possible". So, based on all appearances, those not affected can stay with 3.5.2.

I do think this should have been explicitly stated, though.

AOL Mail is not working in any of these recent releases. I tried many ways. But it is working in older version of Tor Bundle. Please check and update. Thanks.

This ticket does not exist at the point of posting this.

Yes it does -- but paste it in without the period at the end.

I think we should incorporate vidalia, so it would be easier for people to ride a relay :/

Is there a way to make Tor reconnect without closing the browser or chosing new identity?

if my connction suddenly drops i need always to wait until tor reconnects from alone.

Doesn't refreshing a page or loading new page revive the connection?

I recall that 2.x tbb would show disabled vidalia in systray (windows). "Waking" the dormant vidalia would noticeably delay page loading.
Now in 3.5.x, if I return to activity, there may be only a slight delay before new page loads, but loading seems far faster than when waking dormant vidalia in tbb 2.x.
Also my software firewall would popup alerts when 2.x awoke, but firewall does not popup alerts when 3.5 returns to activity after long inactivity.
3.5.x seems to never "fall asleep" like 2.x did.

I appreciate all of the efforts that go into this product / service, but have to say that I find it very disconcerting when comments and questions go for 3 days without answers. I understand that this is not a 24/7 help / paranoid rant hotline, but I hope you understand that browser updates are emotional events to many - as much time gets spent on understanding the 'why' behind the update and the 'what' in terms of what are/were my vulnerabilities. Enough with my human element concern...

My technical concern is with how ticket 10419 was resolved. I did my homework in an attempt to address my own concern, but I do not understand how
https://trac.torproject.org/projects/tor/ticket/10419
was resolved. Even after also reading
https://trac.torproject.org/projects/tor/ticket/10682

Neither have a statement on how they were ultimately resolved. How can I verify if there is not a statement on how the issue was closed?

What was the fix for ticket 10419? The primary discussion seems to note that...
---------------------------------------------------------------------------------
# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny
---------------------------------------------------------------------------------
...rule is already in NoScript and just needs to be enabed with noscript.ABE.enabled = true. My ABE shipped **DISabled**.

As I said, there is cross over with ticket 10682 which is also closed to just a reference to a repository - not an explanation as to how fixed.

Please help.

I'm not a TOR developer so this is a non-authoritative answer, but if you look further down the discussion, Mike Perry says he wants to avoid using NoScript to fix #10419 if at all possible, and whether emptying "network.proxy.no_proxies_on breaks CUPS" (which it doesn't apparently). I would infer from this that that was the fix. If you want to be able to use proxies on 127.0.0.1, see gk's comments 37 & 38 for how to change this setting (but note the caveat about potential fingerprinting risks).

Thanks. I am not interested in using TCC to configure local services and agree with Ticket 10419 comment that this is not the purpose of the tor browser. I, however, want to know that Ticket 10419 was resolved such that a site can't use connection attempts or element loads sourced for 127.0.0.1, as was

I read three solutions offered in ticket. I see none implemented in TBB 3.5.2.1 to support closing the ticket.

The no-Proxy solution was not implemented:
user_pref("extensions.torbutton.no_proxies_on", ""); ====>>>No
user_pref("extensions.torbutton.saved.no_proxies_on", ""); ====>>>No
user_pref("network.proxy.no_proxies_on", ""); ====>>>No

The ABE solution was not implemented:
noscript.ABE.enabled = true ====>>>No

Same for...
add "127.0.0.1" to the *no_proxies_on preferences in about:config ====>>>No

This was marked as a critical ticket and I see nothing to indicate that it is fixed.

Thank you.

Upon further review, I see how this was fixed. In earlier versions of TBB, prefs.js listed 127.0.0.1 against the network.proxy.no_proxies_on preference. The key word in the discussion is 'emptied', so 127.0.0.1 was emptied from the no_prox preference.

I appreciate your assistance, apologize for time spent on this, but still offer that clearer ticket resolution statements would save time for all. ;)

Thanks.

  1. <a href="https://www.ssllabs.com/ssltest/analyze.html?d=torproject.org[/geshifilter-code" rel="nofollow">https://www.ssllabs.com/ssltest/analyze.html?d=torproject.org[/geshifil…</a>]</cite><br /><cite>The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-.</cite></p>
  2. <p><strong>@mikeperry</strong> Please have the server admins enable [geshifilter-code]TLS_ECDHE_*
cipher suites to provide forward secrecy for as many visitors to Tor Project websites as possible.

hey Anonymous the NIST EC curves are cooked! Just get a decent browser and enjoy PFS with AES ;)

One TBB behaviour that continues to trouble me is that Firefox continues to try to connect to the internet. I use standard install on ubuntu with no add-ons (tor-browser-linux32-3.5.2.1_en-US.tar) and with js disabled in both NoScript and about:config.

I see additional changes with each update that improve browser isolation by disabling / blocking more auto-connect threats like blacklist updates, rule-set updates, safebrowsing reporting...etc...etc...

So with every new TBB release, I have renewed hope that Firefox will not go outside of the tor process with an internet connection attempt. Each release I allow tor to access the internet and firefox to access tor via 127.0.0.1. Each release I am either immediately or later disappointed when Firefox attempts its own internet connection.

My concerns...

1) Why does TBB continue to be released with default settings that allow Firefox automatically seek an internet connection? I can not imagine this not being noted in testing. What is trying to connect and what information is trying to be shared?

2) How many people trust any connections from TBB and allow both tor and TBB Firefox connections to outside world? Why is this not a significant security flaw? Tor works fine when I block these Firefox external connection attempts. I run a minimal ubuntu box with standard Forefox gutted to the best of my ability. I have a process connection map running and see that the Firexoz attempting to connect is from the TBB package.

3) If this behaviour is known and accepted, how do we know that connections are not being made and information being sent to unknown locations by Firefox through tor? This is something that I would never catch even with my layers of application and port level firewalls...

Sorry that I do not have Wireshark capabilities, but can not imagine that this behaviour is not seen on all installations.

Thanks for your efforts.

inside

Where is comment?

Setup:
-Standard TBB installation (tor-browser-linux32-3.5.2.1_en-US.tar)
-No add-ons; js disabled in both NoScript and about:config
-Ubuntu 12.04

Problem Description:
-Start up TBB from command line: ./start-tor-browser
-Allow Tor connection through application and port level firewalls
-Monitor processes through netstat window
-Observe tor communicating with outside world
-Observe firefox on 127.0.0.1 ports communicating only with tor across 127.0.0.1:9150/9151
Problem (Attempt to Bypass Tor) => Sometimes sooner, sometimes later...I get an application level alert that Firefox is attempting to connect to the internet
-I deny this Firefox connection attempt
-Firefox continues working well over its 127:0:0:1 connection

Additional Detail:
-Firefox continues working well over its 127:0:0:1 connection after I block the direct connection attempt
-The Firefox PID given in the direct connection alert is the same TBB Firefox PID as in my netstat window, so this is not a non-TBB Firefox process

Concern:
-Something in TBB Firefox is connecting to internet outside of Tor without my direction or something in ubuntu is using TBB Firefox to connect to internet outside of Tor without my direction
-This connection is bypassing the tor proxy
-While I see this as a huge design flaw, it is actually fortunate for me that this connection attempt is bypassing tor, otherwise this connection (from ??? to ??? sharing ???) would occur through Tor and I would be oblivious to the occurrence. As it is occurring now, I am at least able to see the Firefox direct connection attempt and block it
-If individuals do not use application level access control or if they just allow Firefox connections believing that this is part of normal TBB operation, they may be vulnerable

Thanks

Please name what "application and port level firewall" used?

Follow-Up
---------------
-I am not a linux expert sadly and have no wireshark capabilities.
-After checking a few ubuntu sites for ideas, I ran a list of Firefox resources before and after the Firefox direct (non-tor) connection attempt alert
-These may all be normal or may be an effect and not the cause of the tor bypass

Before/after bypass connection (differences between lsof | grep firefox):
---------------------------------------------------------------------------------------------------------
(all start similar to: firefox 10265 username mem REG 8,1 10370 675699...)
/usr/share/locale-langpack/en_GB/LC_MESSAGES/pulseaudio.mo
/usr/lib/xxxx-linux-gnu/libcanberra-0.28/libcanberra-pulse.so
/home/username/.local/share/gvfs-metadata/root-xxxxxx.log
/usr/share/locale-langpack/en_GB/LC_MESSAGES/eog.mo
/usr/share/locale-langpack/en_GB/LC_MESSAGES/file-roller.mo
/home/username/.local/share/gvfs-metadata/root
/home/username/tor-browser_en-US/Data/Browser/profile.default/formhistory.sqlite
unix 0x00000000 0t0 132338 socket
/home/username/tor-browser_en-US/.cache/event-sound-cache.tdb.xxxx.xxxx-pc-linux-gnu
/home/username/.local/share/gvfs-metadata/root (deleted)
/home/username/.local/share/gvfs-metadata/root-xxxxxxxx.log (deleted)

Of immediate concern is that I use standard TBB install, meaning EN-US. Only my system, and now you, lol, know that I have an EN-GB language preference set.
References to /usr/share/locale-langpack/, /usr/lib/xxxx-linux-gnu/l, gvfs-metadata, and fileroller add to this concern.

I am no Ubuntu genius, but it sure appears that Ubuntu system processes are hooking TBB Firefox for updates.

"Ubuntu system processes are hooking TBB Firefox for updates.
tbb processes or tor?"
is tbb different from regular tor in that tbb sends _only_ torbrowser firefox through tor?

It appears that cookies management is still broken. Why is this not a critical issue? How can I, the average user, see what cookies are available in memory and on disk? How can I verify that these are gone if I cant view them in the first place?

I have read some posts on this matter and do not see a good explanation and a good work around. I have current tbb on a unix platform.

This is a sensitive matter in light of Snowden reports on busting anonymity through cookie magic - from simple cookie tracking to the mysterious quantum cookie.

Regards.

This is https://trac.torproject.org/projects/tor/ticket/10353 and alas there is no simple fix to this problem as it is an underlying Firefox issue Mozilla is wrestling itself with.

GMail is broken, when you allow apis.google.com in NoScript. When you login and GMail loads GTalk / Hangouts after showing the main window with your mails, the site redirect you to the login page and asks for your password again. This is an infinit loop. When you block the address it works fine. I found a similar behavior on eBay. Seems like a bug. This is very annoying. I would like to report this, but I don't understand the bug tracker system.

Could be an issue with HTTPS-Everywhere, or could be an issue with Tor Browser's changes.

You might ask on IRC if anybody can help you use the bugtracker.

https://www.torproject.org/about/contact

Okay, thanks ;)
It seems to work now after the update to 3.5.3

HI TORPROJECT!

Where can I get a new Geoip file for Vidalia? (old file is October 2 2013)
I use Windows.
Thanks.