Tor Weekly News — January 28th, 2015

Welcome to the fourth issue in 2015 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

The future of Private Browsing Mode

Mozilla Firefox, on which Tor Browser is based, offers users a “Private Browsing Mode” that aims solely to prevent browsing information from being saved locally. As Georg Koppen pointed out, “The question is now how to treat the other privacy-relevant areas like cross-origin linkability or fingerprinting?”

Georg proposed a “Private Browsing Mode+”, which would integrate the disk-avoidance, anti-tracking, anti-fingerprinting, and location-concealing elements of a privacy-preserving browser in a more logical way.

Miscellaneous news

After a “pretty big overhaul”, Damian Johnson announced that Stem, the Tor controller library, now “lazy-loads” descriptors, resulting in a considerable speed increase when reading network documents. “Note that descriptor validation is now opt-in rather than opt-out, so if you’d prefer validation over performance you’ll now need to include ‘validate = True’.”

The Tails team set out the release schedule for Tails 1.3, and also published its Code of Conduct.

Arturo Filastò reported on OONI-related activities at the Nexa Center’s NNTools2015 event.

Patrick Schleizer wondered how Tor Browser could be made to act more like a “system tor”, and sketched out a possible plan: “What do you think about this proposal in general?”

This issue of Tor Weekly News has been assembled by Harmony.

Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

Tor Weekly News — January 21st, 2015

Welcome to the third issue in 2015 of Tor Weekly News, the weekly newsletter that covers what’s happening in the boring Tor community.

Tor Browser 4.0.3 and 4.5a3 are out

Georg Koppen announced two new releases by the Tor Browser team. Version 4.0.3 of the privacy-preserving browser is based on Firefox 31.4.0esr, and also contains updates to NoScript, meek, and Tor Launcher.

The third release in the 4.5-alpha series allows the secure in-browser update mechanism to handle signed update files, and will reject unsigned ones from now on. It also restores functionality for meek, which was broken in previous 4.5-alpha releases, and offers other improvements and bugfixes — please see Georg’s announcement for the full changelog.

These releases contain important security updates, so users of both the stable and alpha series should upgrade as soon as possible. Furthermore, Tor Browser 4.5a3 is signed by a new Tor Browser Developers signing key rather than the personal key of an individual developer. If you want to verify your download of the new alpha (and you should!), you will need to retrieve the new key (fingerprint EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290) from a keyserver before doing so.

Miscellaneous news

Anthony G. Basile announced version 20150114 of Tor-ramdisk, the uClibc-based micro Linux distribution whose only purpose is to host a Tor relay in an environment that maximizes security and privacy. This release includes updates to Tor, Libevent, and other key software.

Nik announced oppy, an onion proxy implemented in Python: “oppy works like a regular Tor client”, though “there are a number of simplifications made, with the major ones primarily centering around circuit management/build logic and how and when network status documents are collected”. Nik also asked for suggestions on how to take the project forward: “Whether or not I continue hacking on oppy to make it a solid piece of software (rather than just a prototype) or just leave it as is as a reference depends on whether or not the Tor development community sees any real uses or future potential for the project”.

meejah announced a new one-to-one encrypted and anonymous voice chat feature for “carml”, the command-line Tor control utility: “ [It] essentially cross-connects the mic + speakers of each side via an Opus + OGG stream over a single Tor TCP connection.” As meejah warns, it is “NOT FOR REAL USE at all yet”, but if you have experience with gstreamer and/or OGG then please see meejah’s message for some unresolved questions.

Following suggestions from Sebastian Urbach and grarpamp, Karsten Loesing altered the main unit of data rate measurement for the Tor Metrics portal from MiB/s (mebibytes per second) to the more common Gbit/s (gigabits per second).

Philipp Winter published preliminary statistics and analysis obtained by running a Go implementation of Doctor’s sybil-hunting script over archived consensuses: “I’ll have a more detailed analysis at some point in the future.”

The Tails team published instructions for running an nginx webserver as a hidden service using a copy of Tails: “Feedback is welcome!”

Thanks to Frédéric Cornu for running a mirror of the Tor Project’s website and software!

This week in Tor history

A year ago this week, the “Spoiled Onions” project published its preliminary technical report. The goal of the project was to monitor Tor exit relays in order to “expose, document, and thwart malicious or misconfigured relays”; the researchers turned up 65 such relays over the course of their investigation, with the culprits engaging in attacks such as “SSH and HTTPS MitM, HTML injection, SSL stripping, and traffic sniffing”, or unintentionally interfering with traffic as a result of upstream censorship.

Events such as the RELAY_EARLY traffic confirmation attack and the sybil attacks late last year have only highlighted the importance of monitoring for malicious relays in the Tor network. The bad-relays mailing list serves as a reporting channel for Tor community members who believe particular relays are up to no good (messages sent to the list are not publicly visible, for various reasons); David Fifield has been experimenting with data visualizations of significant network events; and Philipp Winter, a “Spoiled Onions” co-author, has been working on additional tools (such as the above-mentioned Go sybil hunter and “zoossh”, a speedy Tor network document parser) to make these checks more efficient — to give only a few examples of recent work by the community on this issue.

This issue of Tor Weekly News has been assembled by Harmony.

Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

Tor Browser 4.5a3 is released

The third alpha release of the 4.5 series is available from the extended downloads page and also from our distribution directory.

Note: The individual bundles of the alpha series are signed by one of the subkeys of the Tor Browser Developers signing key from now on. You can find its fingerprint on the Signing Keys page. It is:

pub   4096R/0x4E2C6E8793298290 2014-12-15
      Key fingerprint = EF6E 286D DA85 EA2A 4BA7
                        DE68 4E2C 6E87 9329 8290

Tor Browser 4.5a3 is based on Firefox ESR 31.4.0, which features important security updates to Firefox. Its updater now contains the code for verifying signed update files and does not accept unsigned ones anymore. Moreover, this release includes an updated Tor,, an updated meek, 0.15, which is now working again, and a bunch of additional improvements and bugfixes.

Here is the changelog since 4.5-alpha-2:

  • All Platforms
    • Update Firefox to 31.4.0esr
    • Update Tor to
    • Update NoScript to
    • Update HTTPS Everywhere to 5.0developement.2
    • Update meek to 0.15
    • Update Torbutton to
      • Bug 13998: Handle changes in NoScript
      • Bug 14100: Option to hide NetworkSettings menuitem
      • Bug 13079: Option to skip control port verification
      • Bug 13835: Option to change default Tor Browser homepage
      • Bug 11449: Fix new identity error if NoScript is not enabled
      • Bug 13881: Localize strings for tor circuit display
      • Bug 9387: Incorporate user feedback
      • Bug 13671: Fixup for circuit display if bridges are used
      • Translation updates
    • Update Tor Launcher
      • Bug 14122: Hide logo if TOR_HIDE_BROWSER_LOGO set
      • Translation updates
    • Bug 13379: Sign our MAR files
    • Bug 13788: Fix broken meek in 4.5-alpha series
    • Bug 13439: No canvas prompt for content callers

Tor Weekly News — January 14th, 2015

Welcome to the second issue in 2015 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

What to do if meek gets blocked

Regular readers of Tor Weekly News will be familiar with meek, the pluggable transport developed by David Fifield. Where most existing transports work by connecting clients to “bridge” relays that are difficult for the adversary to discover (or identify as relays), meek makes all of a client’s Tor traffic appear as though it is destined for a domain that is “too big to block” — in other words, web platforms so popular that a censor cannot prevent access to them without disrupting lots of unrelated Internet activity in its sphere of control — when in fact the traffic is sent to meek servers running on those platforms, which in turn relay it into the regular Tor network. Google, Amazon, and Microsoft are some of the services whose domain names currently work as disguises for meek.

Unfortunately, that doesn’t mean meek is unblockable. As David wrote to the tor-talk mailing list, “that’s the wrong way to think about the problem”. “It is designed to be difficult and expensive to block […] but suppose a censor makes that call, and blocks Google/Amazon/whatever. What then?”

Two easy solutions are selecting a different backend (meek-amazon instead of meek-google, for example) or using a different DNS server: “The most common way to block a domain name is by DNS poisoning; i.e., the IP address behind the name is accessible, but the local DNS server gives you a false address. Try a public DNS server such as But if that works, be aware that it’s probably only a temporary fix, as censors have historically figured out the alternate-DNS trick pretty fast.”

“What you really want to do”, David suggested, “if the easy things don’t work, is choose a different front domain.” Please see David’s message for a fuller explanation of the difference between the backend and the “front domain”, and a guide to configuring new domains — as well as one to setting up your own meek web app, if all else fails.

Miscellaneous news

sycamoreone announced orc, a Go library that implements parts of Tor’s control protocol. “I do have some ideas for a higher-level interface, but no fixed plan yet. The next step will probably be to add net/http-like handlerFuncs to handle (asynchronous) replies from the onion router.”

taxakis linked to “Post-Quantum Secure Onion Routing” by Satrajit Ghosh and Aniket Kate, a new paper proposing a successor to the currently-used ntor handshake protocol that would be “resilient against quantum attacks, but also at the same time allow OR nodes to use the current DH public keys, and consequently require no modification to the current Tor public key infrastructure.” Nick Mathewson wondered whether “anybody around here has the cryptographic background to comment on the PQ part of their scheme?”, and compared it to Yawning Angel’s experimental “basket” protocol.

Nick also sent out a draft of proposal 240, describing “a simple way for directory authorities to perform signing key revocation”.

Daniel Forster asked for advice on proposed research into splitting traffic over multiple entry guards in combination with traffic padding: “Is the approach heading in a not so great direction w.r.t. the Tor Project’s ‘only one entry node’ decision?”

Karsten Loesing submitted his status report for December, and George Kadianakis sent out the report for SponsorR.

“After CCC I have a list of people that I have given raspberry pi’s with ooniprobe, and I would like to start coordinating with them via a mailing list”, wrote Arturo Filastò, and the result is the ooni-operators mailing list. If you regularly run ooniprobe, or want to start, be sure to sign up!

Aleksejs Popovs shared with the ooni-dev mailing list the results of an OONI investigation into Latvian internet censorship, conducted using ooniprobe.

Dan O’Huiginn started a conversation about how to ensure users are informed of the possible consequences of running OONI tests.

Thanks to John Knoll and Monsieur Tino for running mirrors of the Tor Project’s website and software archive!

“How do we prevent a website mirror admin from tampering with the served files?”, wondered Frédéric Cornu. Christian Krbusek clarified that “in fact, you can’t prevent that, but you are also mirroring the signature files. So anybody downloading from any mirror — even the original host — should verify the downloads”. Andrew Lewman added that “the binaries are signed by well-known keys of tor packagers and developers. The mirror update script randomly selects a binary and verifies it each time it runs. If the binaries don't match, the mirror is removed from the public list.”

This issue of Tor Weekly News has been assembled by Harmony.

Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

Tor Browser 4.0.3 is released

A new release for the stable Tor Browser is available from the Tor Browser Project page and also from our distribution directory.

Tor Browser 4.0.3 is based on Firefox ESR 31.4.0, which features important security updates to Firefox. Additionally, it contains updates to meek, NoScript and Tor Launcher.

Here is the changelog since 4.0.2:

  • All Platforms
    • Update Firefox to 31.4.0esr
    • Update NoScript to
    • Update meek to 0.15
    • Update Tor Launcher to
      • Translation updates only

Tor Weekly News — January 7th, 2015

Welcome to the first issue in 2015 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

Tor is out

Nick Mathewson announced the second alpha release in the Tor 0.2.6.x series. As well as including the cell scheduling changes and hidden service statistics collection reported in recent issues of TWN, this release makes it harder to portscan hidden services by closing circuits if a client tries to connect to a non-existent port. It also contains numerous bugfixes and new unit tests; please see Nick’s announcement for the full changelog. The source code is available as usual from the distribution directory.

Tor at 31c3

The 31st edition of the Chaos Communication Congress, an annual highlight in the free software and security calendar, took place in Hamburg, and as usual Tor featured in several key talks over the course of the long weekend.

Roger Dingledine and Jacob Appelbaum’s appropriately grand-sounding “State of the Onion” address, a round-up of the year’s events in the Tor community, took place once again, with guest contributions from journalist and filmmaker Laura Poitras and OONI developer Arturo Filastò. Topics included the relationship between censorship and surveillance, the misinterpretation of academic research by journalists, new pluggable transports, and much more.

Laura Poitras also joined Julia Angwin, Jack Gillum, and Nadia Heninger for “Crypto Tales from the Trenches”, in which the journalists described their experiences with security software when doing research and communicating with sources. “I don’t think any of us could do our work without Tor”, said Laura, while Julia described the Tails operating system as “her favorite success story” in this field.

Tor Browser developer Mike Perry joined Seth Schoen to discuss the concept of deterministic builds, the implementation of which has been one of the Tor Project’s major successes over the past year. Mike and Seth demonstrated some of the attacks that this system aims to defend against, as well as the work that Tor, F-Droid, and Debian have all been doing to make their processes compatible with the deterministic build process.

Finally, Dr. Gareth Owen of Portsmouth University presented the results of research into the content and usage of Tor hidden services. The research involved setting up a number of Tor relays, waiting until they gained the “HSDir” flag, then counting the number of times a particular service’s descriptor was requested, as well as manually categorizing the services whose descriptors were learned. Dr. Owen found that while the largest category of onion services by number could be characterized as “drugs”, the majority of the descriptor requests he saw were for services in his “abuse” category. The talk itself discusses some possible limitations of the data gathered, and Tor developers have responded on the Tor blog with further analysis.

Monthly status reports for December 2014

The wave of regular monthly reports from Tor project members for the month of December has begun. Philipp Winter released his report first, followed by reports from Damian Johnson, Pearl Crescent, Juha Nurmi, Nick Mathewson, Sherief Alaa, Sukhbir Singh, Leiah Jansen, David Goulet, Michael Schloh von Bennewitz, Colin C., Georg Koppen, Arlo Breault, and George Kadianakis.

Colin C. also sent out the help desk report, while Arturo Filastò reported on behalf of the OONI team and Mike Perry for the Tor Browser team.

Miscellaneous news

Nick Mathewson and Andrea Shepard drafted a proposal for including a hash chain in the consensus produced by Tor directory authorities, in order to prevent certain kinds of attack on the directory authorities and their keys.

Nick also clarified that a recently-discovered Libevent vulnerability has no effect on Tor.

In connection with the current push to collect statistics relating to Tor hidden services in a privacy-preserving manner, Aaron Johnson noted that there are two further desirable sets of statistics which might pose a risk to anonymity if gathered incorrectly, and discussed possible solutions to the problem.

David Fifield published a summary of costs incurred by the meek pluggable transport for the month of December 2014.

David also continued his experiments on historical Tor metrics data with visualizations of a recent Sybil attack, and wondered what might have been responsible for a sudden change in the way that users in Kazakhstan were choosing to connect to the Tor network in October 2014.

Sebastian Urbach noted a sudden drop in the number of Tor relays acting as hidden service directories, and wondered about the cause. As SiNA Rabbani clarified, the amount of time a relay needs to have been running before it earns the “HSDir” flag was increased by directory authorities, in response to a recent Sybil attack.

The developers of ChatSecure for iOS announced that their recent 3.0 release includes experimental support for connections to XMPP chat servers over Tor, and briefly described how they added the new feature.

This issue of Tor Weekly News has been assembled by Harmony, David Fifield, Catfish, and Karsten Loesing.

Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

Tor is released

Tor is the second alpha release in the 0.2.6.x series. It introduces a major new backend for deciding when to send cells on channels, which should lead down the road to big performance increases. It contains security and statistics features for better work on hidden services, and numerous bugfixes.

This release contains many new unit tests, along with major performance improvements for running testing networks using Chutney. Thanks to a series of patches contributed by "teor", testing networks should now bootstrap in seconds, rather than minutes.

You can download the source from the usual place on the website. Packages should be up in a few days.

NOTE: This is an alpha release. Please expect bugs.

Changes in version - 2014-12-31

  • Major features (relay, infrastructure):
    • Complete revision of the code that relays use to decide which cell to send next. Formerly, we selected the best circuit to write on each channel, but we didn't select among channels in any sophisticated way. Now, we choose the best circuits globally from among those whose channels are ready to deliver traffic.

      This patch implements a new inter-cmux comparison API, a global high/low watermark mechanism and a global scheduler loop for transmission prioritization across all channels as well as among circuits on one channel. This schedule is currently tuned to (tolerantly) avoid making changes in network performance, but it should form the basis for major circuit performance increases in the future. Code by Andrea; tuning by Rob Jansen; implements ticket 9262.

  • Major features (hidden services):
    • Make HS port scanning more difficult by immediately closing the circuit when a user attempts to connect to a nonexistent port. Closes ticket 13667.
    • Add a HiddenServiceStatistics option that allows Tor relays to gather and publish statistics about the overall size and volume of hidden service usage. Specifically, when this option is turned on, an HSDir will publish an approximate number of hidden services that have published descriptors to it the past 24 hours. Also, if a relay has acted as a hidden service rendezvous point, it will publish the approximate amount of rendezvous cells it has relayed the past 24 hours. The statistics themselves are obfuscated so that the exact values cannot be derived. For more details see proposal 238, "Better hidden service stats from Tor relays". This feature is currently disabled by default. Implements feature 13192.

  read more »

Tor Weekly News — December 31st, 2014

Welcome to the final issue in 2014 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

Attacks and rumors of attacks

Two weeks ago, the Tor Project relayed a warning from an unspecified source to the effect that someone may have been preparing to seize, attack, or otherwise disable one or more of Tor’s directory authorities in a bid to disrupt the entire Tor network. The lack of any specific information about the threat caused understandable concern in the Tor community, and several events that followed over the next fortnight did little to dispel this.

First, the operator of a large Tor exit relay cluster reported that his servers may have been physically interfered with by unknown parties a short while before his message. Later updates suggested that foul play was less likely than initially thought.

Several days later, a large number of small exit relays were created all at once, in what appeared to be a “Sybil attack”; this was detected and halted almost immediately, as was a second, more recent incident. As the Tor Project put it in a response, “we don’t expect any anonymity or performance effects based on what we've seen so far”, although a side-effect of the countermeasure is that relays hosted on some IP ranges are currently being rejected by dirauths.

As far as anyone can tell, these events are not related in any way to the initial warning. The Tor network has functioned normally throughout this period, and the appearance of a series of incidents is likely to be the result of coincidence (helped by the online rumor mill) rather than a coordinated campaign. It is never possible to say with certainty that attacks on the network will not occur, but the threat referred to in the original blog post has not yet materialized — and “no news is good news”.

Miscellaneous news

Lasse Øverlier discovered that ScrambleSuit’s protection against “replay attacks”, in which an adversary repeats a client authentication event to learn that the server is in fact a ScrambleSuit bridge, doesn’t work. Philipp Winter explained the issue, and suggested some simple fixes.

Tom van der Woerdt asked for review of a patch to remove the obsolete version 1 of Tor’s link protocol from the current software: “It’s a rather large patch, though not as large as the patch that will remove v2 of the protocol. However, before I write that one, can someone please check whether my patch is sane and I’m not violating any standards or policies?”

David Fifield trimmed the length of meek’s HTTP headers from 413 to 162 bytes, reducing the bandwidth it uses by “approximately” 3%.

Thanks to Kura for running a mirror of the Tor Project website and software archive!

This issue of Tor Weekly News has been assembled by Harmony, David Fifield, Chuck Peters, and Roger Dingledine.

Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

Syndicate content Syndicate content