Pluggable transports bundles 2.4.18-rc-1-pt1 and 2.4.18-rc-2-pt1 with Firefox 17.0.11esr

There are new Pluggable Transports Tor Browser Bundles with Firefox 17.0.11esr. They are made from the Tor Browser Bundle 2.4.18-rc-1 release of November 19, except for the 64-bit GNU/Linux bundle, which is made from the 2.4.18-rc-2 release of November 20.

Pluggable Transports bundle download

Anonymous

December 05, 2013

Permalink

is it safe to download files with the tor browser? say you are on a website and you right-click on a link to a file, select "save link as"... then a warning pops up: "An external application is needed to handle: http://... NOTE: External applications are NOT Tor Safe by default and can unmask you!"

you can then select: "Launch application" or "cancel"

If you click "Launch application" to start the download is that safe?

can the ISP see what you are downloading from a website through tor browser?

It totally depends on the application that you launch.

In general you should 'save' it not 'launch' it, and then you should be very careful about what programs you run on the file -- for example, a Microsoft Word .doc file could include embedded image links that cause Word to go out to the Internet to fetch the image. And where do you set the proxy settings for Microsoft Word?

Best answer is to use something like Tails, or go offline to process the file after saving it.

what im talking about is the download process itself... not considering opening the file on that computer. would the ISP be able to see what you download through tor?

I just don't understand why that warning comes up when you right click on a file link and select "Save Link As". ... The warning says: "An external application is needed to handle xxx.exe."...External applications are NOT tor safe by default and can unmask you". Why is this warning coming up? I didn't choose to open the file just to Save Link As (meaning save it on my computer). Only two options tor browser gives me are: "Launch application" or "cancel". By clicking "launch application" all that seems to happen is the download begins... it doesn't actually launch any application or open the file... but is this unmasking my download?

Am I missing something like is there a another way to download files?

I think showing that message before saving a file is a bug. Warning people about opening downloaded files is good, but the "launch application button" preceding the file-saving dialog is wrong. That has bothered me too, but not enough to see if there is already a bug about it and open one. I'm not sure how long Tor Browser has done this but I think it has for a long time :(

Anonymous

December 06, 2013

Permalink

There is no mentioning of any obfsproxy updates released for a while. Does it mean that a new PT bundle is essentially the same as taking the previous PT bundle and adding the apps and libs from the latest vanilla TBB?

Many developments are currently on-going on obfsproxy: ScrambleSuit, bananaphone, … there are slowly getting ready to be shipped.

Anonymous

December 07, 2013

Permalink

have not been able to connect to any tor relays for 48 hours, is the entire network down or is my ISP blocking me from seeing the relays & bridges ?

Roger,
I'm not the original poster, but seconding the focus on the referred article. What is your opinion? Is the anonymous access practically attainable?
Because if not, ...

While the described risk of the cooperating entrance-exit node honeypots is not new, and was considered somewhat mitigated by the geo-diversity, it seems like the probability of a "global adversary" is increasing each year, so it may need to be paid more attention to now.

Let's admit that virtually all US-based Tor node traffic is being spied on by the global surveillance organization. Then let's add many (if not all) of the Canada's, UK's, Australia's, New Zealand's, German, French, and Dutch nodes sharing their surveillance with the SAME organization (and first with Israel), as it has been revealed (did I miss any country? The rest of countries may spy, but perhaps not sharing/cooperating so actively.)

Knowing of this global honeypot creation, how can we continue the same way, pretending that e.g. the US-based Tor nodes are still OK to use? That the plain Tor is still OK to use?

And, if obfs3 plugin is the only known solution to escape the deep-packet inspection, why is it still held a barely known OPTION, like it's not critically important? Wouldn't it make more sense to start a wide campaign - showing the importance of it, prompting the current relay operators to support it? Offering incentives for making obfs3? Asking for donations guaranteed to support obfs3 and similar technologies?

Anonymous

December 11, 2013

Permalink

On December 11th, Tails released its 0.22 version which contains Iceweasel 24.2.0esr and Torbutton 1.6.5.

However the current version of Tor Browser Bundle (2.3.25-15) contains Iceweasel 17.0.11esr and Torbutton 1.5.2.

Could Tails' and Tor's developers work as a team please? By that I mean they should sync their versions of Iceweasel, Torbutton and other critical anonymizing applications.

Anonymous

February 02, 2014

Permalink

What is the deal with David's signatures? They've been impossible to align with the packages for months now. Gnupg lists that the packages are signed by an unknown signature even though I've imported David's key several times. Whatever key these packages are signed with, it either isn't David's or there is something weird going on.

When I manually look up on the server the key that gnupg says is the one that the signature was generated by (0x797a326aec4a478af050cc3ae2b93d815cd388e5), it finds the exact key I already have imported (0x5CD388E5). I've deleted it and re-imported it over and again, the same result.

Can we get this resolved please? I can't use a package that keeps having questionable feedback in the signature verification process!

Sounds like you're using gpg wrong? I just fetched

https://people.torproject.org/~dcf/pt-bundle/3.5-pt20131217/TorBrowserB… and the .asc file and checked the signature:

$ gpg TorBrowserBundle-3.5-osx32_fr.zip.asc
gpg: Signature made Mon 27 Jan 2014 11:38:16 PM EST using RSA key ID 5CD388E5
gpg: Good signature from "David Fifield "
Primary key fingerprint: AD1A B35C 674D F572 FBCE 8B0A 6BC7 58CB C11F 6276
Subkey fingerprint: 797A 326A EC4A 478A F050 CC3A E2B9 3D81 5CD3 88E5

It all looks good to me.

Anonymous

February 02, 2014

Permalink

WHAT IS GOING ON WITH FITFIELD'S BAD KEYS?

This is the third time I've brought it up!!!!

Fuck!

I don't expect this comment to be approved and that's fine, but fucking deal with this, people!

Does he not know how to generate a proper key or something, or is something weird going on?

No, I think David is among the better users of gpg in the world.

Sounds like you should find some local Linux users to help you? Or maybe somebody on the #tor irc channel will walk you through it?

Well, that was embarrassing 9_9

Look, its just that I've always had problems with Fifield's keys - never, ever anyone else's. I have dozens of keys and verify various packages many times a week - only David's key turns out with this weird result. This has been the case since the pluggable transports bundles first appeared publicly.

I typically use Kleopatra with GnuPG. I import keys both manually from a file and by downloading from keys.gnupg.net; with each user I usually only choose one method. With David's, after encountering this issue, I have done both. Nothing changes, always the same problem.

When I have his 0x5CD388E5 certificate imported, the package "torbrowser-install-3.5_en-US.exe" (acquired from "https://www.torproject.org/docs/pluggable-transports.html.en#download"), the signature cannot be verified and is listed as "0xE2B93D815CD388E5".If I delete David's key from my keyring and check the package again using the .asc from the page, the signature again of course cannot be verified but instead reads "0x797A326AEC4A478AF050CC3AE2B93D815CD388E5". When his key is in my keyring, it's ID reads as "C11F6276". Every other key I have corresponds to the number in its listing when verifying a file. Only Fifield's does not. Every other key I have brings up the username of the key issuer when used to verify a file. Only David's does not.

This is just the current package I'm checking. I've done this with most of them, the result is the same. His name is never mentioned in the process, only "0xE2B93D815CD388E5", and only when his certificate is in my keyring.

When Erinn Clark's armored signature is used for verification, the key ID comes out in that name and the number that comes up is the same as the one listed as the key ID in the window that lists certificates.

This behavior is weird. Assuming all these numbers are somehow aligned with each other officially and are correct (I could easily have missed something, I haven't read the "Compendium"), how many numbers are we as users supposed to remember to associate a developer with? Three? More?

Perhaps he does things differently than other key providers because he is "among the better users of gpg in the world" but the difference makes things fishy to a medium level user like myself, even with a reasonable amount of experience with these tools. I can only imagine how much uncertainty it would engender in someone who is just getting into this sort of thing.