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

Nov 01, 2014

Today Facebook unveiled its hidden service that lets users access their website more safely. Users and journalists have been asking for our response; here are some points to help you understand our thinking.

Part one: yes, visiting Facebook over Tor is not a contradiction

I didn't even realize I should include this section, until I heard from a journalist today who hoped to get a quote from me about why Tor users wouldn't ever use Facebook. Putting aside the (still very important) questions of Facebook's privacy habits, their harmful real-name policies, and whether you should or shouldn't tell them anything about you, the key point here is that anonymity isn't just about hiding from your destination.

There's no reason to let your ISP know when or whether you're visiting Facebook. There's no reason for Facebook's upstream ISP, or some agency that surveils the Internet, to learn when and whether you use Facebook. And if you do choose to tell Facebook something about you, there's still no reason to let them automatically discover what city you're in today while you do it.

Also, we should remember that there are some places in the world that can't reach Facebook. Long ago I talked to a Facebook security person who told me a fun story. When he first learned about Tor, he hated and feared it because it "clearly" intended to undermine their business model of learning everything about all their users. Then suddenly Iran blocked Facebook, a good chunk of the Persian Facebook population switched over to reaching Facebook via Tor, and he became a huge Tor fan because otherwise those users would have been cut off. Other countries like China followed a similar pattern after that. This switch in his mind between "Tor as a privacy tool to let users control their own data" to "Tor as a communications tool to give users freedom to choose what sites they visit" is a great example of the diversity of uses for Tor: whatever it is you think Tor is for, I guarantee there's a person out there who uses it for something you haven't considered.

Part two: we're happy to see broader adoption of hidden services

I think it is great for Tor that Facebook has added a .onion address. There are some compelling use cases for hidden services: see for example the ones described at using Tor hidden services for good, as well as upcoming decentralized chat tools like Ricochet where there's no central point to tap or lean on to retain data. But we haven't really publicized these examples much, especially compared to the publicity that the "I have a website that the man wants to shut down" examples have gotten in recent years.

Hidden services provide a variety of useful security properties. First — and the one that most people think of — because the design uses Tor circuits, it's hard to discover where the service is located in the world. But second, because the address of the service is the hash of its key, they are self-authenticating: if you type in a given .onion address, your Tor client guarantees that it really is talking to the service that knows the private key that corresponds to the address. A third nice feature is that the rendezvous process provides end-to-end encryption, even when the application-level traffic is unencrypted.

So I am excited that this move by Facebook will help to continue opening people's minds about why they might want to offer a hidden service, and help other people think of further novel uses for hidden services.

Another really nice implication here is that Facebook is committing to taking its Tor users seriously. Hundreds of thousands of people have been successfully using Facebook over Tor for years, but in today's era of services like Wikipedia choosing not to accept contributions from users who care about privacy, it is refreshing and heartening to see a large website decide that it's ok for their users to want more safety.

As an addendum to that optimism, I would be really sad if Facebook added a hidden service, had a few problems with trolls, and decided that they should prevent Tor users from using their old https://www.facebook.com/ address. So we should be vigilant in helping Facebook continue to allow Tor users to reach them through either address.

Part three: their vanity address doesn't mean the world has ended

Their hidden service name is "facebookcorewwwi.onion". For a hash of a public key, that sure doesn't look random. Many people have been wondering how they brute forced the entire name.

The short answer is that for the first half of it ("facebook"), which is only 40 bits, they generated keys over and over until they got some keys whose first 40 bits of the hash matched the string they wanted.

Then they had some keys whose name started with "facebook", and they looked at the second half of each of them to pick out the ones with pronouncable and thus memorable syllables. The "corewwwi" one looked best to them — meaning they could come up with a story about why that's a reasonable name for Facebook to use — so they went with it.

So to be clear, they would not be able to produce exactly this name again if they wanted to. They could produce other hashes that start with "facebook" and end with pronouncable syllables, but that's not brute forcing all of the hidden service name (all 80 bits).

For those who want to explore the math more, read about the "birthday attack". And for those who want to learn more (please help!) about the improvements we'd like to make for hidden services, including stronger keys and stronger names, see hidden services need some love and Tor proposal 224.

Part four: what do we think about an https cert for a .onion address?

Facebook didn't just set up a hidden service. They also got an https certificate for their hidden service, and it's signed by Digicert so your browser will accept it. This choice has produced some feisty discussions in the CA/Browser community, which decides what kinds of names can get official certificates. That discussion is still ongoing, but here are my early thoughts on it.

In favor: we, the Internet security community, have taught people that https is necessary and http is scary. So it makes sense that users want to see the string "https" in front of them.

Against: Tor's .onion handshake basically gives you all of that for free, so by encouraging people to pay Digicert we're reinforcing the CA business model when maybe we should be continuing to demonstrate an alternative.

In favor: Actually https does give you a little bit more, in the case where the service (Facebook's webserver farm) isn't in the same location as the Tor program. Remember that there's no requirement for the webserver and the Tor process to be on the same machine, and in a complicated set-up like Facebook's they probably shouldn't be. One could argue that this last mile is inside their corporate network, so who cares if it's unencrypted, but I think the simple phrase "ssl added and removed here" will kill that argument.

Against: if one site gets a cert, it will further reinforce to users that it's "needed", and then the users will start asking other sites why they don't have one. I worry about starting a trend where you need to pay Digicert money to have a hidden service or your users think it's sketchy — especially since hidden services that value their anonymity could have a hard time getting a certificate.

One alternative would be to teach Tor Browser that https .onion addresses don't deserve a scary pop-up warning. A more thorough approach in that direction is to have a way for a hidden service to generate its own signed https cert using its onion private key, and teach Tor Browser how to verify them — basically a decentralized CA for .onion addresses, since they are self-authenticating anyway. Then you don't have to go through the nonsense of pretending to see if they could read email at the domain, and generally furthering the current CA model.

We could also imagine a pet name model where the user can tell her Tor Browser that this .onion address "is" Facebook. Or the more direct approach would be to ship a bookmark list of "known" hidden services in Tor Browser — like being our own CA, using the old-fashioned /etc/hosts model. That approach would raise the political question though of which sites we should endorse in this way.

So I haven't made up my mind yet about which direction I think this discussion should go. I'm sympathetic to "we've taught the users to check for https, so let's not confuse them", but I also worry about the slippery slope where getting a cert becomes a required step to having a reputable service. Let us know if you have other compelling arguments for or against.

Part five: what remains to be done?

In terms of both design and security, hidden services still need some love. We have plans for improved designs (see Tor proposal 224) but we don't have enough funding and developers to make it happen. We've been talking to some Facebook engineers this week about hidden service reliability and scalability, and we're excited that Facebook is thinking of putting development effort into helping improve hidden services.

And finally, speaking of teaching people about the security features of .onion sites, I wonder if "hidden services" is no longer the best phrase here. Originally we called them "location-hidden services", which was quickly shortened in practice to just "hidden services". But protecting the location of the service is just one of the security features you get. Maybe we should hold a contest to come up with a new name for these protected services? Even something like "onion services" might be better if it forces people to learn what it is.

Oct 30, 2014

Tor 0.2.6.1-alpha is the first release in the Tor 0.2.6.x series. It includes numerous code cleanups and new tests, and fixes a large number of annoying bugs. Out-of-memory conditions are handled better than in 0.2.5, pluggable transports have improved proxy support, and clients now use optimistic data for contacting hidden services. Also, we are now more robust to changes in what we consider a parseable directory object, so that tightening restrictions does not have a risk of introducing infinite download loops.

This is the first alpha release in a new series, so expect there to be bugs. Users who would rather test out a more stable branch should stay with 0.2.5.x for now.

This announcement is for the source release only; I'd expect that compiled packages for several platforms should be available over the next several days.

Changes in version 0.2.6.1-alpha - 2014-10-30
  • New compiler and system requirements:
    • Tor 0.2.6.x requires that your compiler support more of the C99 language standard than before. The 'configure' script now detects whether your compiler supports C99 mid-block declarations and designated initializers. If it does not, Tor will not compile.

      We may revisit this requirement if it turns out that a significant number of people need to build Tor with compilers that don't bother implementing a 15-year-old standard. Closes ticket 13233.

    • Tor no longer supports systems without threading support. When we began working on Tor, there were several systems that didn't have threads, or where the thread support wasn't able to run the threads of a single process on multiple CPUs. That no longer holds: every system where Tor needs to run well now has threading support. Resolves ticket 12439.

 

  • Removed platform support:
    • We no longer include special code to build on Windows CE; as far as we know, nobody has used Tor on Windows CE in a very long time. Closes ticket 11446.
  • Major features (bridges):
    • Expose the outgoing upstream HTTP/SOCKS proxy to pluggable transports if they are configured via the "TOR_PT_PROXY" environment variable. Implements proposal 232. Resolves ticket 8402.
  • Major features (client performance, hidden services):
    • Allow clients to use optimistic data when connecting to a hidden service, which should remove a round-trip from hidden service initialization. See proposal 181 for details. Implements ticket 13211.
  • Major features (directory system):
    • Upon receiving an unparseable directory object, if its digest matches what we expected, then don't try to download it again. Previously, when we got a descriptor we didn't like, we would keep trying to download it over and over. Closes ticket 11243.
  • Major features (sample torrc):
    • Add a new, infrequently-changed "torrc.minimal". This file is similar to torrc.sample, but it will change as infrequently as possible, for the benefit of users whose systems prompt them for intervention whenever a default configuration file is changed. Making this change allows us to update torrc.sample to be a more generally useful "sample torrc".
  • Major bugfixes (directory authorities):
    • Do not assign the HSDir flag to relays if they are not Valid, or currently hibernating. Fixes #12573. Bugfix on tor-0.2.0.10-alpha
  • Major bugfixes (directory bandwidth performance):
    • Don't flush the zlib buffer aggressively when compressing directory information for clients. This should save about 7% of the bandwidth currently used for compressed descriptors and microdescriptors. Fixes bug 11787; bugfix on 0.1.1.23.
  • Minor features (security, memory wiping):
    • Ensure we securely wipe keys from memory after crypto_digest_get_digest and init_curve25519_keypair_from_file have finished using them. Resolves ticket 13477.
  • Minor features (security, out-of-memory handling):
    • When handling an out-of-memory condition, allocate less memory for temporary data structures. Fixes issue 10115.
    • When handling an out-of-memory condition, consider more types of buffers, including those on directory connections, and zlib buffers. Resolves ticket 11792.
  • Minor features:
    • When identity keypair is generated for first time, log a congratulatory message that links to the new relay lifecycle document. Implements feature 10427.
  • Minor features (client):
    • Clients are now willing to send optimistic data (before they receive a 'connected' cell) to relays of any version. (Relays without support for optimistic data are no longer supported on the Tor network.) Resolves ticket 13153.
  • Minor features (directory authorities):
    • Don't list relays with a bandwidth estimate of 0 in the consensus. Implements a feature proposed during discussion of bug 13000.
    • In tor-gencert, report an error if the user provides the same argument more than once.
    • If a directory authority can't find a best consensus method in the votes that it holds, it now falls back to its favorite consensus method. Previously, it fell back to method 1. Neither of these is likely to get enough signatures, but "fall back to favorite" doesn't require us to maintain support an obsolete consensus method. Implements part of proposal 215.
  • Minor features (logging):
    • On Unix-like systems, you can now use named pipes as the target of the Log option, and other options that try to append to files. Closes ticket 12061. Patch from "carlo von lynX".
    • When opening a log file at startup, send it every log message that we generated between startup and opening it. Previously, log messages that were generated before opening the log file were only logged to stdout. Closes ticket 6938.
    • Add a TruncateLogFile option to overwrite logs instead of appending to them. Closes ticket #5583.
  • Minor features (portability, Solaris):
    • Threads are no longer disabled by default on Solaris; we believe that the versions of Solaris with broken threading support are all obsolete by now. Resolves ticket 9495.
  • Minor features (relay):
    • Re-check our address after we detect a changed IP address from getsockname(). This ensures that the controller command "GETINFO address" will report the correct value. Resolves ticket 11582. Patch from "ra".
    • A new AccountingRule option lets Relays set whether they'd like AccountingMax to be applied separately to inbound and outbound traffic, or applied to the sum of inbound and outbound traffic. Resolves ticket 961. Patch by "chobe".
  • Minor features (testing networks):
    • Add the TestingDirAuthVoteExit option, which lists nodes to assign the "Exit" flag regardless of their uptime, bandwidth, or exit policy. TestingTorNetwork must be set for this option to have any effect. Previously, authorities would take up to 35 minutes to give nodes the Exit flag in a test network. Partially implements ticket 13161.
  • Minor features (validation):
    • Check all date/time values passed to tor_timegm and parse_rfc1123_time for validity, taking leap years into account. Improves HTTP header validation. Implemented with bug 13476.
    • In correct_tm(), limit the range of values returned by system localtime(_r) and gmtime(_r) to be between the years 1 and 8099. This means we don't have to deal with negative or too large dates, even if a clock is wrong. Otherwise we might fail to read a file written by us which includes such a date. Fixes bug 13476.
  • Minor bugfixes (bridge clients):
    • When configured to use a bridge without an identity digest (not recommended), avoid launching an extra channel to it when bootstrapping. Fixes bug 7733; bugfix on 0.2.4.4-alpha.
  • Minor bugfixes (bridges):
    • When DisableNetwork is set, do not launch pluggable transport plugins, and if any are running, terminate them. Fixes bug 13213; bugfix on 0.2.3.6-alpha.
  • Minor bugfixes (C correctness):
    • Fix several instances of possible integer overflow/underflow/NaN. Fixes bug 13104; bugfix on 0.2.3.1-alpha and later. Patches from "teor".
    • In circuit_build_times_calculate_timeout() in circuitstats.c, avoid dividing by zero in the pareto calculations. This traps under clang's "undefined-trap" sanitizer. Fixes bug 13290; bugfix on tor-0.2.2.2-alpha.
    • Fix an integer overflow in format_time_interval(). Fixes bug 13393; bugfix on 0.2.0.10-alpha.
    • Set the correct day of year value when the system's localtime(_r) or gmtime(_r) functions fail to set struct tm. Not externally visible. Fixes bug 13476; bugfix on 0.0.2pre14.
    • Avoid unlikely signed integer overflow in tor_timegm on systems with 32-bit time_t. Fixes bug 13476; bugfix on 0.0.2pre14.
  • Minor bugfixes (client):
    • Fix smartlist_choose_node_by_bandwidth() so that relays with the BadExit flag are not considered worthy candidates. Fixes bug 13066; bugfix on 0.1.2.3-alpha.
    • Use the consensus schedule for downloading consensuses, and not the generic schedule. Fixes bug 11679; bugfix on 0.2.2.6-alpha.
    • Handle unsupported or malformed SOCKS5 requests properly by responding with the appropriate error message before closing the connection. Fixes bugs 12971 and 13314; bugfix on 0.0.2pre13.
  • Minor bugfixes (client, torrc):
    • Stop modifying the value of our DirReqStatistics torrc option just because we're not a bridge or relay. This bug was causing Tor Browser users to write "DirReqStatistics 0" in their torrc files as if they had chosen to change the config. Fixes bug 4244; bugfix on 0.2.3.1-alpha.
    • When GeoIPExcludeUnkonwn is enabled, do not incorrectly decide that our options have changed every time we SIGHUP. Fixes bug 9801; bugfix on 0.2.4.10-alpha. Patch from "qwerty1".
  • Minor bugfixes (controller):
    • Return an error when the second or later arguments of the "setevents" controller command are invalid events. Previously we would return success while silently skipping invalid events. Fixes bug 13205; bugfix on 0.2.3.2-alpha. Reported by "fpxnns".
  • Minor bugfixes (directory system):
    • Always believe that v3 directory authorities serve extra-info documents, whether they advertise "caches-extra-info" or not. Fixes part of bug 11683; bugfix on 0.2.0.1-alpha.
    • When running as a v3 directory authority, advertise that you serve extra-info documents so that clients who want them can find them from you too. Fixes part of bug 11683; bugfix on 0.2.0.1-alpha.
    • Check the BRIDGE_DIRINFO flag bitwise rather than using equality. Previously, directories offering BRIDGE_DIRINFO and some other flag (i.e. microdescriptors or extrainfo) would be ignored when looking for bridges. Partially fixes bug 13163; bugfix on 0.2.0.7-alpha.
  • Minor bugfixes (networking):
    • Check for orconns and use connection_or_close_for_error() rather than connection_mark_for_close() directly in the getsockopt() failure case of connection_handle_write_impl(). Fixes bug 11302; bugfix on 0.2.4.4-alpha.
  • Minor bugfixes (relay):
    • When generating our family list, remove spaces from around the entries. Fixes bug 12728; bugfix on 0.2.1.7-alpha.
    • If our previous bandwidth estimate was 0 bytes, allow publishing a new relay descriptor immediately. Fixes bug 13000; bugfix on 0.1.1.6-alpha.
  • Minor bugfixes (testing networks):
    • Fix TestingDirAuthVoteGuard to properly give out Guard flags in a testing network. Fixes bug 13064; bugfix on 0.2.5.2-alpha.
    • Stop using the default authorities in networks which provide both AlternateDirAuthority and AlternateBridgeAuthority. Partially fixes bug 13163; bugfix on 0.2.0.13-alpha.
  • Minor bugfixes (testing):
    • Stop spawn test failures due to a race condition between the SIGCHLD handler updating the process status, and the test reading it. Fixes bug 13291; bugfix on 0.2.3.3-alpha.
  • Minor bugfixes (testing, Windows):
    • Avoid passing an extra backslash when creating a temporary directory for running the unit tests on Windows. Fixes bug 12392; bugfix on 0.2.2.25-alpha. Patch from Gisle Vanem.
  • Minor bugfixes (windows):
    • Remove code to special-case handling of NTE_BAD_KEYSET when acquiring windows CryptoAPI context. This error can't actually occur for the parameters we're providing. Fixes bug 10816; bugfix on 0.0.2pre26.
  • Minor bugfixes (zlib):
    • Avoid truncating a zlib stream when trying to finalize it with an empty output buffer. Fixes bug 11824; bugfix on 0.1.1.23.
  • Build fixes:
    • Allow our configure script to build correctly with autoconf 2.62 again. Fixes bug 12693; bugfix on 0.2.5.2-alpha.
    • Improve the error message from ./configure to make it clear that when asciidoc has not been found, the user will have to either add --disable-asciidoc argument or install asciidoc. Resolves ticket 13228.
  • Code simplification and refactoring:
    • Change the entry_is_live() function to take named bitfield elements instead of an unnamed list of booleans. Closes ticket 12202.
    • Refactor and unit-test entry_is_time_to_retry() in entrynodes.c. Resolves ticket 12205.
    • Use calloc and reallocarray functions in preference to multiply- then-malloc. This makes it less likely for us to fall victim to an integer overflow attack when allocating. Resolves ticket 12855.
    • Use the standard macro name SIZE_MAX, instead of our own SIZE_T_MAX.
    • Document usage of the NO_DIRINFO and ALL_DIRINFO flags clearly in functions which take them as arguments. Replace 0 with NO_DIRINFO in a function call for clarity. Seeks to prevent future issues like 13163.
    • Avoid 4 null pointer errors under clang shallow analysis by using tor_assert() to prove that the pointers aren't null. Fixes bug 13284.
    • Rework the API of policies_parse_exit_policy() to use a bitmask to represent parsing options, instead of a confusing mess of booleans. Resolves ticket 8197.
    • Introduce a helper function to parse ExitPolicy in or_options_t structure.
  • Documentation:
    • Add a doc/TUNING document with tips for handling large numbers of TCP connections when running busy Tor relay. Update the warning message to point to this file when running out of sockets operating system is allowing to use simultaneously. Resolves ticket 9708.
  • Removed code:
    • We no longer remind the user about configuration options that have been obsolete since 0.2.3.x or earlier. Patch by Adrien Bak.
  • Removed features:
    • Remove the --disable-curve25519 configure option. Relays and clients now are required to support curve25519 and the ntor handshake.
    • The old "StrictEntryNodes" and "StrictExitNodes" options, which used to be deprecated synonyms for "StrictNodes", are now marked obsolete. Resolves ticket 12226.
    • The "AuthDirRejectUnlisted" option no longer has any effect, as the fingerprints file (approved-routers) has been deprecated.
    • Directory authorities do not support being Naming dirauths anymore. The "NamingAuthoritativeDir" config option is now obsolete.
    • Directory authorities do not support giving out the BadDirectory flag anymore.
    • Clients don't understand the BadDirectory flag in the consensus anymore, and ignore it.
  • Testing:
    • Refactor the function that chooses guard nodes so that it can more easily be tested; write some tests for it.
    • Fix and re-enable the fgets_eagain unit test. Fixes bug 12503; bugfix on 0.2.3.1-alpha. Patch from "cypherpunks."
    • Create unit tests for format_time_interval(). With bug 13393.
    • Add unit tests for tor_timegm signed overflow, tor_timegm and parse_rfc1123_time validity checks, correct_tm year clamping. Unit tests (visible) fixes in bug 13476.
    • Add a "coverage-html" make target to generate HTML-visualized coverage results when building with --enable-coverage. (Requires lcov.) Patch from Kevin Murray.
    • Enable the backtrace handler (where supported) when running the unit tests.
    • Revise all unit tests that used the legacy test_* macros to instead use the recommended tt_* macros. This patch was generated with coccinelle, to avoid manual errors. Closes ticket 13119.
  • Distribution (systemd):
    • systemd unit file: only allow tor to write to /var/lib/tor and /var/log/tor. The rest of the filesystem is accessible for reading only. Patch by intrigeri; resolves ticket 12751.
    • systemd unit file: ensure that the process and all its children can never gain new privileges. Patch by intrigeri; resolves ticket 12939.
    • systemd unit file: set up /var/run/tor as writable for the Tor service. Patch by intrigeri; resolves ticket 13196.
  • Removed features (directory authorities):
    • Remove code that prevented authorities from listing Tor relays affected by CVE-2011-2769 as guards. These relays are already rejected altogether due to the minimum version requirement of 0.2.3.16-alpha. Closes ticket 13152.
    • Directory authorities no longer advertise or support consensus methods 1 through 12 inclusive. These consensus methods were obsolete and/or insecure: maintaining the ability to support them served no good purpose. Implements part of proposal 215; closes ticket 10163.
  • Testing (test-network.sh):
    • Stop using "echo -n", as some shells' built-in echo doesn't support "-n". Instead, use "/bin/echo -n". Partially fixes bug 13161.
    • Stop an apparent test-network hang when used with make -j2. Fixes bug 13331.
    • Add a --delay option to test-network.sh, which configures the delay before the chutney network tests for data transmission. Partially implements ticket 13161.

Oct 29, 2014

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

Tor 0.2.5.10 is out

The 0.2.5.x branch of the core Tor software hit stable, with the release of 0.2.5.10. As Nick Mathewson explained, there have been no changes since last week’s 0.2.5.9-rc release, and the new features will be familiar to readers of Tor Weekly News over the past year of development, but highlights include “improved denial-of-service resistance for relays, new compiler hardening options, and a system-call sandbox for hardened installations on Linux”, as well as improvements to transparent proxying, building and testing, pluggable transport usability, and much more.

This release means that Tor versions in the 0.2.3.x series, which has “received no patches or attention for some while” and “accumulated many known flaws”, are now deprecated. Relay operators running these versions must upgrade as soon as possible, or risk having their relays rejected from the network in the near future.

Please see Nick’s release announcement for the full changelog, and download your copy of the 0.2.5.10 source code from the distribution directory or a prebuilt package from your usual repositories.

Miscellaneous news

Jacob Appelbaum announced version 0.1.3 of TorBirdy, a torifying extension for the Thunderbird email client. Among other things, this release fixes the recently-reported “wrote:” bug, disables the automatic downloading of messages from POP3 accounts, and ensures that draft messages for IMAP accounts are stored on the local system rather than sent over the network. However, as Jacob wrote, “it’s still experimental”, so “use at your own risk”. See the release announcement for a full changelog.

Anthony G. Basile announced version 20141022 of tor-ramdisk, the micro Linux distribution whose only purpose is to host a Tor server in an environment that maximizes security and privacy. This release addresses the recent POODLE attack with updates to Tor and OpenSSL, and also upgrades the Linux kernel.

Yawning Angel called for testing of the revamped tor-fw-helper, a tool that automates the port forwarding required (for example) by the flash proxy pluggable transport. Please see Yawning’s message for full testing instructions and other important information: “Questions, Comments, Feedback appreciated”.

On the Tor blog, Andrew Lewman responded to the abuse of Tor by creators of so-called “ransomware”, or malware that tries to restrict access to users’ files unless a ransom is paid; these extortionists sometimes ask their victims to install Tor software in order to communicate with them over a hidden service, leading users to the mistaken belief that The Tor Project is somehow involved. As Andrew wrote, this software “is unrelated to The Tor Project. We didn’t produce it, and we didn’t ask to be included in the criminal infection of any computer.” Users may find the information provided by the BBC and Bleeping Computer to be helpful in resolving the problem.

Josh Pitts posted an analysis of apparently malicious behavior by a Tor relay that was modifying binary files downloaded over Tor circuits in which it was the exit node. As Roger Dingledine responded, “we’ve now set the BadExit flag on this relay, so others won’t accidentally run across it”.

David Fifield pointed out “an apparent negative correlation between obfs3 users and vanilla users” in the Tor Metrics portal’s bridge user graphs and wondered what might be causing it.

News from Tor StackExchange

Dodo wants to run several hidden services (HTTP, XMPP, SSH etc.), but use just one onion address. Jobiwan explained that one can forward each port to a different service. Further information can be found at the configuration page for hidden services.

Rodney Hester proxies the DirPort of his relay and saw lots of requests to nonexistent URLs, of which the most prominent is the URL /tor/status/all.z, and asks where they are coming from. Do you have an answer? If so, please share it at Tor’s StackExchange site.


This issue of Tor Weekly News has been assembled by Lunar, qbi, Roger Dingledine, and 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!

Oct 27, 2014

Tor 0.2.5.10 is the first stable release in the 0.2.5 series.

It adds several new security features, including improved denial-of-service resistance for relays, new compiler hardening options, and a system-call sandbox for hardened installations on Linux (requires seccomp2). The controller protocol has several new features, resolving IPv6 addresses should work better than before, and relays should be a little more CPU-efficient. We've added support for more OpenBSD and FreeBSD transparent proxy types. We've improved the build system and testing infrastructure to allow unit testing of more parts of the Tor codebase. Finally, we've addressed several nagging pluggable transport usability issues, and included numerous other small bugfixes and features mentioned below.

This release marks end-of-life for Tor 0.2.3.x; those Tor versions have accumulated many known flaws; everyone should upgrade.

Below we list all changes in 0.2.5.10 since the 0.2.4.x series; for a list of changes in individual alpha releases, see the ChangeLog.

Changes in version 0.2.5.10 - 2014-10-24

  • Major features (security):
    • The ntor handshake is now on-by-default, no matter what the directory authorities recommend. Implements ticket 8561.
    • Make the "tor-gencert" tool used by directory authority operators create 2048-bit signing keys by default (rather than 1024-bit, since 1024-bit is uncomfortably small these days). Addresses ticket 10324.
    • Warn about attempts to run hidden services and relays in the same process: that's probably not a good idea. Closes ticket 12908.
    • Disable support for SSLv3. All versions of OpenSSL in use with Tor today support TLS 1.0 or later, so we can safely turn off support for this old (and insecure) protocol. Fixes bug 13426.
  • Major features (relay security, DoS-resistance):
    • When deciding whether we have run out of memory and we need to close circuits, also consider memory allocated in buffers for streams attached to each circuit.

      This change, which extends an anti-DoS feature introduced in 0.2.4.13-alpha and improved in 0.2.4.14-alpha, lets Tor exit relays better resist more memory-based DoS attacks than before. Since the MaxMemInCellQueues option now applies to all queues, it is renamed to MaxMemInQueues. This feature fixes bug 10169.

    • Avoid hash-flooding denial-of-service attacks by using the secure SipHash-2-4 hash function for our hashtables. Without this feature, an attacker could degrade performance of a targeted client or server by flooding their data structures with a large number of entries to be stored at the same hash table position, thereby slowing down the Tor instance. With this feature, hash table positions are derived from a randomized cryptographic key, and an attacker cannot predict which entries will collide. Closes ticket 4900.
    • If you don't specify MaxMemInQueues yourself, Tor now tries to pick a good value based on your total system memory. Previously, the default was always 8 GB. You can still override the default by setting MaxMemInQueues yourself. Resolves ticket 11396.
  • Major features (bridges and pluggable transports):
    • Add support for passing arguments to managed pluggable transport proxies. Implements ticket 3594.
    • Bridges now track GeoIP information and the number of their users even when pluggable transports are in use, and report usage statistics in their extra-info descriptors. Resolves tickets 4773 and 5040.
    • Don't launch pluggable transport proxies if we don't have any bridges configured that would use them. Now we can list many pluggable transports, and Tor will dynamically start one when it hears a bridge address that needs it. Resolves ticket 5018.
    • The bridge directory authority now assigns status flags (Stable, Guard, etc) to bridges based on thresholds calculated over all Running bridges. Now bridgedb can finally make use of its features to e.g. include at least one Stable bridge in its answers. Fixes bug 9859.
  • Major features (controller):
    • Extend ORCONN controller event to include an "ID" parameter, and add four new controller event types CONN_BW, CIRC_BW, CELL_STATS, and TB_EMPTY that show connection and circuit usage. The new events are emitted in private Tor networks only, with the goal of being able to better track performance and load during full-network simulations. Implements proposal 218 and ticket 7359.
  • Major features (relay performance):
    • Speed up server-side lookups of rendezvous and introduction point circuits by using hashtables instead of linear searches. These functions previously accounted between 3 and 7% of CPU usage on some busy relays. Resolves ticket 9841.
    • Avoid wasting CPU when extending a circuit over a channel that is nearly out of circuit IDs. Previously, we would do a linear scan over possible circuit IDs before finding one or deciding that we had exhausted our possibilities. Now, we try at most 64 random circuit IDs before deciding that we probably won't succeed. Fixes a possible root cause of ticket 11553.
  • Major features (seccomp2 sandbox, Linux only):
    • Use the seccomp2 syscall filtering facility on Linux to limit which system calls Tor can invoke. This is an experimental, Linux-only feature to provide defense-in-depth against unknown attacks. To try turning it on, set "Sandbox 1" in your torrc file. Please be ready to report bugs. We hope to add support for better sandboxing in the future, including more fine-grained filters, better division of responsibility, and support for more platforms. This work has been done by Cristian-Matei Toader for Google Summer of Code. Resolves tickets 11351 and 11465.
  • Major features (testing networks):
    • Make testing Tor networks bootstrap better: lower directory fetch retry schedules and maximum interval without directory requests, and raise maximum download tries. Implements ticket 6752.
    • Add make target 'test-network' to run tests on a Chutney network. Implements ticket 8530.
  • Major features (other):
    • On some platforms (currently: recent OSX versions, glibc-based platforms that support the ELF format, and a few other Unix-like operating systems), Tor can now dump stack traces when a crash occurs or an assertion fails. By default, traces are dumped to stderr (if possible) and to any logs that are reporting errors. Implements ticket 9299.
  • Deprecated versions:
    • Tor 0.2.3.x has reached end-of-life; it has received no patches or attention for some while.
  • Major bugfixes (security, directory authorities):
    • Directory authorities now include a digest of each relay's identity key as a part of its microdescriptor.

      This is a workaround for bug 11743 (reported by "cypherpunks"), where Tor clients do not support receiving multiple microdescriptors with the same SHA256 digest in the same consensus. When clients receive a consensus like this, they only use one of the relays. Without this fix, a hostile relay could selectively disable some client use of target relays by constructing a router descriptor with a different identity and the same microdescriptor parameters and getting the authorities to list it in a microdescriptor consensus. This fix prevents an attacker from causing a microdescriptor collision, because the router's identity is not forgeable.

  • Major bugfixes (openssl bug workaround):
    • Avoid crashing when using OpenSSL version 0.9.8zc, 1.0.0o, or 1.0.1j, built with the 'no-ssl3' configuration option. Fixes bug 13471. This is a workaround for an OpenSSL bug.
  • Major bugfixes (client):
    • Perform circuit cleanup operations even when circuit construction operations are disabled (because the network is disabled, or because there isn't enough directory information). Previously, when we were not building predictive circuits, we were not closing expired circuits either. Fixes bug 8387; bugfix on 0.1.1.11-alpha. This bug became visible in 0.2.4.10-alpha when we became more strict about when we have "enough directory information to build circuits".
  • Major bugfixes (client, pluggable transports):
    • When managing pluggable transports, use OS notification facilities to learn if they have crashed, and don't attempt to kill any process that has already exited. Fixes bug 8746; bugfix on 0.2.3.6-alpha.
  • Major bugfixes (relay denial of service):
    • Instead of writing destroy cells directly to outgoing connection buffers, queue them and intersperse them with other outgoing cells. This can prevent a set of resource starvation conditions where too many pending destroy cells prevent data cells from actually getting delivered. Reported by "oftc_must_be_destroyed". Fixes bug 7912; bugfix on 0.2.0.1-alpha.
  • Major bugfixes (relay):
    • Avoid queuing or sending destroy cells for circuit ID zero when we fail to send a CREATE cell. Fixes bug 12848; bugfix on 0.0.8pre1. Found and fixed by "cypherpunks".
    • Fix ORPort reachability detection on relays running behind a proxy, by correctly updating the "local" mark on the controlling channel when changing the address of an or_connection_t after the handshake. Fixes bug 12160; bugfix on 0.2.4.4-alpha.
    • Use a direct dirport connection when uploading non-anonymous descriptors to the directory authorities. Previously, relays would incorrectly use tunnel connections under a fairly wide variety of circumstances. Fixes bug 11469; bugfix on 0.2.4.3-alpha.
    • When a circuit accidentally has the same circuit ID for its forward and reverse direction, correctly detect the direction of cells using that circuit. Previously, this bug made roughly one circuit in a million non-functional. Fixes bug 12195; this is a bugfix on every version of Tor.
  • Minor features (security):
    • New --enable-expensive-hardening option to enable security hardening options that consume nontrivial amounts of CPU and memory. Right now, this includes AddressSanitizer and UbSan, which are supported in newer versions of GCC and Clang. Closes ticket 11477.
    • Authorities now assign the Guard flag to the fastest 25% of the network (it used to be the fastest 50%). Also raise the consensus weight that guarantees the Guard flag from 250 to 2000. For the current network, this results in about 1100 guards, down from 2500. This step paves the way for moving the number of entry guards down to 1 (proposal 236) while still providing reasonable expected performance for most users. Implements ticket 12690.
  • Minor features (security, memory management):
    • Memory allocation tricks (mempools and buffer freelists) are now disabled by default. You can turn them back on with --enable-mempools and --enable-buf-freelists respectively. We're disabling these features because malloc performance is good enough on most platforms, and a similar feature in OpenSSL exacerbated exploitation of the Heartbleed attack. Resolves ticket 11476.
  • Minor features (bridge client):
    • Report a more useful failure message when we can't connect to a bridge because we don't have the right pluggable transport configured. Resolves ticket 9665. Patch from Fábio J. Bertinatto.
  • Minor features (bridge):
    • Add an ExtORPortCookieAuthFileGroupReadable option to make the cookie file for the ExtORPort g+r by default.
  • Minor features (bridges, pluggable transports):
    • Bridges now write the SHA1 digest of their identity key fingerprint (that is, a hash of a hash of their public key) to notice-level logs, and to a new hashed-fingerprint file. This information will help bridge operators look up their bridge in Globe and similar tools. Resolves ticket 10884.
    • Improve the message that Tor displays when running as a bridge using pluggable transports without an Extended ORPort listener. Also, log the message in the log file too. Resolves ticket 11043.
    • Add threshold cutoffs to the networkstatus document created by the Bridge Authority. Fixes bug 1117.
    • On Windows, spawn background processes using the CREATE_NO_WINDOW flag. Now Tor Browser Bundle 3.5 with pluggable transports enabled doesn't pop up a blank console window. (In Tor Browser Bundle 2.x, Vidalia set this option for us.) Implements ticket 10297.
  • Minor features (build):
    • The configure script has a --disable-seccomp option to turn off support for libseccomp on systems that have it, in case it (or Tor's use of it) is broken. Resolves ticket 11628.
    • Assume that a user using ./configure --host wants to cross-compile, and give an error if we cannot find a properly named tool-chain. Add a --disable-tool-name-check option to proceed nevertheless. Addresses ticket 9869. Patch by Benedikt Gollatz.
    • If we run ./configure and the compiler recognizes -fstack-protector but the linker rejects it, warn the user about a potentially missing libssp package. Addresses ticket 9948. Patch from Benedikt Gollatz.
    • Add support for `--library-versions` flag. Implements ticket 6384.
    • Return the "unexpected sendme" warnings to a warn severity, but make them rate limited, to help diagnose ticket 8093.
    • Detect a missing asciidoc, and warn the user about it, during configure rather than at build time. Fixes issue 6506. Patch from Arlo Breault.
  • Minor features (client):
    • Add a new option, PredictedPortsRelevanceTime, to control how long after having received a request to connect to a given port Tor will try to keep circuits ready in anticipation of future requests for that port. Patch from "unixninja92"; implements ticket 9176.
  • Minor features (config options and command line):
    • Add an --allow-missing-torrc commandline option that tells Tor to run even if the configuration file specified by -f is not available. Implements ticket 10060.
    • Add support for the TPROXY transparent proxying facility on Linux. See documentation for the new TransProxyType option for more details. Implementation by "thomo". Closes ticket 10582.
  • Minor features (config options):
    • Config (torrc) lines now handle fingerprints which are missing their initial '$'. Resolves ticket 4341; improvement over 0.0.9pre5.
    • Support a --dump-config option to print some or all of the configured options. Mainly useful for debugging the command-line option parsing code. Helps resolve ticket 4647.
    • Raise awareness of safer logging: notify user of potentially unsafe config options, like logging more verbosely than severity "notice" or setting SafeLogging to 0. Resolves ticket 5584.
    • Add a new configuration option TestingV3AuthVotingStartOffset that bootstraps a network faster by changing the timing for consensus votes. Addresses ticket 8532.
    • Add a new torrc option "ServerTransportOptions" that allows bridge operators to pass configuration parameters to their pluggable transports. Resolves ticket 8929.
    • The config (torrc) file now accepts bandwidth and space limits in bits as well as bytes. (Anywhere that you can say "2 Kilobytes", you can now say "16 kilobits", and so on.) Resolves ticket 9214. Patch by CharlieB.
  • Minor features (controller):
    • Make the entire exit policy available from the control port via GETINFO exit-policy/*. Implements enhancement 7952. Patch from "rl1987".
    • Because of the fix for ticket 11396, the real limit for memory usage may no longer match the configured MaxMemInQueues value. The real limit is now exposed via GETINFO limits/max-mem-in-queues.
    • Add a new "HS_DESC" controller event that reports activities related to hidden service descriptors. Resolves ticket 8510.
    • New "DROPGUARDS" controller command to forget all current entry guards. Not recommended for ordinary use, since replacing guards too frequently makes several attacks easier. Resolves ticket 9934; patch from "ra".
    • Implement the TRANSPORT_LAUNCHED control port event that notifies controllers about new launched pluggable transports. Resolves ticket 5609.
  • Minor features (diagnostic):
    • When logging a warning because of bug 7164, additionally check the hash table for consistency (as proposed on ticket 11737). This may help diagnose bug 7164.
    • When we log a heartbeat, log how many one-hop circuits we have that are at least 30 minutes old, and log status information about a few of them. This is an attempt to track down bug 8387.
    • When encountering an unexpected CR while writing text to a file on Windows, log the name of the file. Should help diagnosing bug 11233.
    • Give more specific warnings when a client notices that an onion handshake has failed. Fixes ticket 9635.
    • Add significant new logging code to attempt to diagnose bug 12184, where relays seem to run out of available circuit IDs.
    • Improve the diagnostic log message for bug 8387 even further to try to improve our odds of figuring out why one-hop directory circuits sometimes do not get closed.
    • Add more log messages to diagnose bug 7164, which causes intermittent "microdesc_free() called but md was still referenced" warnings. We now include more information, to figure out why we might be cleaning a microdescriptor for being too old if it's still referenced by a live node_t object.
    • Log current accounting state (bytes sent and received + remaining time for the current accounting period) in the relay's heartbeat message. Implements ticket 5526; patch from Peter Retzlaff.
  • Minor features (geoip):
    • Update geoip and geoip6 to the August 7 2014 Maxmind GeoLite2 Country database.
  • Minor features (interface):
    • Generate a warning if any ports are listed in the SocksPolicy, DirPolicy, AuthDirReject, AuthDirInvalid, AuthDirBadDir, or AuthDirBadExit options. (These options only support address ranges.) Fixes part of ticket 11108.
  • Minor features (kernel API usage):
    • Use the SOCK_NONBLOCK socket type, if supported, to open nonblocking sockets in a single system call. Implements ticket 5129.
  • Minor features (log messages):
    • When ServerTransportPlugin is set on a bridge, Tor can write more useful statistics about bridge use in its extrainfo descriptors, but only if the Extended ORPort ("ExtORPort") is set too. Add a log message to inform the user in this case. Resolves ticket 9651.
    • When receiving a new controller connection, log the origin address. Resolves ticket 9698; patch from "sigpipe".
    • When logging OpenSSL engine status at startup, log the status of more engines. Fixes ticket 10043; patch from Joshua Datko.
  • Minor features (log verbosity):
    • Demote the message that we give when a flushing connection times out for too long from NOTICE to INFO. It was usually meaningless. Resolves ticket 5286.
    • Don't log so many notice-level bootstrapping messages at startup about downloading descriptors. Previously, we'd log a notice whenever we learned about more routers. Now, we only log a notice at every 5% of progress. Fixes bug 9963.
    • Warn less verbosely when receiving a malformed ESTABLISH_RENDEZVOUS cell. Fixes ticket 11279.
  • Minor features (performance):
    • If we're using the pure-C 32-bit curve25519_donna implementation of curve25519, build it with the -fomit-frame-pointer option to make it go faster on register-starved hosts. This improves our handshake performance by about 6% on i386 hosts without nacl. Closes ticket 8109.
  • Minor features (relay):
    • If a circuit timed out for at least 3 minutes, check if we have a new external IP address, and publish a new descriptor with the new IP address if it changed. Resolves ticket 2454.
  • Minor features (testing):
    • If Python is installed, "make check" now runs extra tests beyond the unit test scripts.
    • When bootstrapping a test network, sometimes very few relays get the Guard flag. Now a new option "TestingDirAuthVoteGuard" can specify a set of relays which should be voted Guard regardless of their uptime or bandwidth. Addresses ticket 9206.
  • Minor features (transparent proxy, *BSD):
    • Support FreeBSD's ipfw firewall interface for TransPort ports on FreeBSD. To enable it, set "TransProxyType ipfw". Resolves ticket 10267; patch from "yurivict".
    • Support OpenBSD's divert-to rules with the pf firewall for transparent proxy ports. To enable it, set "TransProxyType pf-divert". This allows Tor to run a TransPort transparent proxy port on OpenBSD 4.4 or later without root privileges. See the pf.conf(5) manual page for information on configuring pf to use divert-to rules. Closes ticket 10896; patch from Dana Koch.
  • Minor bugfixes (bridge client):
    • Stop accepting bridge lines containing hostnames. Doing so would cause clients to perform DNS requests on the hostnames, which was not sensible behavior. Fixes bug 10801; bugfix on 0.2.0.1-alpha.
  • Minor bugfixes (bridges):
    • Avoid potential crashes or bad behavior when launching a server-side managed proxy with ORPort or ExtORPort temporarily disabled. Fixes bug 9650; bugfix on 0.2.3.16-alpha.
    • Fix a bug where the first connection works to a bridge that uses a pluggable transport with client-side parameters, but we don't send the client-side parameters on subsequent connections. (We don't use any pluggable transports with client-side parameters yet, but ScrambleSuit will soon become the first one.) Fixes bug 9162; bugfix on 0.2.0.3-alpha. Based on a patch from "rl1987".
  • Minor bugfixes (build, auxiliary programs):
    • Stop preprocessing the "torify" script with autoconf, since it no longer refers to LOCALSTATEDIR. Fixes bug 5505; patch from Guilhem.
    • The tor-fw-helper program now follows the standard convention and exits with status code "0" on success. Fixes bug 9030; bugfix on 0.2.3.1-alpha. Patch by Arlo Breault.
    • Corrected ./configure advice for what openssl dev package you should install on Debian. Fixes bug 9207; bugfix on 0.2.0.1-alpha.
  • Minor bugfixes (client):
    • Avoid "Tried to open a socket with DisableNetwork set" warnings when starting a client with bridges configured and DisableNetwork set. (Tor launcher starts Tor with DisableNetwork set the first time it runs.) Fixes bug 10405; bugfix on 0.2.3.9-alpha.
    • Improve the log message when we can't connect to a hidden service because all of the hidden service directory nodes hosting its descriptor are excluded. Improves on our fix for bug 10722, which was a bugfix on 0.2.0.10-alpha.
    • Raise a control port warning when we fail to connect to all of our bridges. Previously, we didn't inform the controller, and the bootstrap process would stall. Fixes bug 11069; bugfix on 0.2.1.2-alpha.
    • Exit immediately when a process-owning controller exits. Previously, tor relays would wait for a little while after their controller exited, as if they had gotten an INT signal -- but this was problematic, since there was no feedback for the user. To do a clean shutdown, controllers should send an INT signal and give Tor a chance to clean up. Fixes bug 10449; bugfix on 0.2.2.28-beta.
    • Stop attempting to connect to bridges before our pluggable transports are configured (harmless but resulted in some erroneous log messages). Fixes bug 11156; bugfix on 0.2.3.2-alpha.
    • Fix connections to IPv6 addresses over SOCKS5. Previously, we were generating incorrect SOCKS5 responses, and confusing client applications. Fixes bug 10987; bugfix on 0.2.4.7-alpha.
  • Minor bugfixes (client, DNSPort):
    • When using DNSPort, try to respond to AAAA requests with AAAA answers. Previously, we hadn't looked at the request type when deciding which answer type to prefer. Fixes bug 10468; bugfix on 0.2.4.7-alpha.
    • When receiving a DNS query for an unsupported record type, reply with no answer rather than with a NOTIMPL error. This behavior isn't correct either, but it will break fewer client programs, we hope. Fixes bug 10268; bugfix on 0.2.0.1-alpha. Original patch from "epoch".
  • Minor bugfixes (client, logging during bootstrap):
    • Only report the first fatal bootstrap error on a given OR connection. This stops us from telling the controller bogus error messages like "DONE". Fixes bug 10431; bugfix on 0.2.1.1-alpha.
    • Avoid generating spurious warnings when starting with DisableNetwork enabled. Fixes bug 11200 and bug 10405; bugfix on 0.2.3.9-alpha.
  • Minor bugfixes (closing OR connections):
    • If write_to_buf() in connection_write_to_buf_impl_() ever fails, check if it's an or_connection_t and correctly call connection_or_close_for_error() rather than connection_mark_for_close() directly. Fixes bug 11304; bugfix on 0.2.4.4-alpha.
    • When closing all connections on setting DisableNetwork to 1, use connection_or_close_normally() rather than closing OR connections out from under the channel layer. Fixes bug 11306; bugfix on 0.2.4.4-alpha.
  • Minor bugfixes (code correctness):
    • Previously we used two temporary files when writing descriptors to disk; now we only use one. Fixes bug 1376.
    • Remove an erroneous (but impossible and thus harmless) pointer comparison that would have allowed compilers to skip a bounds check in channeltls.c. Fixes bugs 10313 and 9980; bugfix on 0.2.0.10-alpha. Noticed by Jared L Wong and David Fifield.
    • Fix an always-true assertion in pluggable transports code so it actually checks what it was trying to check. Fixes bug 10046; bugfix on 0.2.3.9-alpha. Found by "dcb".
  • Minor bugfixes (command line):
    • Use a single command-line parser for parsing torrc options on the command line and for finding special command-line options to avoid inconsistent behavior for torrc option arguments that have the same names as command-line options. Fixes bugs 4647 and 9578; bugfix on 0.0.9pre5.
    • No longer allow 'tor --hash-password' with no arguments. Fixes bug 9573; bugfix on 0.0.9pre5.
  • Minor bugfixes (compilation):
    • Compile correctly with builds and forks of OpenSSL (such as LibreSSL) that disable compression. Fixes bug 12602; bugfix on 0.2.1.1-alpha. Patch from "dhill".
    • Restore the ability to compile Tor with V2_HANDSHAKE_SERVER turned off (that is, without support for v2 link handshakes). Fixes bug 4677; bugfix on 0.2.3.2-alpha. Patch from "piet".
    • In routerlist_assert_ok(), don't take the address of a routerinfo's cache_info member unless that routerinfo is non-NULL. Fixes bug 13096; bugfix on 0.1.1.9-alpha. Patch by "teor".
    • Fix a large number of false positive warnings from the clang analyzer static analysis tool. This should make real warnings easier for clang analyzer to find. Patch from "teor". Closes ticket 13036.
    • Resolve GCC complaints on OpenBSD about discarding constness in TO_{ORIGIN,OR}_CIRCUIT functions. Fixes part of bug 11633; bugfix on 0.1.1.23. Patch from Dana Koch.
    • Resolve clang complaints on OpenBSD with -Wshorten-64-to-32 due to treatment of long and time_t as comparable types. Fixes part of bug 11633. Patch from Dana Koch.
    • When deciding whether to build the 64-bit curve25519 implementation, detect platforms where we can compile 128-bit arithmetic but cannot link it. Fixes bug 11729; bugfix on 0.2.4.8-alpha. Patch from "conradev".
    • Fix compilation when DNS_CACHE_DEBUG is enabled. Fixes bug 11761; bugfix on 0.2.3.13-alpha. Found by "cypherpunks".
    • Fix compilation with dmalloc. Fixes bug 11605; bugfix on 0.2.4.10-alpha.
    • Build and run correctly on systems like OpenBSD-current that have patched OpenSSL to remove get_cipher_by_char and/or its implementations. Fixes issue 13325.
  • Minor bugfixes (controller and command-line):
    • If changing a config option via "setconf" fails in a recoverable way, we used to nonetheless write our new control ports to the file described by the "ControlPortWriteToFile" option. Now we only write out that file if we successfully switch to the new config option. Fixes bug 5605; bugfix on 0.2.2.26-beta. Patch from "Ryman".
  • Minor bugfixes (directory server):
    • No longer accept malformed http headers when parsing urls from headers. Now we reply with Bad Request ("400"). Fixes bug 2767; bugfix on 0.0.6pre1.
    • When sending a compressed set of descriptors or microdescriptors, make sure to finalize the zlib stream. Previously, we would write all the compressed data, but if the last descriptor we wanted to send was missing or too old, we would not mark the stream as finished. This caused problems for decompression tools. Fixes bug 11648; bugfix on 0.1.1.23.
  • Minor bugfixes (hidden service):
    • Only retry attempts to connect to a chosen rendezvous point 8 times, not 30. Fixes bug 4241; bugfix on 0.1.0.1-rc.
  • Minor bugfixes (interface):
    • Reject relative control socket paths and emit a warning. Previously, single-component control socket paths would be rejected, but Tor would not log why it could not validate the config. Fixes bug 9258; bugfix on 0.2.3.16-alpha.
  • Minor bugfixes (log messages):
    • Fix a bug where clients using bridges would report themselves as 50% bootstrapped even without a live consensus document. Fixes bug 9922; bugfix on 0.2.1.1-alpha.
    • Suppress a warning where, if there's only one directory authority in the network, we would complain that votes and signatures cannot be uploaded to other directory authorities. Fixes bug 10842; bugfix on 0.2.2.26-beta.
    • Report bootstrapping progress correctly when we're downloading microdescriptors. We had updated our "do we have enough microdescs to begin building circuits?" logic most recently in 0.2.4.10-alpha (see bug 5956), but we left the bootstrap status event logic at "how far through getting 1/4 of them are we?" Fixes bug 9958; bugfix on 0.2.2.36, which is where they diverged (see bug 5343).
  • Minor bugfixes (logging):
    • Downgrade "Unexpected onionskin length after decryption" warning to a protocol-warn, since there's nothing relay operators can do about a client that sends them a malformed create cell. Resolves bug 12996; bugfix on 0.0.6rc1.
    • Log more specific warnings when we get an ESTABLISH_RENDEZVOUS cell on a cannibalized or non-OR circuit. Resolves ticket 12997.
    • When logging information about an EXTEND2 or EXTENDED2 cell, log their names correctly. Fixes part of bug 12700; bugfix on 0.2.4.8-alpha.
    • When logging information about a relay cell whose command we don't recognize, log its command as an integer. Fixes part of bug 12700; bugfix on 0.2.1.10-alpha.
    • Escape all strings from the directory connection before logging them. Fixes bug 13071; bugfix on 0.1.1.15. Patch from "teor".
    • Squelch a spurious LD_BUG message "No origin circuit for successful SOCKS stream" in certain hidden service failure cases; fixes bug 10616.
    • Downgrade the severity of the 'unexpected sendme cell from client' from 'warn' to 'protocol warning'. Closes ticket 8093.
  • Minor bugfixes (misc code correctness):
    • In munge_extrainfo_into_routerinfo(), check the return value of memchr(). This would have been a serious issue if we ever passed it a non-extrainfo. Fixes bug 8791; bugfix on 0.2.0.6-alpha. Patch from Arlo Breault.
    • On the chance that somebody manages to build Tor on a platform where time_t is unsigned, correct the way that microdesc_add_to_cache() handles negative time arguments. Fixes bug 8042; bugfix on 0.2.3.1-alpha.
    • Fix various instances of undefined behavior in channeltls.c, tor_memmem(), and eventdns.c that would cause us to construct pointers to memory outside an allocated object. (These invalid pointers were not accessed, but C does not even allow them to exist.) Fixes bug 10363; bugfixes on 0.1.1.1-alpha, 0.1.2.1-alpha, 0.2.0.10-alpha, and 0.2.3.6-alpha. Reported by "bobnomnom".
    • Use the AddressSanitizer and Ubsan sanitizers (in clang-3.4) to fix some miscellaneous errors in our tests and codebase. Fixes bug 11232. Bugfixes on versions back as far as 0.2.1.11-alpha.
    • Always check return values for unlink, munmap, UnmapViewOfFile; check strftime return values more often. In some cases all we can do is report a warning, but this may help prevent deeper bugs from going unnoticed. Closes ticket 8787; bugfixes on many, many tor versions.
    • Fix numerous warnings from the clang "scan-build" static analyzer. Some of these are programming style issues; some of them are false positives that indicated awkward code; some are undefined behavior cases related to constructing (but not using) invalid pointers; some are assumptions about API behavior; some are (harmlessly) logging sizeof(ptr) bytes from a token when sizeof(*ptr) would be correct; and one or two are genuine bugs that weren't reachable from the rest of the program. Fixes bug 8793; bugfixes on many, many tor versions.
  • Minor bugfixes (node selection):
    • If ExcludeNodes is set, consider non-excluded hidden service directory servers before excluded ones. Do not consider excluded hidden service directory servers at all if StrictNodes is set. (Previously, we would sometimes decide to connect to those servers, and then realize before we initiated a connection that we had excluded them.) Fixes bug 10722; bugfix on 0.2.0.10-alpha. Reported by "mr-4".
    • If we set the ExitNodes option but it doesn't include any nodes that have the Exit flag, we would choose not to bootstrap. Now we bootstrap so long as ExitNodes includes nodes which can exit to some port. Fixes bug 10543; bugfix on 0.2.4.10-alpha.
  • Minor bugfixes (performance):
    • Avoid a bug where every successful connection made us recompute the flag telling us whether we have sufficient information to build circuits. Previously, we would forget our cached value whenever we successfully opened a channel (or marked a router as running or not running for any other reason), regardless of whether we had previously believed the router to be running. This forced us to run an expensive update operation far too often. Fixes bug 12170; bugfix on 0.1.2.1-alpha.
    • Avoid using tor_memeq() for checking relay cell integrity. This removes a possible performance bottleneck. Fixes part of bug 12169; bugfix on 0.2.1.31.
  • Minor bugfixes (platform-specific):
    • When dumping a malformed directory object to disk, save it in binary mode on Windows, not text mode. Fixes bug 11342; bugfix on 0.2.2.1-alpha.
    • Don't report failures from make_socket_reuseable() on incoming sockets on OSX: this can happen when incoming connections close early. Fixes bug 10081.
  • Minor bugfixes (pluggable transports):
    • Avoid another 60-second delay when starting Tor in a pluggable- transport-using configuration when we already have cached descriptors for our bridges. Fixes bug 11965; bugfix on 0.2.3.6-alpha.
  • Minor bugfixes (protocol correctness):
    • When receiving a VERSIONS cell with an odd number of bytes, close the connection immediately since the cell is malformed. Fixes bug 10365; bugfix on 0.2.0.10-alpha. Spotted by "bobnomnom"; fix by "rl1987".
  • Minor bugfixes (relay, other):
    • We now drop CREATE cells for already-existent circuit IDs and for zero-valued circuit IDs, regardless of other factors that might otherwise have called for DESTROY cells. Fixes bug 12191; bugfix on 0.0.8pre1.
    • When rejecting DATA cells for stream_id zero, still count them against the circuit's deliver window so that we don't fail to send a SENDME. Fixes bug 11246; bugfix on 0.2.4.10-alpha.
  • Minor bugfixes (relay, threading):
    • Check return code on spawn_func() in cpuworker code, so that we don't think we've spawned a nonworking cpuworker and write junk to it forever. Fix related to bug 4345; bugfix on all released Tor versions. Found by "skruffy".
    • Use a pthread_attr to make sure that spawn_func() cannot return an error while at the same time launching a thread. Fix related to bug 4345; bugfix on all released Tor versions. Reported by "cypherpunks".
  • Minor bugfixes (relays and bridges):
    • Avoid crashing on a malformed resolv.conf file when running a relay using Libevent 1. Fixes bug 8788; bugfix on 0.1.1.23.
    • Non-exit relays no longer launch mock DNS requests to check for DNS hijacking. This has been unnecessary since 0.2.1.7-alpha, when non-exit relays stopped servicing DNS requests. Fixes bug 965; bugfix on 0.2.1.7-alpha. Patch from Matt Pagan.
    • Bridges now report complete directory request statistics. Related to bug 5824; bugfix on 0.2.2.1-alpha.
    • Bridges now never collect statistics that were designed for relays. Fixes bug 5824; bugfix on 0.2.3.8-alpha.
  • Minor bugfixes (testing):
    • Fix all valgrind warnings produced by the unit tests. There were over a thousand memory leak warnings previously, mostly produced by forgetting to free things in the unit test code. Fixes bug 11618, bugfixes on many versions of Tor.
  • Minor bugfixes (tor-fw-helper):
    • Give a correct log message when tor-fw-helper fails to launch. (Previously, we would say something like "tor-fw-helper sent us a string we could not parse".) Fixes bug 9781; bugfix on 0.2.4.2-alpha.
  • Minor bugfixes (trivial memory leaks):
    • Fix a small memory leak when signing a directory object. Fixes bug 11275; bugfix on 0.2.4.13-alpha.
    • Resolve some memory leaks found by coverity in the unit tests, on exit in tor-gencert, and on a failure to compute digests for our own keys when generating a v3 networkstatus vote. These leaks should never have affected anyone in practice.
  • Code simplification and refactoring:
    • Remove some old fallback code designed to keep Tor clients working in a network with only two working relays. Elsewhere in the code we have long since stopped supporting such networks, so there wasn't much point in keeping it around. Addresses ticket 9926.
    • Reject 0-length EXTEND2 cells more explicitly. Fixes bug 10536; bugfix on 0.2.4.8-alpha. Reported by "cypherpunks".
    • Extract the common duplicated code for creating a subdirectory of the data directory and writing to a file in it. Fixes ticket 4282; patch from Peter Retzlaff.
    • Since OpenSSL 0.9.7, the i2d_*() functions support allocating output buffer. Avoid calling twice: i2d_RSAPublicKey(), i2d_DHparams(), i2d_X509(), and i2d_PublicKey(). Resolves ticket 5170.
    • Add a set of accessor functions for the circuit timeout data structure. Fixes ticket 6153; patch from "piet".
    • Clean up exit paths from connection_listener_new(). Closes ticket 8789. Patch from Arlo Breault.
    • Since we rely on OpenSSL 0.9.8 now, we can use EVP_PKEY_cmp() and drop our own custom pkey_eq() implementation. Fixes bug 9043.
    • Use a doubly-linked list to implement the global circuit list. Resolves ticket 9108. Patch from Marek Majkowski.
    • Remove contrib/id_to_fp.c since it wasn't used anywhere.
    • Remove constants and tests for PKCS1 padding; it's insecure and shouldn't be used for anything new. Fixes bug 8792; patch from Arlo Breault.
    • Remove instances of strcpy() from the unit tests. They weren't hurting anything, since they were only in the unit tests, but it's embarassing to have strcpy() in the code at all, and some analysis tools don't like it. Fixes bug 8790; bugfix on 0.2.3.6-alpha and 0.2.3.8-alpha. Patch from Arlo Breault.
    • Remove is_internal_IP() function. Resolves ticket 4645.
    • Remove unused function circuit_dump_by_chan from circuitlist.c. Closes issue 9107; patch from "marek".
    • Change our use of the ENUM_BF macro to avoid declarations that confuse Doxygen.
    • Get rid of router->address, since in all cases it was just the string representation of router->addr. Resolves ticket 5528.
  • Documentation:
    • Adjust the URLs in the README to refer to the new locations of several documents on the website. Fixes bug 12830. Patch from Matt Pagan.
    • Document 'reject6' and 'accept6' ExitPolicy entries. Resolves ticket 12878.
    • Update manpage to describe some of the files you can expect to find in Tor's DataDirectory. Addresses ticket 9839.
    • Clean up several option names in the manpage to match their real names, add the missing documentation for a couple of testing and directory authority options, remove the documentation for a V2-directory fetching option that no longer exists. Resolves ticket 11634.
    • Correct the documenation so that it lists the correct directory for the stats files. (They are in a subdirectory called "stats", not "status".)
    • In the manpage, move more authority-only options into the directory authority section so that operators of regular directory caches don't get confused.
    • Fix the layout of the SOCKSPort flags in the manpage. Fixes bug 11061; bugfix on 0.2.4.7-alpha.
    • Resolve warnings from Doxygen.
    • Document in the manpage that "KBytes" may also be written as "kilobytes" or "KB", that "Kbits" may also be written as "kilobits", and so forth. Closes ticket 9222.
    • Document that the ClientOnly config option overrides ORPort. Our old explanation made ClientOnly sound as though it did nothing at all. Resolves bug 9059.
    • Explain that SocksPolicy, DirPolicy, and similar options don't take port arguments. Fixes the other part of ticket 11108.
    • Fix a comment about the rend_server_descriptor_t.protocols field to more accurately describe its range. Also, make that field unsigned, to more accurately reflect its usage. Fixes bug 9099; bugfix on 0.2.1.5-alpha.
    • Fix the manpage's description of HiddenServiceAuthorizeClient: the maximum client name length is 16, not 19. Fixes bug 11118; bugfix on 0.2.1.6-alpha.
  • Package cleanup:
    • The contrib directory has been sorted and tidied. Before, it was an unsorted dumping ground for useful and not-so-useful things. Now, it is divided based on functionality, and the items which seemed to be nonfunctional or useless have been removed. Resolves ticket 8966; based on patches from "rl1987".
  • Removed code and features:
    • Clients now reject any directory authority certificates lacking a dir-key-crosscert element. These have been included since 0.2.1.9-alpha, so there's no real reason for them to be optional any longer. Completes proposal 157. Resolves ticket 10162.
    • Remove all code that existed to support the v2 directory system, since there are no longer any v2 directory authorities. Resolves ticket 10758.
    • Remove the HSAuthoritativeDir and AlternateHSAuthority torrc options, which were used for designating authorities as "Hidden service authorities". There has been no use of hidden service authorities since 0.2.2.1-alpha, when we stopped uploading or downloading v0 hidden service descriptors. Fixes bug 10881; also part of a fix for bug 10841.
    • Remove /tor/dbg-stability.txt URL that was meant to help debug WFU and MTBF calculations, but that nobody was using. Fixes bug 11742.
    • The TunnelDirConns and PreferTunnelledDirConns options no longer exist; tunneled directory connections have been available since 0.1.2.5-alpha, and turning them off is not a good idea. This is a brute-force fix for 10849, where "TunnelDirConns 0" would break hidden services.
    • Remove all code for the long unused v1 directory protocol. Resolves ticket 11070.
    • Remove all remaining code related to version-0 hidden service descriptors: they have not been in use since 0.2.2.1-alpha. Fixes the rest of bug 10841.
    • Remove migration code from when we renamed the "cached-routers" file to "cached-descriptors" back in 0.2.0.8-alpha. This incidentally resolves ticket 6502 by cleaning up the related code a bit. Patch from Akshay Hebbar.
  • Test infrastructure:
    • Tor now builds each source file in two modes: a mode that avoids exposing identifiers needlessly, and another mode that exposes more identifiers for testing. This lets the compiler do better at optimizing the production code, while enabling us to take more radical measures to let the unit tests test things.
    • The production builds no longer include functions used only in the unit tests; all functions exposed from a module only for unit-testing are now static in production builds.
    • Add an --enable-coverage configuration option to make the unit tests (and a new src/or/tor-cov target) to build with gcov test coverage support.
    • Update to the latest version of tinytest.
    • Improve the tinytest implementation of string operation tests so that comparisons with NULL strings no longer crash the tests; they now just fail, normally. Fixes bug 9004; bugfix on 0.2.2.4-alpha.
    • New macros in test.h to simplify writing mock-functions for unit tests. Part of ticket 11507. Patch from Dana Koch.
    • We now have rudimentary function mocking support that our unit tests can use to test functions in isolation. Function mocking lets the tests temporarily replace a function's dependencies with stub functions, so that the tests can check the function without invoking the other functions it calls.
  • Testing:
    • Complete tests for the status.c module. Resolves ticket 11507. Patch from Dana Koch.
    • Add more unit tests for the <circid,channel>->circuit map, and the destroy-cell-tracking code to fix bug 7912.
    • Unit tests for failing cases of the TAP onion handshake.
    • More unit tests for address-manipulation functions.
  • Distribution (systemd):
    • Include a tor.service file in contrib/dist for use with systemd. Some distributions will be able to use this file unmodified; others will need to tweak it, or write their own. Patch from Jamie Nguyen; resolves ticket 8368.
    • Verify configuration file via ExecStartPre in the systemd unit file. Patch from intrigeri; resolves ticket 12730.
    • Explicitly disable RunAsDaemon in the systemd unit file. Our current systemd unit uses "Type = simple", so systemd does not expect tor to fork. If the user has "RunAsDaemon 1" in their torrc, then things won't work as expected. This is e.g. the case on Debian (and derivatives), since there we pass "--defaults-torrc /usr/share/tor/tor-service-defaults-torrc" (that contains "RunAsDaemon 1") by default. Patch by intrigeri; resolves ticket 12731.

Oct 23, 2014

We are happy to announce the fourth beta release of TorBirdy: 0.1.3. All users are encouraged to upgrade as soon as possible, especially if you are using Thunderbird 31.

Notable changes in this release include:

0.1.3, 23 Oct 2014

* The default keyserver (hidden service) has been updated:
- hkp://qdigse2yzvuglcix.onion
* Show the Sender header in message pane (closes #10226)
* Draft messages on IMAP accounts are now saved locally (closes #10309)
* Restore preferences to the user's own defaults instead of Thunderbird's
(closes #10588)
* network.proxy.no_proxies_on is no longer set to "localhost, 127.0.0.1"
(thanks to Carsten N.)
* Disable automatic downloading of new messages for POP3 accounts
(closes #11188)
* Update the reply_header author behaviour (closes #13480)
* TorBirdy is now available in 31 languages:
- Arabic
- Catalan
- Czech
- Danish
- German
- Greek
- English (US)
- English (Great Britain)
- Spanish
- Basque
- French
- Hebrew
- Hungarian
- Indonesian
- Italian
- Korean
- Latvian
- Norwegian Bokmål
- Norwegian Nynorsk
- Punjabi
- Polish
- Portuguese
- Portuguese (Brazil)
- Romanian
- Russian
- Slovak
- Slovenian
- Serbian
- Swedish
- Turkish
- Ukrainian

We offer two ways of installing TorBirdy -- either by visiting our website (sig) or by visiting the Mozilla Add-ons page for TorBirdy. Please note that there may be a delay -- which can range from a few hours to days -- before the extension is reviewed by Mozilla and updated on the Add-ons page.

As a general anonymity and security note: we are still working on two known anonymity issues with Mozilla. Please make sure that you read the Before Using TorBirdy and Known TorBirdy Issues sections on the wiki before using TorBirdy.

We had love help with getting our patches accepted, or anything that you think will help improve TorBirdy!

Feel free to follow along with the release on the tor-talk mailing list.

Oct 22, 2014

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

Tor 0.2.5.9-rc is out

Nick Mathewson announced what is hopefully the final release candidate in the Tor 0.2.5 series. It contains two enhancements in response to the recent POODLE attack on OpenSSL, “even though POODLE does not affect Tor”, as well as a number of other miscellaneous improvements.

Upgrading is especially important for relay operators, as a remote crash is possible when older Tor versions are used with a version of OpenSSL released last week that was built with the “no-ssl3” flag.

As ever, you can download the source code from the distribution directory and packages should follow shortly.

Tor Browser 4.0 is out

Mike Perry announced a major release by the Tor Browser team. Version 4.0 of the secure and anonymous web browser brings several exciting new features to the stable series, including the meek censorship-circumvention tool, the secure updater, and a simplified Javascript enabling/disabling process in NoScript, all based on a customized Firefox ESR31. SSLv3 is also disabled, in response to the recent POODLE attack.

This release contains important security fixes, and all users should upgrade as soon as possible. Please note that the new directory structure means users cannot simply extract the new Tor Browser over their existing 3.6.6 directory, and must instead delete the old version entirely. The secure updater still requires manual activation in the “About Tor Browser” menu option, as its security will depend “on the specific CA that issued the www.torproject.org HTTPS certificate (Digicert)” until site-specific certificate pinning and signed update files are implemented. Furthermore, “we still need to improve meek’s performance to match other transports”, wrote Mike, “so adjust your expectations accordingly”.

See Mike’s post for further details and a full changelog, and get your copy of Tor Browser 4.0 from the distribution directory or the download page.

Tails 1.2 is out

The Tails team put out version 1.2 of the anonymizing live operating system. This release replaces the Iceweasel browser with “most of” the regular Tor Browser, and confines several important applications with AppArmor.

I2P will now, like Tor, be started upon network connection if activated with the “i2p” boot parameter, and must be used with the new dedicated I2P Browser. This is also the last Tails release to ship with the now-unmaintained TrueCrypt tool, but the Tails team has already documented the method for opening TrueCrypt volumes with cryptsetup. See the team’s announcement for a full list of changes in the new version.

This is an important security release and all users should upgrade as soon as possible. If you have a running Tails, you should be able to use the incremental updater; if your Tails drive was manually created, or you are a new user, head to the download page for more information.

Miscellaneous news

tagnaq warned users of TorBirdy, the torifying extension for the Thunderbird mail client, that a change in Thunderbird 31’s handling of the “reply_header_authorwrote” header means that the word “wrote”, translated into the user’s system language, may be inserted before quoted text when replying to emails, leaking the system language to recipients of replies if not removed. Jacob Appelbaum responded that a new release of TorBirdy addressing this and other issues was imminent.

Arturo Filastò announced the release of ooniprobe 1.1.2, containing “two new report entry keys, test_start_time and test_runtime”, and a fix for a bug that “led to ooniresources not working properly”.

evilaliv3 announced version 3.1.20 of tor2web, an HTTP proxy that enables access to hidden services without a Tor client, for users who do not require strong anonymity. As well as “some networking bugfixing and optimizations”, this release adds a “replace” mode for remotely-fetched blocklists in addition to “merge”, and a feature that allows different hostnames to be mapped to specific hidden services.

Karsten Loesing gave users of Onionoo a “one-month heads-up” that on or after November 15th, a change to the protocol will let the search parameter “accept base64-encoded fingerprints in addition to hex-encoded fingerprints, nicknames, and IP addresses.” These searches will also return relays whose base64-encoded fingerprints are a partial match for the search string. “If you’re fine with that, feel free to ignore this message and do nothing”, but if not, “you’ll have to filter out those relays locally”.

Following updates to the Tor Project’s website, Sebastian Hahn drew attention to a change in the steps necessary to run a website mirror. “Please ask if you run into any trouble, and thanks for providing a mirror!”

Inspired by “the Directory Authorities, the crappy experiment leading up to Black Hat, and the promise that one can recreate the Tor network in the event of some catastrophe”, Tom Ritter sent out a detailed report of issues he encountered while setting up his own Tor network using “full-featured independent tor daemons”, rather than a network simulator like Shadow or Chutney.

Cthulhu asked for assistance in overhauling the GoodBadISP page, which is the starting point for many relay operators around the world. If you have some time to spare, or know some ISPs not yet on the list, it would be greatly appreciated if they could be added to the page. This new effort to reach out to hosting providers could be of great value after years of what Roger Dingledine has described as a “slash and burn” agriculture model of operating Tor nodes.

Vladimir Martyanov started a discussion on the question of whether Tor developers should ensure that tor can still be built using compilers that do not support the C99 programming language standard, such as older versions of Microsoft Visual Studio.


This issue of Tor Weekly News has been assembled by Lunar, Cthulhu, Roger Dingledine, Karsten Loesing, and 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!

Oct 21, 2014

Tor misused by criminals

Several people contacted The Tor Project recently because some software told them to install the Tor Browser to access a website. There is no affiliation between the criminals who wrote this software and Tor.

What happened here?

The computer is probably infected with what's called ransomware. This is a kind of malicious software which restricts access to the files and demands a ransom. In this case the authors of the ransomware CryptoLocker set up a website which is only reachable by using Tor. That is why people are thinking that the software is somehow related to The Tor Project.

In fact, CryptoLocker is unrelated to The Tor Project. We didn't produce it, and we didn't ask to be included in the criminal infection of any computer. We cannot help you with your infection. However, according to the BBC you may be able to decrypt your files for free. If not, Bleeping Computer can provide more information.

We, the people of Tor, are very sorry to hear that some individual misused the anonymity granted by our service. The vast majority of our users use Tor in a responsible way. Thank you for your understanding.

Oct 21, 2014

This is a copy of the message Nick Mathewson sent to the tor-talk & tor-relays mailing lists.

Hello, relay operators!

There's one important bugfix in the 0.2.5.9-rc release that relay operators should know about. If you have a version of OpenSSL that came out last week (like 1.0.1j, 1.0.0, ) and if your version of OpenSSL is built with the "no-ssl3" flag, then it's possible to crash your Tor relay remotely if you don't upgrade to 0.2.5.9-rc or to 0.2.4.25 (when that's out).

This appears to be an OpenSSL bug. The Tor releases in question contain a workaround for it.

To tell if your version of OpenSSL was built with 'no-ssl3': run:

openssl s_client -ssl3 -connect www.torproject.org:443

If it gives you output beginning with something like:

CONNECTED(00000003)
140632971298688:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3
alert handshake failure:s3_pkt.c:1257:SSL alert number 40
140632971298688:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl
handshake failure:s3_pkt.c:596:

then you're fine and you don't need to upgrade Tor on your relay. But if it says something that starts with:

unknown option -ssl3
usage: s_client args

then you need to upgrade Tor.

Some questions and answers:

Q: Does this affect clients?
A: No. Only relays.

Q: Does this affect me if I'm running a version of OpenSSL other than 1.0.1j, 1.0.0o, or 0.9.8zc?
A: No. Only those versions.

Q: Does this affect me if I'm running a version of OpenSSL configured without the "no-ssl3" option?
A: No. Only versions that were built with the "no-ssl3" option are affected.

Q: Does the OpenSSL team know?
A: Yes. Have a look at this thread. Also, before I saw that thread, I informed them the other day.

Q: Does this affect Tor packages?
A: I don't think that we shipped any packages where we used the "no-ssl3" flag to diable ssl3. So only if you're using OpenSSL from another source (say, your operating system) will you be affected.

Q: What can I do to remediate this problem?
A: You can upgrade to the most recent Tor, or you can use a version of OpenSSL built without the "no-ssl3" flag. Downgrading your OpenSSL is not recommended.

Q: What is the potential impact of this bug?
A: If a relay is affected by this bug, anybody can make the relay crash remotely. It does not enable any data leaks or remote code execution. Still, the ability to selectively disable relays might enable a sophisticated attacker to do some kinds of traffic analysis more efficiently. So, fix your relay if it's affected.

Q: Should we run in circles and freak out?
A: Not this time. We should just make sure we fix affected relays.

Q: Hey, Nick, you didn't explain this properly!
A: Please send a follow-up message that explains it better. :)