Tor 0.2.8.8 is released, with important fixes

by nickm | September 23, 2016

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.

Comments

Please note that the comment area below has been archived.

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?

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?

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.

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.

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.

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.

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)

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.

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.

September 26, 2016

Permalink

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

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.

September 29, 2016

Permalink

Thanks to all who work on Tor.

Looking forward to the windows expert version release.

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?

October 04, 2016

Permalink

Okay, all I can find is links to the source code when looking for the win32 binaries.

Where are the win32 binaries of 2.8.8 hiding? Going to the "download" links doesn't help, none of the links I can find. :(

October 04, 2016

Permalink

(Begging indulgence of moderator; second attempt to comment)

Oppressive governments are likely to maintain lists of all IP addresses under their jurisdiction (e.g. because the servers are located within their borders), and are increasingly likely to follow NSA's example by trying to implant an APT malware in all of them. Similarly, FBI has access to NSA's continuously updated list of IPs which have contacted a Tor Directory Authority (a necessary preliminary for using the Tor network), and come 1 Dec 2016 FBI is likely to attack all these IPs with a malware dropper. And of course NSA has lists of the IPs of all Cisco business-grade routers and appears to regularly attack each of them with a malware dropper which tries to implant an APT.

Sometimes that dropper fails to implant the APT, but when the dropper succeeds, it is "game over" for that device: the APT cannot be removed even with a complete OS reinstall (possibly because it has buried itself in a vulnerable microcontroller for a hard drive or some other essential hardware component which in inaccessible to the OS).

This kind of dragnet or targeted blitz attack with a malware dropper is different from worm/virus infections, in which infected machines try to infect other machines, so that the rate of attack is proportional to the number of already infected machines, because the malware dropper blitz is working from a more or less constant list of IPs, so the rate of dropper attacks is limited only by how many servers the state-sponsored attackers are willing to devote to the scheme. Further, infected machines are not removed from the population (if the APT is implanted, the infection shows no symptoms despite the disastrous consequences). These features mean that a dropper blitz attack is easier to model than a virus/worm attack.

Here is a simple four-state Markov process model in such a "dropper blitz attack" on a fixed list of devices. The states describe the status of a device on the list:

4. not yet attacked by dropper

3. dropper attack in progress

2. dropper attack complete but failed

1. dropper attack complete and APT implanted.

The infinitesimal generator matrix A is a four by four matrix with real entries such that all rows add to zero. The first two rows are zero (since states 1,2 are absorbing), the bottom two rows are

[ p*m, (1-p)*m, -m, 0 ]
[ 0,0,b,-b]

where 0 < p < 1 is the probability that a dropper attack succeeds, b > 0 is the time rate at which dropper attacks occur, and m > 0 is the time rate at which dropper attacks are completed once they begin. (Usually m >> b). That is, 1/b is the mean time before being attacked by a dropper and 1/m is the mean time for the attack to complete once it has begun.

Then the transition probabilities are given by the matrix P = exp(t*A) which can be computed explicitly and unmessily because the eigenvalues of A happen to be non-messy:

-b, -m, 0 with multiplicities 1, 1, 2

The conclusions of interest are:

1. the mean time for the attack to complete is 1/b + 1/m (no surprise there),

2. eventually (after a time on the order of some multiple of 1/b+1/m) essentially all the victims have been attacked, and fraction p of the victims have been implanted.

If we had some idea of the values of the characteristic times 1/b, 1/m we could estimate how long we can expect to be unmolested by FBI after 1 Dec 2016. I guess 1/b about a week and 1/m thirty seconds at most, and p might be about 0.95. Using those figures, the model predicts that sometime around Pearl Harbor day, 7 Dec 2016, 95% of Tor users will have been silently enlisted in FBI's secret botnet, and may thereafter be abused to attack still more victims. FBI can do a great deal of damage with a botnet consisting of millions of devices. Brian Krebs might not be worried, but Glenn Greenwald probably should be.

This model is easily generalized to a seven state model of a two stage attack in which every device which resists the first dropper is then attacked with a second dropper. Then the mean time for the entire blitz attack to complete is (1-p1)*(1/m2 + 1/b2) + (1/m1 + 1/b1), where p1 is the probability that the first dropper attack succeeds, b1 is the rate for the first dropper attack, m1 is the rate at which the first dropper completes, b2 is the rate for the second dropper attack, m2 is the rate at which the second dropper completes. At the end, after a time about three times the mean time just mentioned, essentially everyone has been attacked and only a fraction (1-p1)*(1-p2) have survived both dropper attacks.

And so on for three stage attacks.

Nothing stupendously surprising about any of this, but these models may be of interest to anyone teaching a course on Markov processes who needs a simple example of an absorbing Markov process for which everything is easily computed explicitly (which is not very often the case for continuous time Markov processes even for finite state models, because the eigenvalues of A are not often so tractable).

Sometimes that dropper fails to implant the APT, but when the dropper succeeds, it is "game over" for that device:

For those of us who are not IT trained, please tell us what the following terms refer to:

dropper

APT

device

Not IT trained either, but should have defined:

> dropper

A malware component which attempts to implant a persistent backdoor malware

> APT

Advanced Persistent Threat, a type of backdoor malware which cannot be removed even by reinstalling the operating system (for example, some NSA "implants" hide in micro-controller for the disk drive, which cannot be examined by an ordinary OS such as Linux)

> device

For example: a desktop PC, a laptop, a tablet computer, a smart phone, a PDA, an internet capable surveillance camera, or some other electronic device with internet connectivity

There *must* be some books which explain clearly and concisely the basic ideas of Markov processes in continuum time (viz. discrete time), but the best I can come up with for now are

Kleinrock, Queueing Systems, Wiley, 1975.

Readable and engaging. Queueing systems are a special type of Markov process.

Karlin and Taylor, A First Course in Stochastic Processes, Academic Press, 1975.

A graduate textbook, but the relevant sections are not as hard as they may appear.

It helps but is not essential to know something of the corresponding theory for Markov chains in discrete time, for which see

Kemeny and Snell, Finite Markov Chains, Van Nostrand, 1959.

The matrix techniques used in this book should help in understanding A and P = exp(A*t) for Markov processes in continuous time. Also, if you have trouble with a Markov process in continuous time, you can derive a similar Markov chain in discrete time and then the techniques in Kemeny and Snell should help you understand the behavior of this discrete time chain (the "uniformitization" of the original process).

To simulate a Markov process on a computer, it is important to understand that the diagonal components of A (the generator matrix) are negative, but flipping the signs gives the reciprocals of the mean times to remain in each state. Then the "embedded chain" is a discrete time Markov chain which says how to jump to a new state. So if you are in state j, you sample a waiting time from the exponential distribution with mean -1/A_jj, then you use S_(ij), the transition probability matrix of the embedded chain, to choose (nondeterministically) the next state k. Then you sample a waiting time from the exponential distribution with mean -1/A_kk, and so forth.

A book which is not as readable as one would like, but which does at least define the embedded chain and the uniformitization is

Nelson, Stochastic Modeling, Dover, 1995.

A textbook with careful proofs (but no diagrams) which does explain the simulation method noted above more clearly than Nelson is

Stroock, Introduction to Markov Processes, Springer, 2005.

None of these books simply tell the reader clearly and concisely how to get started working with specific Markov processes, which is unfortunate because that is not nearly as hard it the books might make it appear.

[This is the kind of meta-comment which USG may try to censor or delete]

@ moderator: wow, thanks much for posting this comment!

@ Roger: please consider asking your MIT colleague Daniel Stroock, author of a textbook on Markov processes, whether he can suggest a more serious Markov model which can help basic researchers understand some Tor-related problem. Stroock is one of the US mathematicians who have expressed support for a boycott of NSA by AMS (American Mathematical Society), so it seems reasonable to assume he might be willing to help. AFAIK, unlike too many other US STEM faculty, he has no financial ties to our enemies. (TP needs to avoid another Chasteen fiasco, so due caution will be required until NSA is dismantled and The People are safe from USG attack.)

@ Shari: 1 Dec 2016 is fast approaching, and users who are worried about FBI executing a dragnet malware dropper attack on all Tor users need a post before that date from TP offering best advice (which I would anticipate would be: "use Tails or Whonix", but hopefully with more detail). I'd also like to hear what advice if any people like Bruce Schneier, Matthew Green, Micah Lee, etc., have to offer.

October 05, 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?

Also pardon Ladar Levison ..

and Bradley Manning. And Assange...

[This is the kind of post which both USG and TP are likely to censor]

> 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?

I think it's a reasonable question:

1. At the urging of both TP (Tor Project) employees and Tor users, Shari has (laudably) reconfigured TP as a human rights organization.

2. HRW (Human Rights Watch), Amnesty International, ACLU (American Civil Liberties Union), and EFF (Electronic Frontier Foundation, where Shari worked for many years) and all other major human rights organizations have come out in favor of pardoning Snowden.

It has not escaped our notice that Shari has also hinted she plans to run major policy decisions by the TP workforce (not a bad idea in itself), leading us to suspect that some senior members who appear to be close to people who may be a little to close to the USG are bitterly opposed to TP coming out in favor of a Snowden pardon.

Reporters at TheRegister, Motherboard, Arstechnica are passing up the opportunity to look into and either confirm or debunk this sensational speculation.

Feel free to offer your own thoughts, if this comment appears.

My own thoughts are these one :
a) a partial judgement is not a pardon
b) a pardon means in the official mind 'we do understand but you must be judged (20 years of humiliation & poverty for telling the truth or acting as a human being -in prison- ?)'
c) a pardon means for yourself like an official honorific status so , another life , cleaned of all trial persecution with a good job and even prizes & money ... a star status (a dreyfus case ?... but he was guilty you know ...).
d) it is a comedy where all charges must be dropped and the truth must triumphed & opened the eyes of these blind servants ... of a power which is dying slowly but surely.

October 08, 2016

Permalink

"Tor 0.2.8.8 is released, with IMPORTANT FIXES
Relays running 0.2.8.x SHOULD UPGRADE,"

OK, but why you are allowing 0.2.4.26,0.2.4.27,0.2.5.11,0.2.5.12,0.2.6.5-rc,0.2.6.6,0.2.6.7,0.2.6.8,0.2.6.9,0.2.6.10,0.2.7.1-alpha,.... ??

October 11, 2016

Permalink

"Researchers at the KTH Royal Institute of Technology, Stockholm, and Princeton University in the USA have unveiled a new way to attack Tor and deanonymise its users."

"In the short term, the authors of the paper would like to see the Tor project fix a bug that causes Tor to cache DNS entries for 60 seconds regardless of the DNS entry’s TTL (Time To Live).

In the longer term they’re also calling for Tor to implement DNS lookups over TLS (which would encrypt traffic between exit nodes and DNS resolvers), and suggest that defenses against website fingerprinting attacks in general should be “an important long-term goal.’

They also offer the following advice for exit node operators:

… exit relay operators should avoid public resolvers such as Google and OpenDNS. Instead, they should either use the resolvers provided by their ISP, or run their own, particularly if the operator’s ISP already hosts many other exit relays. Local resolvers can further be optimized to minimize information leakage, by (for example) enabling QNAME minimization

Site operators worried about their users’ anonymity can bypass the DNS system entirely, and stay within the Tor network, by running their site as a hidden service."

For the rest of the article, surf to: Unmasking Tor users with DNS (https://nakedsecurity.sophos.com/2016/10/05/unmasking-tor-users-with-dn…)

> "Site operators worried about their users’ anonymity can bypass the DNS system entirely, and stay within the Tor network, by running their site as a hidden service."

I do not understand this, and would love to see an explainer from TP people who do understand it, but regardless:

1. EFF did great work in helping non-tech-savvy website maintainers learn how to implement TLS and obtain free certs,

2. This effort has been very successful, but owing to the ease with which governments (and other determined actors) can obtain and abuse root certs to MITM, https is no longer much help,

3. So TP should reach out to EFF about starting a new drive urging websites (such as major news organizations, human rights groups and other at-risk NGOs, controversial bloggers such as Brian Krebs, Phil Plait, etc., about setting up onion site mirrors of their websites.

Assuming of course that TP and EFF experts concur that onion sites offer significant protection against bad certs and other problems with https.

October 12, 2016

Permalink

No doubt it is merely accidental that comments are disabled here:

https://blog.torproject.org/blog/q-and-yawning-angel

Many thanks to Yawning Angel for this urgently needed innovation. Very happy to hear third try is charm!

Too bad it won't be ready before 1 Dec 2016 when FBI is likely to begin attacking all Tor users with their NIT malware (which indeed seems to fall into the class of malware which exploits browser vulnerabilities to "phone home" to spyservers, but probably follows up by trying to implant an APT backdoor giving complete control of a privately owned computer used by someone not even suspected of any crime to the FBI, which would be an unprecedented violation of Constitutional protections [of US citizens; suspected "others" evidently are not regarded as having any human rights whatever by USG).

According to my understanding, Tails already uses some sandboxing. How will the new TB sandboxing from YA compare?

I wish the blog had recommended that at-risk users consider using Tails, at least until the new sandboxing is available and has been battle tested.

October 13, 2016

Permalink

@ Tails:

What if no Paypal account and our bank refuses to wire money to a German bank? Is there another way to donate?

October 14, 2016

Permalink

Don't use 1024-bit prime number!

A kilobit hidden SNFS discrete logarithm computation
http://eprint.iacr.org/2016/961

For non-scientists:
http://arstechnica.com/security/2016/10/how-the-nsa-could-put-undetecta…
Technique allows attackers to passively decrypt Diffie-Hellman protected data.
With the current batch of existing 1,024-bit primes already well past their, well, prime, the time has come to retire them to make
way for 2,048-bit or even 4,096-bit replacements. Those 1,024-bit primes that can't be verified as truly random should be viewed
with special suspicion and banished from accepted standards as soon as possible.

October 14, 2016

Permalink

It seems that Tor users who wish to avoid being enrolled in FBI's botnet come 1 Dec 2016 need to use Tails. And Tails is seeking donations to fund 2016 operations:

tails.boum.org

But how can US users who have a bank account but who do not use Paypal, Flattr, Bitcoin donate?

(The problem is that Tails uses a bank account in DE, and not all US banks are willing to transfer funds except in dollars, which the DE bank apparently does not accept.)

A few years ago, Freedom of the Press Foundation was forwarding donations to Tails, but the current funding drive announcement does not mention FOTP. It does say the money is handled by Riseup Labs, but doesn't say whether Riseup Networks can forward a donation to Tails.

October 14, 2016

Permalink

> "Many thanks to Yawning Angel for this urgently needed innovation. Very happy to hear third try is charm!

Too bad it won't be ready before 1 Dec 2016 when FBI is likely to begin attacking all Tor users with their NIT malware"

Do you believe they're not attacking already? Legality means almost nothing to the FBI, or any of the other alphabet agencies in the US. Most other country's "agency's" as well. They are just hedging their bets in case they're caught out.

October 15, 2016

Permalink

Text-to-Speech help!

I'm dyslexic and I frequently use TTS for reading long emails or pages with long threads/posts (Like this one).

Last night I finally upgraded to El Capitan (10.11.6). Ever since then, when I use Tor, it reads the ENTIRE webpage (telling me where there are buttons, etc), rather than just the text I select. This renders TTS completely useless in Tor.

Note: TTS works as it should in FireFox and in Safari. (I haven't tested opera or chrome, because I don't have them). It's only in Tor that it seems to have borked since my upgrade. And it did work properly in Mavericks (10.9.5)

The only solution I've found at this point is to install a 'reader' addon, select the text I want TTS to read and then activate TTS. But that's a lot of steps and doesn't always work well. (IE: If I activate the reader for the whole page, TTS still sees and reads the linked buttons for some reason.)

Is there any way to return the native functionality for TTS to Tor in OSX 10.11?

I assume it has something to do with Apple changing how TTS works from a copy/paste to whatever they now use, but I don't know for sure.

I love Tor and use it constantly, but this change is making it difficult to use on my most frequented sites.

Thanks in advanced!
X-posted to Stack Exchange