Tor 0.2.8.8 is released, with important fixes

Tor 0.2.8.8 fixes two crash bugs present in previous versions of the 0.2.8.x series. Relays running 0.2.8.x should upgrade, as should users who select public relays as their bridges.
You can download the source from the Tor website. Packages should be available over the next week or so.
Below is a list of changes since 0.2.8.6.

Changes in version 0.2.8.8 - 2016-09-23

  • Major bugfixes (crash):
    • Fix a complicated crash bug that could affect Tor clients configured to use bridges when replacing a networkstatus consensus in which one of their bridges was mentioned. OpenBSD users saw more crashes here, but all platforms were potentially affected. Fixes bug 20103; bugfix on 0.2.8.2-alpha.
  • Major bugfixes (relay, OOM handler):
    • Fix a timing-dependent assertion failure that could occur when we tried to flush from a circuit after having freed its cells because of an out-of-memory condition. Fixes bug 20203; bugfix on 0.2.8.1-alpha. Thanks to "cypherpunks" for help diagnosing this one.
  • Minor feature (fallback directories):
    • Remove broken fallbacks from the hard-coded fallback directory list. Closes ticket 20190; patch by teor.
  • Minor features (geoip):
    • Update geoip and geoip6 to the September 6 2016 Maxmind GeoLite2 Country database.
Anonymous

September 23, 2016

Permalink

OpenBSD users saw more crashes here, but all platforms were potentially affected.

Since nickm mentioned OpenBSD users have been more seriously affected, we'd like to take this opportunity to ask why The Tor Project has no plans at all to release Tor Browser Bundle for *BSD operating systems, OpenBSD in particular.

A study by the European Union specifically recommends OpenBSD as the OS of choice. (cf. http://undeadly.org/cgi?action=article&sid=20150427093546)

According to The Tor BSD Diversity Project and we quote:

"Most of the ports in this repo pull their source tarballs from other GH torbsd repositories. This is because the Tor project chooses not to make source tarballs easily available for anything except tor itself (their gitian-based build process does not require them). Also, the OpenBSD ports system explicitly supports pointing at GH projects. I maintain the tags and branches in these repositories and track changes in the tor project's git repositories. Where possible I prefer to have ports pull source from some authoritative download area maintained by the project itself; in the case of noscript I do this, for example." (cf. https://github.com/torbsd/openbsd-ports)

It appears then that The Tor Project is not keen at all to support users of *BSD operating systems. Therein lies the danger. Again the following is a quote from The Tor BSD Diversity Project:

"While recognizing the Tor Project is a dynamic open source project with a vibrant community, we are also concerned with the overwhelming GNU/Linux monoculture that is an Achilles’ Heel. Monocultures in nature are dangerous, as vulnerabilities are held in common across a broad spectrum. In contrast, diversity means single vulnerabilities are less likely to harm the entire ecosystem. In a global anonymity network, monocultures are potentially disastrous. A single kernel vulnerability in GNU/Linux impacting Tor relays could be devastating. We want to see a stronger Tor network, and we believe one critical ingredient for that is operating system diversity." (cf. https://torbsd.github.io/)

About a month ago, Linux users learned of a security vulnerability that has the potential to unmask Tor users. Debian references it as CVE-2016-5696 (cf: https://security-tracker.debian.org/tracker/CVE-2016-5696) and the Debian OS remained unpatched for at least 17 days from the date of announcement of the bug in the Linux world. *BSD operating systems are not affected by the said vulnerability.

Given the above, we do hope that Tor developers will release Tor Browser Bundles that work natively in *BSD operating systems, OpenBSD in particular as the latter has been recommended by the EU.

"We"? http://undeadly.org/.† Ah, *BSD enthusiasts! OK, good.

A study by the European Union specifically recommends OpenBSD ...

I think the European Union is currently good about promoting privacy and security on the interwebs, but I expect someone'll turn up sooner or later flaming you that such a recommendation is just a sign of conspiracy.

I think you are right about OS diversity, though I would qualify it by saying that the Tor network should strongly avoid the use of relays running on proprietary-closed OSs (Windows, etc.).

Yet, is the lack of support for *BSD not like the earlier days of Linux, when early adopters were so likely to be experts in compiling from source (I recall something called 'freshmeat'), so that packages weren't really expected. (I must admit that to date I've never compiled sources myself.)

OK, I see there's no source for TBB like the source for Tor at https://www.torproject.org/download/download.html.en#source. Is it much co-ordination with TP to get the right Firefox source and Tor Project scripts for producing OpenBSD TBB packages? I'm curious about this, yet don't have the technical knowledge, but hope it can work for FOSS OS diversity.

https://undeadly.org/ requires login?

Anonymous

September 27, 2016

In reply to by Anonymous (not verified)

Permalink

>later flaming you that such a recommendation is just a sign of conspiracy

Conspiracy? Is that possible with FOSS OS such as OpenBSD?

>the Tor network should strongly avoid the use of relays running on proprietary-closed OSs (Windows, etc.)

Agreed. OpenBSD isn't proprietary software.

>Yet, is the lack of support for *BSD not like the earlier days of Linux, when early adopters were so likely to be experts in compiling from source

OpenBSD doesn't recommend users to compile from sources. Their recommended approach is to use pre-compiled packages.

>Is it much co-ordination with TP to get the right Firefox source and Tor Project scripts for producing OpenBSD TBB packages?

On the contrary it appears the The Tor Project does NOT wish to support *BSD operating systems as stated in the following:

"This is because the Tor project chooses not to make source tarballs easily available for anything except tor itself (their gitian-based build process does not require them)." (cf. https://github.com/torbsd/openbsd-ports)

Moroever OpenBSD users prefer to download Tor Browser Bundle directly from The Tor Project as the latter is the official software publisher of Tor.

"OpenBSD Ports for the Tor Browser Bundle (TBB)" at https://github.com/torbsd/openbsd-ports is not officially approved by The Tor Project, is it?

>† https://undeadly.org/ requires login?

It's a forum like reddit.com. Do you've a problem with it?

Thanks for replying!

Conspiracy? Is that possible with FOSS OS such as OpenBSD?

I meant that (of course) we know that FOSS is more robust against sneaked in backdoors, but the conspiracy enthusiasts will treat any endorsement by a governmental organisation as a clear red flag. Have you noticed the Pando-like claims that sometimes appear here?

OpenBSD['s] ... recommended approach is to use pre-compiled packages.

My ignorance is revealed! That strengthens the case for Tor packages for *BSDs then.

On the contrary it appears the The Tor Project does NOT wish to support *BSD operating systems ...

If I had seen all this sooner, I wonder if it would have been worthwhile to have suggested tackling *BSD Tor packages be a hack topic at the recent Tor Project Hack Day in Seattle this weekend? Perhaps there'll be a future chance?

... as stated in the following:

"This is because the Tor project chooses not to make source tarballs easily available for anything except tor itself (their gitian-based build process does not require them)." (cf. https://github.com/torbsd/openbsd-ports)

I can't quite follow this, though. What's the difference between the source tarballs you need and source tarballs for Tor and Firefox, and scripts to modify the Firefox source code into TBB? Is that what it takes?

It's a forum like reddit.com. Do you've a problem with it?

No problem, it's just that I was testing whether I could read the site using HTTPS, but a user login prompt came up. I wonder if the site's admin. set the server to assume anyone connecting using HTTPS must be wanting to log in to that forum, so it goes straight to a login prompt. I've not seen that before. Does that mean one cannot browse the site using HTTPS without logging in?

Anonymous

October 04, 2016

In reply to by Anonymous (not verified)

Permalink

I'm with TDP (https://torbsd.github.io) and I'm *trying* to make sense of this thread. Once I do, maybe I'll reply to some of the specific points.

We regularly correspond with Tor Project people, and we've received enormous encouragement since the beginning from people like Moritz and Roger. One of us did (finally) attend the Tor Summit in Seattle last week after multiple invites. I was thrilled at the awareness and reaction to our project particularly since we've been crawling through mud the past 1.5 years and are weak in the publicity sphere. Our project is treated with great respect by a lot of Tor people, and any opinions counter to that are delusional.

We did find the noted bug (https://bugs.torproject.org/20103) since we are running TB on OpenBSD and using a FreeBSD and an OpenBSD relay. Diversity helps finding bugs like that, and we intend to start running BSDs on other architectures like PPC and ARMv7 soon to extend the bug-squashing.

On that note, TB 6.0.5 is almost ready for testing, but we had to deal with a number of abrupt changes in OpenBSD -current, besides the above bug.

Stay tuned.

Anonymous

October 05, 2016

In reply to by Anonymous (not verified)

Permalink

> Perhaps there'll be a future chance?

Why not? If Tor developers in particular and FOSS developers in general agree that monocultures and having a monolithic Linux kernel are dangerous, Tor should promote TBB diversity as well. By TBB diversity I mean having TBB for as many platforms as possible.

> I can't quite follow this, though. What's the difference between the source tarballs you need and source tarballs for Tor and Firefox, and scripts to modify the Firefox source code into TBB? Is that what it takes?

I can't answer your question because I'm new to OpenBSD and not a software developer at all.

My suggestion is that if Tor developers are interested in offering TBB to *BSD users on Tor's official website, they could get in touch with the people at Tor BSD Diversity Project at https://torbsd.github.io/contact.html

*BSD users would prefer to download TBB from Tor's official website because the latter implicitly carries the official imprimatur.

> Does that mean one cannot browse the site using HTTPS without logging in?

I have always been able to surf and browse https://github.com/torbsd/ using TBB without problems. I wasn't prompted to login.

Anonymous

October 02, 2016

In reply to by Anonymous (not verified)

Permalink

@European Union is currently good about promoting privacy and security
no, e.u are against since a long time using a large & cruel violence.
@European Union specifically recommends OpenBSD
no, e.u are against all the systems/protocol that it should not be in their business plan.
*E.U contains (paradox?) also the territories which are not included officially and does not contain the territories which have said "no"(referendum=voxpopuli) and you could think that these one are a part of it.. NO is NO.

About a month ago, Linux users learned of a security vulnerability that has the potential to unmask Tor users. Debian references it as CVE-2016-5696 ...

It wasn't you making posts like https://blog.torproject.org/blog/tor-browser-605-released#comment-209592, about Tails being a risk to use as a consequence of said bug, was it?

If so, I'd like to state that I replied to one like that pointing out that Isis Lovecruft posted a blog on her website showing why this wasn't such a serious concern. See:

   https://blog.patternsinthevoid.net/cve-2016-5696-and-its-effects-on-tor…

Sadly, my (admittedly scornful!) reply didn't make it through the Great Disappearing Comment Episode (I mean, never passed moderation, not got censored, because of workload, I presume).

My understanding is that Linux was first to implement RFC5961, which should have made it more secure against blind in-window TCP attacks, but it turns out the implementation was screwed up. Arguing about whether that made it more or less secure on this point against other OSs seems to me not so clear, somewhat academic. In any case, being fixed, Linux could once again claim 'superiority'.

So, I don't think this is a good (or fair) way to promote OpenBSD, although I would otherwise welcome it. Yay, Open BSD.

What's a bigger risk with Tails is that it cannot carry over which Tor relay was last in use as guard node during reboot. Even if Tails switched from Linux to OpenBSD, it would not solve this problem. I'm using Tails 2.6 right now (with Linux kernel 4.6) and I don't experience any DoS. I'm not bothered.

> that Isis Lovecruft posted a blog on her website showing why this wasn't such a serious concern.

Debian classifies CVE-2016-5696 it as medium security risk. Shouldn't that in itself be a concern?

>So, I don't think this is a good (or fair) way to promote OpenBSD, although I would otherwise welcome it. Yay, Open BSD.

Correction. It's not just OpenBSD but FreeBSD, NetBSD, etc. are not affected by CVE-2016-5696.

>Even if Tails switched from Linux to OpenBSD,

It will never happen as *BSD kernels are notorious for being behind in their support for the latest Intel CPUs. An example is Intel Skylake CPU where there's still no support by *BSD operating systems.

Tails needs to be able to run on most hardware and Linux at the moment is the one that can offer it.

>and I don't experience any DoS.

Not yet. If I were you, I'd have written "and I don't experience DoS yet."

When you're out there on the internet, anything can happen. So don't be too quick to congratulate on your good fortune.

>Debian classifies CVE-2016-5696 it as medium security risk. Shouldn't that in itself be a concern?
Things above medium are reserved for, well, really extreme issues, like RCE. I agree that this should be higher, but it's not a concern.

>Correction. It's not just OpenBSD but FreeBSD, NetBSD, etc. are not affected by CVE-2016-5696.
Indeed. It was a bug in Linux's tcp_input.c specifically.

>It will never happen as *BSD kernels are notorious for being behind in their support for the latest Intel CPUs. An example is Intel Skylake CPU where there's still no support by *BSD operating systems.
FreeBSD, NetBSD, and OpenBSD support Skylake just fine, though OpenBSD lacks driver support for its GPU.

Shouldn't that in itself be a concern?

At medium level? Not necessarily, it depends on your threat model. I'm surprised it's only rated as medium given the fuss made about that, but after Isis's explanation I can see it was another victim of hype. I think some medium risk CVEs do linger on unpatched because they are partially applicable. It's the high risk CVEs that prompt the obligatory and spontaneous patches and releases, isn't it?

Not yet. If I were you, I'd have written "and I don't experience DoS yet." ... So don't be too quick to congratulate on your good fortune.

Ahh, but 'yet' can apply to anyone or anything! I could as easily say that you or the *BSDs just haven't yet had their DoSs from other unknown vulnerabilities.

TLDR; do use the argument that FOSS kernel diversity is good to promote support for *BSD kernels, don't use the argument that some other kernel has a bug to promote support for *BSD kernels because the tables can easily turn.

In fact, maybe I had been experiencing attempts at DoS. Using Tails (2.5 and 2.6), I noted that Tor sets up three guards nodes upon connnecting, and uses just one of them for a while. Until a few days ago, after browsing for some time, some web page would fail to load, and I'd find Onion Circuits would show failed attempts to connect via many circuits. Either I'd toggle my internet connection, or Tor would switch to the second guard node by itself some minutes later. Yet after all that, if these events were attempts at DoS, they were very ineffective. As for if "they" are trying to bump me towards a hostile guard node, well the real deficiency* with Tails is that it's three new guard nodes every reboot. So, the recommendations of Tor project for slow changing guards nodes is thrown out. That's one reason I'm using Tails for conventional stuff at the moment, so it won't matter if I do connect to a hostile guard node. Perhaps I could stretch to pondering that "they" were indeed trying out blind in-window hijacks to see if they could try and push Tor users around the network, and maybe it's all stopped because "they've" finished their evaluation. Maybe "they" found it more unrewarding than "they" hoped, or maybe "they" did deanonymise me and found out I read *gasp!* the Tor Project blog, but if the attack worked, wouldn't they need to keep doing it for all the websites I visit? So I can't be conclusive on that. More likely, I think, is that the guard node was undergoing heavy use, and when its bandwidth saturates, it becomes unresponsive and Tor realises it needs to switch guard node to keep Tor available. Doesn't that make sense too?

Still, I want to come to that argument for more support for *BSD, by focussing on CVE-2016-5696. Someone made three comments about Tails being at risk through Linux kernel 4.7. I initially posted a tart reply a short while after posting a long comment debunking the tiresome Addon update attack misconstruence of @movrcx, but it (now thankfully) never made it past moderation. I've posted three identical replies to each with a report pointing to Isis's blog post (though agains, one failed to make it past moderation. If my rude post does make it through, I must apologise in advance for its tartness.

Turning now to the merit of the argument about Linux kernal 4.7's CVE, I think the argument for more support is absolutely right if it is towards the goal of improving diversity of FOSS kernels. However, I think an argument based on which OS has a current embarrassing vulnerability isn't a good one, because the tables can so easily be turned if or when a *BSD kernel has its inglorious moment. That unexpected 'yet' doesn't help people understand it's the diversity of FOSS kernels that can protect us from these unforeseen risks or embarrassments. Indeed, singling out a sensationalised vulnerability in one particular kernel to contrast another as seemingly immune can actually have a bad effect of driving people (or sheeple) to revere one solution at the expense of others. At the moment, from Isis's blog, the Linux kernel gets a 96.6% share (of websites seen by Alexa, IIUC), not diverse at all. We should want to change that, but the argument should just be about having diverse kernels, because saying a known bug "proves" one of them to be inherently inferior is actually a temporary fact. In using a diversity argument and avoiding a comparative argument, I'd expect more support for *BSDs will be attracted from thinking people.

* Tails do want to find a way to preserve guard node constancy in their new roadmap.

> Someone made three comments about Tails being at risk through Linux kernel 4.7.

We read the three comments and believe you got it wrong. Tails 2.6 doesn't use Linux kernel 4.7. It uses version 4.6, which according to Debian security tracker, contains the vulnerability CVE-2016-5696.

> Turning now to the merit of the argument about Linux kernal 4.7's CVE,

Tails 2.6 uses kernel version 4.6 which is still vulnerable to CVE-2016-5696.

> TLDR; do use the argument that FOSS kernel diversity is good to promote support for *BSD kernels, don't use the argument that some other kernel has a bug to promote support for *BSD kernels because the tables can easily turn.

> However, I think an argument based on which OS has a current embarrassing vulnerability isn't a good one, because the tables can so easily be turned if or when a *BSD kernel has its inglorious moment.

> We should want to change that, but the argument should just be about having diverse kernels, because saying a known bug "proves" one of them to be inherently inferior is actually a temporary fact.

We agree but we can't speak for all *BSD flavors in general. We wish to single out OpenBSD, which according to its official website, has "only two remote holes in default install, in a heck of a long time!"

Unlike Debian, on which Tails is based, OpenBSD releases happen twice a year. During the interval between the official releases, the base system which includes the kernel is being continually audited for vulnerabilities and upgraded whenever the developers seem fit.

> the Great Disappearing Comment Episode

It isn't an episode, but rather a long-running series going back years. A significant number of my contributions to the blog comments here have failed to appear. I'm biased, of course, but I think that their quality was quite good and it perplexes me as to why they never made it.

From what I understand, junk comments are numerous and volunteers go through them when they have time so that they don't overwhelm the blog. I've suggested that people sometimes take a quick second look to see if any nice comments got swept away by accident.

If it's a question of volunteer resources (time), I volunteer to do this job myself. If I were allowed to take a quick look over flagged comments, I'll bet I could rescue a few of the constructive ones mistaken for spam.

This is important as online comments sections are increasingly seen as being deliberately manipulated. Good content that people work hard to create should not simply get misplaced as it may lead the authors to believe that something they said was censored, and censorship of divergent views is antithetical to what we believe as a community.

No. I think there are two separate things. The failure of posts to appear at all is indeed chronic; I've had many not get through, especially in the past month or so. The deletion of entire blogs of comments mid September is a one off (AFAICT).

The rest of your comment I fully agree with, even that I too would volunteer to manage comments. My problem is that I could not present Tor project with credentials (I still cannot find a trustably psuedonymous e-mail solution, if that were even acceptable), and we can't have Tor Project hand over the keys for the blog to any old anon, now can we!? :)

BSD things are more better for closed source; big company like Apple can use BSD without give any code to community, and this very sad thing.

But! Windows supported, which much worse.

GPL very good but please support BSD operating systems.

Very thank you for good good good project, so much thank you. Even better if more widespread. Begging you please to love the BSD neighbors with making Tor better on BSD, please please please please. Wishing the bestest to all of you.

>BSD things are more better for closed source;

FreeBSD, NetBSD and OpenBSD are all free open-source operating systems.

I don't understand why you brought Apple into the discussion.

>Begging you please to love the BSD neighbors with making Tor better on BSD,

It seems that Tor developers are well versed with Linux but not with *BSD, especially OpenBSD.

I don't understand why you brought Apple into the discussion.

I think the OP refers to the public secret that Apple pilfered one of the *BSDs and adapted it into iOS, because the generous nature of the BSD licence allows it, hence why "BSD things are more better for closed source" as the OP puts it. It's well known that iOS is a Unix clone, at least.

That's another problem for FOSS and BSDs in particular. Big businesses can appropriate these things for free, make vast profits, but see no reason to put money back into them, taking them for granted. So FOSS struggles with silly problems like Heartbleed because it's hard to raise the funds to properly maintain FOSS. Meredith Patterson made this point here in a blog of hers: https://medium.com/message/how-i-explained-heartbleed-to-my-therapist-4….

> I think the OP refers to the public secret that Apple pilfered one of the *BSDs and adapted it into iOS,

I was under the impression that Apple adapted *BSD codenamed "Darwin" for its Mac OS, not iOS.

> So FOSS struggles with silly problems like Heartbleed because it's hard to raise the funds to properly maintain FOSS.

I have a suggestion. When a vulnerability such as Heartbleed occurs in the future, Linux shall have the right to solicit funds from companies that uses it before a fix is released.

No doubt everyone here knows that the political differences between supporters of (say) Ted Cruz and Bernie Sanders are minor compared to the partisan hatreds which separates fans of Linux and fans of Windows.

So before I say anything else: citing the following link should *not* be supported as suggesting that urging Tor users to reject Linux in favor of Windows (or Mac OS) is a suitable fix for the increasingly worrisome troubles in Linux kernel space, nor as opposition to increased attention in Tor community to BSD support:

http://arstechnica.com/security/2016/09/linux-kernel-security-needs-fix…
Unsafe at any clock speed: Linux kernel security needs a rethink
Ars reports from the Linux Security Summit—and finds much work that needs to be done.
J.M. Porup (UK)
27 Sep 2016

> The Linux kernel today faces an unprecedented safety crisis. Much like when Ralph Nader famously told the American public that their cars were "unsafe at any speed" back in 1965, numerous security developers told the 2016 Linux Security Summit in Toronto that the operating system needs a total rethink to keep it fit for purpose.

Clearly TP cannot fix the safety/stability problems with the Linux kernel, and possibly cannot even hope to take a leading role in addressing them. But Linux is essential to the Open Source Software (OSS) movement, so Tor Project and especially Tails Project needs to stay abreast of the debate and even to try to make sure that kernel developers are made aware of any critical kernel issues which might affect the safety of the Tor network.

FWIW, I strongly support closer ties between Tor Project and Debian Project. Perhaps Tor Project's input into the debate over the future of the Linux kernel can go through Debian.

In one of the deleted comments, another poster mentioned experiencing kernel instability while using Tails. I've experienced several screen freezes which I suspect may reflext kernel instability, especially after using Tails connected to the web (I also used Tails extensively in off-line mode), when mounting or unmounting storage devices. It is possible that we are seeing unintended consquences of stock FBI/GCHQ malware attacks rather than kernel problems which would not otherwise occur.

Tails Team said in most recent release notes that they hope using a newer kernel will help.

No doubt everyone here knows ... the partisan hatreds which separates fans of Linux and fans of Windows.

Heh heh, I thought it was Apple Mac versus Microsoft Windows! but that just shows that in reality, most users don't even see beyond the end of their proprietary noses. Down with proprietary, I say, and up with FOSS plurality!

In one of the deleted comments, another poster mentioned experiencing kernel instability while using Tails.

It wasn't me, but I can add my observations on when I find crashes happen:

  • On a laptop, when I open the lid after closing, if the workspace has applications with open (non-minimised) windows on it. I find if I switch to a workspace with no or minimised windows, this doesn't happen.
  • On a laptop, when I adjust the screen brightness via the keyboard too quickly. This seems to happen only when Tails has booted, but not when I do this in the BIOS CMOS setup.
  • When downloading a large file, and the free memory in /home drops below about 400MB. usig the kernel option 'toram' makes this happen sooner, as well as having Firefox open at all (use curl or wget instead).
  • Having a lot of Firefox windows open in private browsing mode (I suspect Firedox completely replicates itself in memory for each window to provide isolation).
  • When using wget -i $file, where $file has a multitude of links (Again I suspect that wget is replicating itself in memory for each download).

These all seem to be either memory leaks or interrupt request handling. For, memory leaks, if you set the root password, there is sometime just enough response (the clock sometimes updates, and the mouse cursor still jerks every few seconds) to bang CTRL-ALT-F1 a few dozen times and get a console. There you can delete files or kill processes, and recover.

I too have experienced crashes, a new and unwelcome experience to this long time Linux user. Specifically, I have been observing crashes which appear to be associated with detaching encrypted USB drives. I've also seen some strangely slow encryption/decryption of same.

Linus said recently (sorry lost the link) that "crap" crept into recent kernels and has caused instabilities.

Another possibility for our community, sad to say, is that malware which is designed to be invisible is inadvertently showing hints of its presence by causing problems on our systems. Would be great if CitizenLab could look into this.

Anonymous

September 25, 2016

Permalink

As grateful as all users are for your work on Tor, would you please consider those who do not know how to compile?

Many times announcements are made relating to a new release, however there is rarely a tor.exe available for windows users for many weeks, sometimes months.

If there is indeed a significant reason for users to upgrade, would you kindly ensure there is a version available for "all" Tor users.

Thank you once again for you work.

Anonymous

September 25, 2016

Permalink

I know there is always a lot to do, but out of curiosity. Is there a big reason for a new release of Tor not automatically yielding in a new version of the Tor Browser Bundle?

Getting Tor Browser releases out is expensive for us. And as those releases happen in 6 week intervals (or shorter) we usually pick up a new Tor release in the following Tor Browser one. (critical bug fixes on Tor's side are treated differently, though)

Anonymous

September 25, 2016

Permalink

Begging indulgence of the moderator: I have a question about bridges with Tails 2.6.

Are there any requirements for (cheap crap consumer grade) router settings in order to use obfs4 bridges?

I got three obfs4 bridges from bridges.torproject.org but Tails 2.6 cannot establish a connection to any of them. I see "server refusing connection" in log, but LEDs on router seemed to suggest no outgoing packets. Is there some way of editing the "proxy" settings to help establish the connection to the bridges.

In the past I have tried to use "none" bridges, but most of them fail to accept connections also.

It will not escape your attention that if adversaries can prevent connections to any bridges they do not control, Tor users are at risk. You can judge better than I whether that scenario seems possible here.

Anonymous

September 25, 2016

Permalink

[This is the kind of comment which USG is likely to censor or delete]

How is it possible that TP has no comment whatsoever on the campaign to pardon Snowden?

Can Shari explain why she is not speaking out?

Do you mean you'd like to see a full blog post?

Maybe Shari's too busy. I think virtually all TP staff are "doing all the things." Comments to this blog are hard to maintain. Maybe Alison Macrina would be better able to make a Snowden blog post.

I think you're the same poster who wrote in https://blog.torproject.org/comment/reply/1211/208730 the following:

I've been trying hard to be supportive of the Shari regime but she's certainly not making it easy right now by remaining silent on so many critical issues, such as the question of whether or not TP supports a pardon for Edward Snowden, or what TP is doing to counter the dangerous demands for backdoors and free hacking powers--- not to mention the smearing of Snowden and the entire Tor community--- by FBI Director James Comey.

I can't find an example retweet by @torproject of any call for a pardon* for Snowden, though I had a (false?) memory that it did. Instead, about "demands for backdoors and free hacking powers" there's this pinned tweet by @torproject:

   https://twitter.com/torproject/status/776147999420329984

Surely Tor project isn't so aquiescent? I hope you can see it's not as bad as you fear.

* I don't agree with a pardon for Snowden (gasp!). Pardons imply culpability, followed by forgiveness. Instead, I think Snowden did The Right Thing and the charges should be dropped (... aaand, you're in Guantanamo!).

> Do you mean you'd like to see a full blog post?

Yes, a statement from TP.

> Maybe Shari's too busy.

Yes. We did warn her when her CEO-ship was announced that she had the hardest job in the world.

> I think virtually all TP staff are "doing all the things."

Yes.

> Comments to this blog are hard to maintain.

I'm sure, and my sympathies. But forcing commentators to register using valid email addresses before being able to post comments is not an acceptable way to fix the issue.

> Maybe Alison Macrina would be better able to make a Snowden blog post.

I think the Snowden pardon is so important that Shari should sign the statement supporting the pardon petition. Fine by me if Alison writes it as long as Shari approves it and signs it.

One of the best steps Shari has made is to begin to redefine TP as a civil liberties NGO. I think that is neccessary and overdue because protecting political dissidents around the world is the most important function of Tor. And all major US-based civil liberties groups (including ACLU and EFF) have cosponsored the Snowden petition drive. If TP does not sign on, this raises questions about whether USG is threatening to yank all funding for TP if TP signs the drive. I don't think that such bullying should be acceptable to TP, assuming that is the explanation for the nonappearance of an official TP statement.

> I don't agree with a pardon for Snowden (gasp!). Pardons imply culpability, followed by forgiveness. Instead, I think Snowden did The Right Thing and the charges should be dropped (... aaand, you're in Guantanamo!).

Not sure I understand. I think you may be saying you strongly support removing Snowden from legal jeapardy, but think drops should be dropped rather than a pardon issued. One problem there is that the two major candidations for US President have both stated that they want to put Snowden away for life, or even put him on Death Row, so they would surely simply reissue the charges on Day One. I can't parse the parenthetical comment; it almost seems you are urging that Snowden be kidnapped and rushed to GTMO regardless of his legal status under US law, but that would appear to be inconsistent with what I think you appeared to say previously.

>One problem there is that the two major candidations for US President have both stated that they want to put Snowden away for life, or even put him on Death Row,

Which candidate said they wanted him on death row? I haven't heard anything about that.

I'm sure, and my sympathies. But forcing commentators to register using valid email addresses before being able to post comments is not an acceptable way to fix the issue.

I agree. My problem is that I would not be able to comment anymore. I would rather remain properly anonymous, but moving to being properly pseudonymous isn't viable. I still cannot find a trustably pseudonymous e-mail solution. They either require two-factor authentication with a 'phone (the big providers), javascript enabled (even bitmessage.ch), traceable payments, another e-mail address anyway, Autistici want particular political alignments, and Riseup have a queue if you're too isolated to get a referral ...

Fine by me if Alison writes it ...

I suppose I thought of her because she's so gutsy!

... this raises questions about whether USG is threatening to yank all funding ...

... but I'm sure Alison wouldn't drop colleagues in it. If you are right, you may have found an 'acid test', but I'd have reservations about applying stress to pressure. If you are right, maybe better to ensure TPs migration to independent funding while quietly drawing the conclusion. The statement can come afterwards, surely?

(And Isis's canary is still dead ... :O ... :) )

I can't parse the parenthetical comment; ...

So sorry, my bad! I meant to write "(... aaand, I'm in Guantanamo!)" teasing that I would be put away for my heretical thoughts supporting Snowden!

I see you are pointing out my naivety regarding acquittal, but this latest US Presidential election campaign is throwing up strange things: Clinton gets away with using her own insecure e-mail server to process state secrets. Trump thinks a kill switch for the internet is a good thing. You may be right that an acquittal is reversable, but I wonder with either of these two if they'd try and undo a former president's pardon!

Re: "I still cannot find a trustably pseudonymous e-mail solution."

Easy fix: Sigaint.

No Javascript required for operation, .onion is available for creation of accounts and login (no problems with Tor browser), no 2FA required, and you could create and throw away the email address for each separate Tor comment in about 1 minute.

google (sorry disconnect lol) is your friend and you will find some good option even if the best is running your own mail-server.
by the way, posting on tor blog with an e-mail address will not fix the issue ... few persons (always the same) will comment and the others will even not read them : closed circuit.

> running your own mail-server

Hmm... where did I read recently about someone doing that? Oh, right, it was HRC. And what were the consequences for her choice to hire some dude to set up her private mail server in her own basement? Not good (for her).

> posting on tor blog with an e-mail address will not fix the issue

Not sure I follow... are you claiming that reporters and employees of NGOs such as Tor Project posting their email address and GPG key on pages (and sending public keys to key servers) is somehow a bad idea?

> few persons (always the same) will comment and the others will even not read them : closed circuit.

? ?

> My problem is that I would not be able to comment anymore. I would rather remain properly anonymous, but moving to being properly pseudonymous isn't viable. I still cannot find a trustably pseudonymous e-mail solution.

Exactly! You said it much better than I did, and my voice also would be silenced if Shari decides to require email/registration to post. That would be a loss, I think, to the community.

> I suppose I thought of her because she's so gutsy!

To repeat something I've said before: if Tor Project ever receives a NSL accompanied by a gag order, someone *must* assume the risk of flying to Germany (or somewhere else outside USA, where good extradition defense lawyers can be found) and giving a press conference revealing and publishing the NSL with gag order. I think Alison has sufficient courage. The problem is that as I've said before, in all likelihood the only persons who would know about the NSL are Shari and her lawyer.

Reuters has just revealed that Yahoo was served with an NSL (or something similar) accompanied by an eternal gag order which demanded that Yahoo scan *all* incoming emails for text dictated by NSA, and cc emails containing the keywords to a Yahoo server set up just so NSA could freely access whatever it wanted without Yahoo employees knowing. The CEO of Yahoo approved the secret system, but never told the security team about it. Later the security guys discovered that some emails were being mysteriously cc'd to a mystery server which unknown entities were accessing, and only then were they told about the NSA/Yahoo dragnet surveillance collaboration. I suspect this is typical of what happens when a company decides to give in to USG pressure: they bypass their own security people and hire an NSA/TAO person to design the secret exfiltration system without any company employees other than the CEO and GC knowing about it.

http://www.reuters.com
Exclusive: Yahoo secretly scanned customer emails for U.S. intelligence - sources
Joseph Menn
4 Oct 2016

|> Yahoo Inc last year secretly built a custom software program to search all of its customers' incoming emails for specific information provided by U.S. intelligence officials, according to people familiar with the matter. The company complied with a classified U.S. government demand, scanning hundreds of millions of Yahoo Mail accounts at the behest of the National Security Agency or FBI, said three former employees and a fourth person apprised of the events. Some surveillance experts said this represents the first case to surface of a U.S. Internet company agreeing to an intelligence agency's request by searching all arriving messages, as opposed to examining stored messages or scanning a small number of accounts in real time.

> this latest US Presidential election campaign is throwing up strange things

Don't forget that both candidates are calling for preventative detention and lifelong surveillance of "problem children" as part of CVE (Trump openly, Clinton in private, although her "surveillance surge" comment reveals that like Obama her first impulse in confronting a problem is to ramp up a vast new dragnet surveillance and population control program).

And don't forget that the coming collapse of the global economy is not just a right-wing "conspiracy theory", but something even the liberal magazine Salon is worrying about.

https://www.salon.com/2016/10/04/election-blindness-its-the-end-of-the-…
Election blindness: It’s the end of the world economy as we know it — and we feel fine
Our myopic focus on Trump and Clinton has blinded us to a looming debt crisis and a global economy on the precipice
Bob Hennelly
4 Oct 2016

|> As the World Bank and the International Monetary Fund convene this week in Washington for their annual meeting, there is growing evidence that the post-World War II global consensus that created them is unraveling, right at the time when the global economy is facing major economic headwinds that have been decades in the making.
|> ...
|> For decades now the received neo-liberal wisdom from the elite institutions of the World Bank and the IMF was that only open markets and unfettered global trade could deliver a broad-based prosperity and advance the well-being of our species on the planet. Yet, what we have is massive misery for millions caught up in the cross fire of conflict and increasing wealth concentration, thanks to tax evasion and rampant political corruption both here and around the world.

And don't forget that global warming is likely to ultimately kill most humans even if the depression or the USG don't do it first.

Open Whisper Systems (maker of Signal) has just revealed FBI demanded information on all customers and added an eternal gag order. ACLU fought and WON which is why we know about the FBI's unconstitutional data grab. As ACLU points out, the ease with which FBI abandoned its gag order shows that it is *always* worthwhile fighting such gag orders, because FBI knows they are outrageously unconstitutional and is apparently reluctant to risk a serious court fight unless they feel very strongly that the spying must be kept secret.

http://arstechnica.com/tech-policy/2016/10/fbi-demands-signal-user-data…
FBI demands Signal user data, but there’s not much to hand over
Signal parent company Open Whisper Systems hired ACLU, which helped fight gag order.
Cyrus Farivar
4 Oct 2016

|> The American Civil Liberties Union announced Tuesday that Open Whisper Systems (OWS), the company behind popular encrypted messaging app Signal, was subpoenaed earlier this year by a federal grand jury in the Eastern District of Virginia to hand over a slew of information—"subscriber name, addresses, telephone numbers, email addresses, method of payment"—on two of its users. Further, OWS was prevented for at least several months from publicly disclosing that it had received such an order until the ACLU successfully challenged it.

Sadly, it seems that far from pardoning Snowden, Obama's last act in office will be to pardon the CIA agents who did this:

https://www.salon.com/2016/10/04/hell-in-dark-prison-new-forms-of-tortu…
Hell in “Dark Prison”: New forms of torture at CIA black site revealed
Interviews conducted by Human Rights Watch detail the extreme abuse detainees endured at the CIA black site Cobalt
Ben Norton
4 Oct 2016

|> Previously undisclosed methods of torture used by the U.S. Central Intelligence Agency have been revealed in a new report by Human Rights Watch. Two Tunisian men detained without charge or trial in a CIA black site in Afghanistan from 2002 to 2015 independently described to the rights group several excruciating forms of abuse they endured at the hands of the CIA.

The scope and scale of USG abuses of all peoples everywhere is truly abhorrent.

It will end only when the US political leadership is put on trial for war crimes at the ICC. This is far more likely than they realize, because a global depression will cripple USG's ability to bully EU and other nations, and will cause so much anger around the world that if the current US regime collapses, the leadership may well be handed over the Hague to face justice. So the cloud currently hanging of the global economy has a silver lining.

Anonymous

September 26, 2016

Permalink

Why no comment from TP on the Snowden pardon petition? The Sterling pardon petition?

Anonymous

September 28, 2016

Permalink

Thank you for your services. Huge Blessing. I believe come the first of October if not already china and russia will have access to our internet. Very disturbing. God Bless you for putting this together. I am sharing with all that I come across with about this app. I RESPECT AND ADMIRE MR. SNOWDEN FOR WHAT HE DID. It took courage and integrity to do what he did.

Anonymous

September 29, 2016

Permalink

Thanks to all who work on Tor.

Looking forward to the windows expert version release.

Anonymous

October 02, 2016

Permalink

@ Tor experts:

Any comments on this "Tor-friendly" proposal from our chums at Cloudflare?

https://motherboard.vice.com/read/tor-captchas
Tor Users Might Soon Have a Way to Avoid Those Annoying CAPTCHAs
Joshua Kopstein
1 Oct 2016

> If you’ve ever used the Tor anonymity software to browse the web, there’s a good chance you’re very familiar with CAPTCHAs, the prove-you’re-a-human puzzles that have you select images containing street signs, storefronts, or bodies of water before accessing a site.
> ...
> To solve this, the authors propose a Tor browser plugin that would store “unlinkable” authentication tokens, which Tor users would provide to prove they’re not spammy bots without having to repeatedly solve CAPTCHAs or risk identifying themselves. As Brave developer Yan Xu points out, the spec is based around the concept of “blind signatures,” originally proposed in 1983 by cryptographer David Chaum.

Chaum's name is well known in the privacy arena, but has this idea generated a substantial amount of security research more recent than 1983?

Few of us would want to download a TB plugin from Cloudflare, but we'd probably be willing to try one which came from TP itself.

For Tor browser users engaged in general browsing, avoiding the CAPTCHA virus is as simple as:

1. startpage.com
2. enter desired url
3. click 'proxy'
4. keep reading

The proxy by-pass will work in probably 90-95% of cases. And - shock horror - if that fails, you can inevitably read the same information on another website without the CAPTCHA (AIDS) virus, with about 5 seconds of effort.

For critical internet activities, there is always an alternative service available without CAPTCHAS if you look hard enough. I will never bow down to this form of internet censorship, and I suggest you do the same. The sooner these companies go and shoot themselves in the head, the better off we'll all be.

Please don't make this a thing. Cloudflare is not a gate to the internet. They mistakenly challenge (require captcha solution for) GET requests from IPs that were caught in their WAF/IDS/IPS thing. The solution is for them not to block these IPs. All other anti DDOS solutions have done it this way since the beginning of the internet. Anti DDOS solutions are meant to eat up the bandwidth of clients, not block them. The problem is that Cloudflare bundles this WAF garbage which nobody asked for (but they will happily be tricked into taking). Unlike what Cloudflare claim, nobody is seriously depending on a WAF to prevent SQL injection or scraping of their website. Neither of those can even be prevented by blacklisting in the first place.

Ignoring all this, the cloudflare plugin (like all web plugins) will probably be found to be buggy and compromise anonymity/security (intentionally or not).

The register's writeup has a link to the arXiv eprint on this "defecTor attack":

http://www.theregister.co.uk/2016/10/04/domain_name_resolution_is_a_tor…
Domain name resolution is a Tor attack vector, but don't worry
Nation-state attackers probably pwn you anyhow
4 Oct 2016
Richard Chirgwin

> Google's DNS has a special place in the research, the paper states, because 40 per cent of DNS bandwidth from Tor exit nodes, and one-third of all Tor DNS requests, land on The Chocolate Factory's resolvers. That makes Google uniquely placed to help snoop on users, if it were so minded.
>
> There's a second problem, and one The Register is sure has other researchers slapping their foreheads and saying “why didn't I think of that?”: DNS requests often traverse networks (autonomous systems, ASs) that the user's HTTP traffic never touches. The requests leak further than the Tor traffic that triggers it.
> ...
> Like other attacks, DefecTor needs a network-level sniffer at ingress. While ingress traffic is encrypted, existing research demonstrates that packet length and direction provides a fingerprint that can identify the Website that originated the traffic. Egress sniffing is also needed: the attacker might capture traffic on the path between an exit relay and a resolver; or may operate a malicious DNS resolver to capture exit traffic. With the user's encrypted TCP traffic fingerprinted, DNS requests, and time-stamps, DefecTor can mount “perfectly precise” attacks. “Mapping DNS traffic to websites is highly accurate even with simple techniques, and correlating the observed websites with a website fingerprinting attack greatly improves the precision when monitoring relatively unpopular websites,” the paper states.
>
> Mitigations suggested in the paper include:

> o Exit relay operators handling DNS resolution themselves, or using their ISP's resolver, rather than Google or OpenDNS;
> o There's a “clipping bug” in Tor (notified to the operators) that expires DNS caches too soon, sending too many requests out to a resolver (and providing more sniffable material to an attacker);
> o Site operators should create .onion services that don't raise DNS requests; and
> o Tor needs hardening against Website fingerprinting.

And here is a writeup from one of the authors of the defecTor eprint:

https://freedom-to-tinker.com/2016/09/29/the-effect-of-dns-on-tors-anon…
The Effect of DNS on Tor’s Anonymity
29 Sep 2016
Philipp Winter

> Counting almost two million daily users and 7,000 relays, the Tor network is the largest anonymity network operating today. The Tor Project is maintaining a privacy-enhanced version of the popular Firefox web browser—Tor Browser—that bounces its network traffic over the Tor network. By using Tor Browser, users can protect their web browsing from government surveillance, stalkers, advertisement-injecting ISPs, and nosy neighbors. Tor works by decoupling a user’s identity (i.e., the IP address, which reveals where in the world you are) from her activity (e.g., visiting Facebook). When using Tor, your ISP can no longer learn what websites you visit, but it does know that you are using Tor. The website you visit (e.g., Facebook) will also know that you are using Tor, but it will not learn your IP address. The EFF maintains a great interactive diagram, illustrating information leakage in several scenarios.

How DNS can deanonmymize the onion:// website that is not use DNS?
From article says "potentially uncovering not only the user's true IP address but the physical location of servers in some cases.

Companies which operate open DNS resolvers, such as Google, are in the position to facilitate or use such attacks"
Is it just warn us that now website which not onion:// can located server? Was this new? Can not located http:// server before now?