Support all your favorite nonprofits with a single donation.

Donate safely, anonymously & monthly, in any amount. It's a smarter way to give online. Learn more
The Tor Project
Dedham, MA
givvers: jason, emerssso + 4 others

Tor is free software and an open network that helps you defend against a form of network surveillance that threatens personal freedom and privacy, confidential business activities and relationships, and state security known as traffic analysis.

The Tor Project is a 501(c)3 organization.

Latest News

Jan 28, 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!

Jan 21, 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!

Jan 16, 2015

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, 0.2.6.2-alpha, 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 0.2.6.2-alpha
    • Update NoScript to 2.6.9.10
    • Update HTTPS Everywhere to 5.0developement.2
    • Update meek to 0.15
    • Update Torbutton to 1.8.1.3
      • Bug 13998: Handle changes in NoScript 2.6.9.8+
      • 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 0.2.7.1
      • 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

Jan 14, 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 8.8.8.8. 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!

Jan 13, 2015

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 2.6.9.10
    • Update meek to 0.15
    • Update Tor Launcher to 0.2.7.0.2
      • Translation updates only

Jan 07, 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 0.2.6.2-alpha 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!

Dec 31, 2014

Tor 0.2.6.2-alpha 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 0.2.6.2-alpha - 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.

 

  • Major bugfixes (client, automap):
    • Repair automapping with IPv6 addresses. This automapping should have worked previously, but one piece of debugging code that we inserted to detect a regression actually caused the regression to manifest itself again. Fixes bug 13811 and bug 12831; bugfix on 0.2.4.7-alpha. Diagnosed and fixed by Francisco Blas Izquierdo Riera.
  • Major bugfixes (hidden services):
    • When closing an introduction circuit that was opened in parallel with others, don't mark the introduction point as unreachable. Previously, the first successful connection to an introduction point would make the other introduction points get marked as having timed out. Fixes bug 13698; bugfix on 0.0.6rc2.
  • Directory authority changes:
    • Remove turtles as a directory authority.
    • Add longclaw as a new (v3) directory authority. This implements ticket 13296. This keeps the directory authority count at 9.
  • Major removed features:
    • Tor clients no longer support connecting to hidden services running on Tor 0.2.2.x and earlier; the Support022HiddenServices option has been removed. (There shouldn't be any hidden services running these versions on the network.) Closes ticket 7803.
  • Minor features (client):
    • Validate hostnames in SOCKS5 requests more strictly. If SafeSocks is enabled, reject requests with IP addresses as hostnames. Resolves ticket 13315.
  • Minor features (controller):
    • Add a "SIGNAL HEARTBEAT" controller command that tells Tor to write an unscheduled heartbeat message to the log. Implements feature 9503.
  • Minor features (geoip):
    • Update geoip and geoip6 to the November 15 2014 Maxmind GeoLite2 Country database.
  • Minor features (hidden services):
    • When re-enabling the network, don't try to build introduction circuits until we have successfully built a circuit. This makes hidden services come up faster when the network is re-enabled. Patch from "akwizgran". Closes ticket 13447.
    • When we fail to a retrieve hidden service descriptor, send the controller an "HS_DESC FAILED" controller event. Implements feature 13212.
    • New HiddenServiceDirGroupReadable option to cause hidden service directories and hostname files to be created group-readable. Patch from "anon", David Stainton, and "meejah". Closes ticket 11291.
  • Minor features (systemd):
    • Where supported, when running with systemd, report successful startup to systemd. Part of ticket 11016. Patch by Michael Scherer.
    • When running with systemd, support systemd watchdog messages. Part of ticket 11016. Patch by Michael Scherer.
  • Minor features (transparent proxy):
    • Update the transparent proxy option checks to allow for both ipfw and pf on OS X. Closes ticket 14002.
    • Use the correct option when using IPv6 with transparent proxy support on Linux. Resolves 13808. Patch by Francisco Blas Izquierdo Riera.
  • Minor bugfixes (preventative security, C safety):
    • When reading a hexadecimal, base-32, or base-64 encoded value from a string, always overwrite the whole output buffer. This prevents some bugs where we would look at (but fortunately, not reveal) uninitialized memory on the stack. Fixes bug 14013; bugfix on all versions of Tor.
    • Clear all memory targetted by tor_addr_{to,from}_sockaddr(), not just the part that's used. This makes it harder for data leak bugs to occur in the event of other programming failures. Resolves ticket 14041.
  • Minor bugfixes (client, microdescriptors):
    • Use a full 256 bits of the SHA256 digest of a microdescriptor when computing which microdescriptors to download. This keeps us from erroneous download behavior if two microdescriptor digests ever have the same first 160 bits. Fixes part of bug 13399; bugfix on 0.2.3.1-alpha.
    • Reset a router's status if its microdescriptor digest changes, even if the first 160 bits remain the same. Fixes part of bug 13399; bugfix on 0.2.3.1-alpha.
  • Minor bugfixes (compilation):
    • Silence clang warnings under --enable-expensive-hardening, including implicit truncation of 64 bit values to 32 bit, const char assignment to self, tautological compare, and additional parentheses around equality tests. Fixes bug 13577; bugfix on 0.2.5.4-alpha.
    • Fix a clang warning about checking whether an address in the middle of a structure is NULL. Fixes bug 14001; bugfix on 0.2.1.2-alpha.
  • Minor bugfixes (hidden services):
    • Correctly send a controller event when we find that a rendezvous circuit has finished. Fixes bug 13936; bugfix on 0.1.1.5-alpha.
    • Pre-check directory permissions for new hidden-services to avoid at least one case of "Bug: Acting on config options left us in a broken state. Dying." Fixes bug 13942; bugfix on 0.0.6pre1.
    • When adding a new hidden service (for example, via SETCONF), Tor no longer congratulates the user for running a relay. Fixes bug 13941; bugfix on 0.2.6.1-alpha.
    • When fetching hidden service descriptors, we now check not only for whether we got the hidden service we had in mind, but also whether we got the particular descriptors we wanted. This prevents a class of inefficient but annoying DoS attacks by hidden service directories. Fixes bug 13214; bugfix on 0.2.1.6-alpha. Reported by "special".
  • Minor bugfixes (Linux seccomp2 sandbox):
    • Make transparent proxy support work along with the seccomp2 sandbox. Fixes part of bug 13808; bugfix on 0.2.5.1-alpha. Patch by Francisco Blas Izquierdo Riera.
    • Fix a memory leak in tor-resolve when running with the sandbox enabled. Fixes bug 14050; bugfix on 0.2.5.9-rc.
  • Minor bugfixes (logging):
    • Downgrade warnings about RSA signature failures to info log level. Emit a warning when an extra info document is found incompatible with a corresponding router descriptor. Fixes bug 9812; bugfix on 0.0.6rc3.
    • Make connection_ap_handshake_attach_circuit() log the circuit ID correctly. Fixes bug 13701; bugfix on 0.0.6.
  • Minor bugfixes (misc):
    • Stop allowing invalid address patterns like "*/24" that contain both a wildcard address and a bit prefix length. This affects all our address-range parsing code. Fixes bug 7484; bugfix on 0.0.2pre14.
  • Minor bugfixes (testing networks, fast startup):
    • Allow Tor to build circuits using a consensus with no exits. If the consensus has no exits (typical of a bootstrapping test network), allow Tor to build circuits once enough descriptors have been downloaded. This assists in bootstrapping a testing Tor network. Fixes bug 13718; bugfix on 0.2.4.10-alpha. Patch by "teor".
    • When V3AuthVotingInterval is low, give a lower If-Modified-Since header to directory servers. This allows us to obtain consensuses promptly when the consensus interval is very short. This assists in bootstrapping a testing Tor network. Fixes parts of bugs 13718 and 13963; bugfix on 0.2.0.3-alpha. Patch by "teor".
    • Stop assuming that private addresses are local when checking reachability in a TestingTorNetwork. Instead, when testing, assume all OR connections are remote. (This is necessary due to many test scenarios running all relays on localhost.) This assists in bootstrapping a testing Tor network. Fixes bug 13924; bugfix on 0.1.0.1-rc. Patch by "teor".
    • Avoid building exit circuits from a consensus with no exits. Now thanks to our fix for 13718, we accept a no-exit network as not wholly lost, but we need to remember not to try to build exit circuits on it. Closes ticket 13814; patch by "teor".
    • Stop requiring exits to have non-zero bandwithcapacity in a TestingTorNetwork. Instead, when TestingMinExitFlagThreshold is 0, ignore exit bandwidthcapacity. This assists in bootstrapping a testing Tor network. Fixes parts of bugs 13718 and 13839; bugfix on 0.2.0.3-alpha. Patch by "teor".
    • Add "internal" to some bootstrap statuses when no exits are available. If the consensus does not contain Exits, Tor will only build internal circuits. In this case, relevant statuses will contain the word "internal" as indicated in the Tor control- spec.txt. When bootstrap completes, Tor will be ready to build internal circuits. If a future consensus contains Exits, exit circuits may become available. Fixes part of bug 13718; bugfix on 0.2.4.10-alpha. Patch by "teor".
    • Decrease minimum consensus interval to 10 seconds when TestingTorNetwork is set, or 5 seconds for the first consensus. Fix assumptions throughout the code that assume larger intervals. Fixes bugs 13718 and 13823; bugfix on 0.2.0.3-alpha. Patch by "teor".
    • Avoid excluding guards from path building in minimal test networks, when we're in a test network and excluding guards would exclude all relays. This typically occurs in incredibly small tor networks, and those using "TestingAuthVoteGuard *". Fixes part of bug 13718; bugfix on 0.1.1.11-alpha. Patch by "teor".
  • Code simplification and refactoring:
    • Stop using can_complete_circuits as a global variable; access it with a function instead.
    • Avoid using operators directly as macro arguments: this lets us apply coccinelle transformations to our codebase more directly. Closes ticket 13172.
    • Combine the functions used to parse ClientTransportPlugin and ServerTransportPlugin into a single function. Closes ticket 6456.
    • Add inline functions and convenience macros for inspecting channel state. Refactor the code to use convenience macros instead of checking channel state directly. Fixes issue 7356.
    • Document all members of was_router_added_t and rename ROUTER_WAS_NOT_NEW to ROUTER_IS_ALREADY_KNOWN to make it less confusable with ROUTER_WAS_TOO_OLD. Fixes issue 13644.
    • In connection_exit_begin_conn(), use END_CIRC_REASON_TORPROTOCOL constant instead of hardcoded value. Fixes issue 13840.
    • Refactor our generic strmap and digestmap types into a single implementation, so that we can add a new digest256map type trivially.
  • Documentation:
    • Document the bridge-authority-only 'networkstatus-bridges' file. Closes ticket 13713; patch from "tom".
    • Fix typo in PredictedPortsRelevanceTime option description in manpage. Resolves issue 13707.
    • Stop suggesting that users specify relays by nickname: it isn't a good idea. Also, properly cross-reference how to specify relays in all parts of manual documenting options that take a list of relays. Closes ticket 13381.
    • Clarify the HiddenServiceDir option description in manpage to make it clear that relative paths are taken with respect to the current working directory. Also clarify that this behavior is not guaranteed to remain indefinitely. Fixes issue 13913.
  • Testing:
    • New tests for many parts of channel, relay, and circuitmux functionality. Code by Andrea; part of 9262.
    • New tests for parse_transport_line(). Part of ticket 6456.
    • In the unit tests, use chgrp() to change the group of the unit test temporary directory to the current user, so that the sticky bit doesn't interfere with tests that check directory groups. Closes 13678.
    • Add unit tests for resolve_my_addr(). Part of ticket 12376; patch by 'rl1987'.

Dec 31, 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!