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: 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 24, 2015

The first thing that Laura Poitras has to say about Tor is that she couldn’t have made Citizenfour without it.

“There’s no way I would have been able to protect the initial source without using Tor,” she says. “Fundamentally, without Tor and other free software tools I wouldn’t have been able to do the reporting, and the story would not have been broken.”

Laura also recalls her own learning process around encryption that allowed her to communicate easily with Snowden when he first contacted her. “I’ve been on a government watch list since 2006,” she says. “In 2010, I was interested in reaching out to Jake Appelbaum around the work he was doing with Tor. I got up to speed on encryption just to contact him, and he taught me far more. Then Snowden came along and taught me even more. So I’ve had good teachers.”

She references her first exchange with Snowden that dramatically shifted her methods of communication.

“He contacted me through Micah Lee initially,” she recalls. “And of course Micah sent the encrypted email to me. The problem was that my key was still attached to my actual identity at the time and Ed quickly encouraged me to change that. By my third email from him, I was communicating on Tails with a computer that I bought with cash, checking it only from public places. I was using the Tor Browser for all of my research, and to verify the information I was hearing. It was essential in moving the whole story forward.”

Laura is heartened by feedback she has received that Citizenfour, by so compellingly telling Snowden’s story, has helped make mass surveillance a topic for public debate.

“Before Snowden, as a journalist, I knew that I had to be careful, but didn’t quite know how to protect myself,” she remembers. “I knew I needed anonymity, but didn’t know what tools to use.”

And she encourages everyone to use, and to support Tor.

“There are so many reasons…that we want to protect our privacy and not broadcast every move we make online. Tor is an essential tool that is needed by people to do what they do. It fosters free speech and independent voices.”

Donate to Tor Today!

Nov 23, 2015

The Tor 0.2.7 release series is dedicated to the memory of Tor user and privacy advocate Caspar Bowden (1961-2015). Caspar worked tirelessly to advocate human rights regardless of national borders, and oppose the encroachments of mass surveillance. He opposed national exceptionalism, he brought clarity to legal and policy debates, he understood and predicted the impact of mass surveillance on the world, and he laid the groundwork for resisting it. While serving on the Tor Project's board of directors, he brought us his uncompromising focus on technical excellence in the service of humankind. Caspar was an inimitable force for good and a wonderful friend. He was kind, humorous, generous, gallant, and believed we should protect one another without exception. We honor him here for his ideals, his efforts, and his accomplishments. Please honor his memory with works that would make him proud.

Tor is the first stable release in the Tor 0.2.7 series. It makes no changes beyond those in; the summary below lists all changes in the 0.2.7 series.

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

The 0.2.7 series adds a more secure identity key type for relays, improves cryptography performance, resolves several longstanding hidden-service performance issues, improves controller support for hidden services, and includes small bugfixes and performance improvements throughout the program. This release series also includes more tests than before, and significant simplifications to which parts of Tor invoke which others. For a full list of changes, see below.

Changes in version - 2015-11-20
  • New system requirements:
    • Tor no longer includes workarounds to support Libevent versions before 1.3e. Libevent 2.0 or later is recommended. Closes ticket 15248.
    • Tor no longer supports copies of OpenSSL that are missing support for Elliptic Curve Cryptography. (We began using ECC when available in, for more safe and efficient key negotiation.) In particular, support for at least one of P256 or P224 is now required, with manual configuration needed if only P224 is available. Resolves ticket 16140.
    • Tor no longer supports versions of OpenSSL before 1.0. (If you are on an operating system that has not upgraded to OpenSSL 1.0 or later, and you compile Tor from source, you will need to install a more recent OpenSSL to link Tor against.) These versions of OpenSSL are still supported by the OpenSSL, but the numerous cryptographic improvements in later OpenSSL releases makes them a clear choice. Resolves ticket 16034.
  • Major features (controller):
    • Add the ADD_ONION and DEL_ONION commands that allow the creation and management of hidden services via the controller. Closes ticket 6411.
    • New "GETINFO onions/current" and "GETINFO onions/detached" commands to get information about hidden services created via the controller. Part of ticket 6411.
    • New HSFETCH command to launch a request for a hidden service descriptor. Closes ticket 14847.
    • New HSPOST command to upload a hidden service descriptor. Closes ticket 3523. Patch by "DonnchaC".


  • Major features (Ed25519 identity keys, Proposal 220):
    • Add support for offline encrypted Ed25519 master keys. To use this feature on your tor relay, run "tor --keygen" to make a new master key (or to make a new signing key if you already have a master key). Closes ticket 13642.
    • All relays now maintain a stronger identity key, using the Ed25519 elliptic curve signature format. This master key is designed so that it can be kept offline. Relays also generate an online signing key, and a set of other Ed25519 keys and certificates. These are all automatically regenerated and rotated as needed. Implements part of ticket 12498.
    • Directory authorities now vote on Ed25519 identity keys along with RSA1024 keys. Implements part of ticket 12498.
    • Directory authorities track which Ed25519 identity keys have been used with which RSA1024 identity keys, and do not allow them to vary freely. Implements part of ticket 12498.
    • Microdescriptors now include Ed25519 identity keys. Implements part of ticket 12498.
    • Add a --newpass option to allow changing or removing the passphrase of an encrypted key with tor --keygen. Implements part of ticket 16769.
    • Add a new OfflineMasterKey option to tell Tor never to try loading or generating a secret Ed25519 identity key. You can use this in combination with tor --keygen to manage offline and/or encrypted Ed25519 keys. Implements ticket 16944.
    • On receiving a HUP signal, check to see whether the Ed25519 signing key has changed, and reload it if so. Closes ticket 16790.
    • Significant usability improvements for Ed25519 key management. Log messages are better, and the code can recover from far more failure conditions. Thanks to "s7r" for reporting and diagnosing so many of these!
  • Major features (ECC performance):
    • Improve the runtime speed of Ed25519 signature verification by using Ed25519-donna's batch verification support. Implements ticket 16533.
    • Improve the speed of Ed25519 operations and Curve25519 keypair generation when built targeting 32 bit x86 platforms with SSE2 available. Implements ticket 16535.
    • Improve the runtime speed of Ed25519 operations by using the public-domain Ed25519-donna by Andrew M. ("floodyberry"). Implements ticket 16467.
    • Improve the runtime speed of the ntor handshake by using an optimized curve25519 basepoint scalarmult implementation from the public-domain Ed25519-donna by Andrew M. ("floodyberry"), based on ideas by Adam Langley. Implements ticket 9663.
  • Major features (Hidden services):
    • Hidden services, if using the EntryNodes option, are required to use more than one EntryNode, in order to avoid a guard discovery attack. (This would only affect people who had configured hidden services and manually specified the EntryNodes option with a single entry-node. The impact was that it would be easy to remotely identify the guard node used by such a hidden service. See ticket for more information.) Fixes ticket 14917.
    • Add the torrc option HiddenServiceNumIntroductionPoints, to specify a fixed number of introduction points. Its maximum value is 10 and default is 3. Using this option can increase a hidden service's reliability under load, at the cost of making it more visible that the hidden service is facing extra load. Closes ticket 4862.
    • Remove the adaptive algorithm for choosing the number of introduction points, which used to change the number of introduction points (poorly) depending on the number of connections the HS sees. Closes ticket 4862.
  • Major features (onion key cross-certification):
    • Relay descriptors now include signatures of their own identity keys, made using the TAP and ntor onion keys. These signatures allow relays to prove ownership of their own onion keys. Because of this change, microdescriptors will no longer need to include RSA identity keys. Implements proposal 228; closes ticket 12499.
  • Major bugfixes (client-side privacy, also in
    • Properly separate out each SOCKSPort when applying stream isolation. The error occurred because each port's session group was being overwritten by a default value when the listener connection was initialized. Fixes bug 16247; bugfix on Patch by "jojelino".
  • Major bugfixes (hidden service clients, stability, also in
    • Stop refusing to store updated hidden service descriptors on a client. This reverts commit 9407040c59218 (which indeed fixed bug 14219, but introduced a major hidden service reachability regression detailed in bug 16381). This is a temporary fix since we can live with the minor issue in bug 14219 (it just results in some load on the network) but the regression of 16381 is too much of a setback. First-round fix for bug 16381; bugfix on
  • Major bugfixes (hidden services):
    • Revert commit that made directory authorities assign the HSDir flag to relay without a DirPort; this was bad because such relays can't handle BEGIN_DIR cells. Fixes bug 15850; bugfix on tor-
    • When cannibalizing a circuit for an introduction point, always extend to the chosen exit node (creating a 4 hop circuit). Previously Tor would use the current circuit exit node, which changed the original choice of introduction point, and could cause the hidden service to skip excluded introduction points or reconnect to a skipped introduction point. Fixes bug 16260; bugfix on
  • Major bugfixes (memory leaks):
    • Fix a memory leak in ed25519 batch signature checking. Fixes bug 17398; bugfix on
  • Major bugfixes (open file limit):
    • The open file limit wasn't checked before calling tor_accept_socket_nonblocking(), which would make Tor exceed the limit. Now, before opening a new socket, Tor validates the open file limit just before, and if the max has been reached, return an error. Fixes bug 16288; bugfix on
  • Major bugfixes (security, correctness):
    • Fix an error that could cause us to read 4 bytes before the beginning of an openssl string. This bug could be used to cause Tor to crash on systems with unusual malloc implementations, or systems with unusual hardening installed. Fixes bug 17404; bugfix on
  • Major bugfixes (stability, also in
    • Stop crashing with an assertion failure when parsing certain kinds of malformed or truncated microdescriptors. Fixes bug 16400; bugfix on Found by "torkeln"; fix based on a patch by "cypherpunks_backup".
    • Stop random client-side assertion failures that could occur when connecting to a busy hidden service, or connecting to a hidden service while a NEWNYM is in progress. Fixes bug 16013; bugfix on
  • Minor features (client, SOCKS):
    • Add GroupWritable and WorldWritable options to unix-socket based SocksPort and ControlPort options. These options apply to a single socket, and override {Control,Socks}SocketsGroupWritable. Closes ticket 15220.
    • Relax the validation done to hostnames in SOCKS5 requests, and allow a single trailing '.' to cope with clients that pass FQDNs using that syntax to explicitly indicate that the domain name is fully-qualified. Fixes bug 16674; bugfix on
    • Relax the validation of hostnames in SOCKS5 requests, allowing the character '_' to appear, in order to cope with domains observed in the wild that are serving non-RFC compliant records. Resolves ticket 16430.
  • Minor features (client-side privacy):
    • New KeepAliveIsolateSOCKSAuth option to indefinitely extend circuit lifespan when IsolateSOCKSAuth and streams with SOCKS authentication are attached to the circuit. This allows applications like TorBrowser to manage circuit lifetime on their own. Implements feature 15482.
    • When logging malformed hostnames from SOCKS5 requests, respect SafeLogging configuration. Fixes bug 16891; bugfix on
  • Minor features (clock-jump tolerance):
    • Recover better when our clock jumps back many hours, like might happen for Tails or Whonix users who start with a very wrong hardware clock, use Tor to discover a more accurate time, and then fix their clock. Resolves part of ticket 8766.
  • Minor features (command-line interface):
    • Make --hash-password imply --hush to prevent unnecessary noise. Closes ticket 15542. Patch from "cypherpunks".
    • Print a warning whenever we find a relative file path being used as torrc option. Resolves issue 14018.
  • Minor features (compilation):
    • Give a warning as early as possible when trying to build with an unsupported OpenSSL version. Closes ticket 16901.
    • Use C99 variadic macros when the compiler is not GCC. This avoids failing compilations on MSVC, and fixes a log-file-based race condition in our old workarounds. Original patch from Gisle Vanem.
  • Minor features (control protocol):
    • Support network-liveness GETINFO key and NETWORK_LIVENESS event in the control protocol. Resolves ticket 15358.
  • Minor features (controller):
    • Add DirAuthority lines for default directory authorities to the output of the "GETINFO config/defaults" command if not already present. Implements ticket 14840.
    • Controllers can now use "GETINFO hs/client/desc/id/..." to retrieve items from the client's hidden service descriptor cache. Closes ticket 14845.
    • Implement a new controller command "GETINFO status/fresh-relay- descs" to fetch a descriptor/extrainfo pair that was generated on demand just for the controller's use. Implements ticket 14784.
  • Minor features (directory authorities):
    • Directory authorities no longer vote against the "Fast", "Stable", and "HSDir" flags just because they were going to vote against "Running": if the consensus turns out to be that the router was running, then the authority's vote should count. Patch from Peter Retzlaff; closes issue 8712.
  • Minor features (directory authorities, security, also in
    • The HSDir flag given by authorities now requires the Stable flag. For the current network, this results in going from 2887 to 2806 HSDirs. Also, it makes it harder for an attacker to launch a sybil attack by raising the effort for a relay to become Stable to require at the very least 7 days, while maintaining the 96 hours uptime requirement for HSDir. Implements ticket 8243.
  • Minor features (DoS-resistance):
    • Make it harder for attackers to overload hidden services with introductions, by blocking multiple introduction requests on the same circuit. Resolves ticket 15515.
  • Minor features (geoip):
    • Update geoip and geoip6 to the October 9 2015 Maxmind GeoLite2 Country database.
  • Minor features (hidden services):
    • Add the new options "HiddenServiceMaxStreams" and "HiddenServiceMaxStreamsCloseCircuit" to allow hidden services to limit the maximum number of simultaneous streams per circuit, and optionally tear down the circuit when the limit is exceeded. Part of ticket 16052.
    • Client now uses an introduction point failure cache to know when to fetch or keep a descriptor in their cache. Previously, failures were recorded implicitly, but not explicitly remembered. Closes ticket 16389.
    • Relays need to have the Fast flag to get the HSDir flag. As this is being written, we'll go from 2745 HSDirs down to 2342, a ~14% drop. This change should make some attacks against the hidden service directory system harder. Fixes ticket 15963.
    • Turn on hidden service statistics collection by setting the torrc option HiddenServiceStatistics to "1" by default. (This keeps track only of the fraction of traffic used by hidden services, and the total number of hidden services in existence.) Closes ticket 15254.
    • To avoid leaking HS popularity, don't cycle the introduction point when we've handled a fixed number of INTRODUCE2 cells but instead cycle it when a random number of introductions is reached, thus making it more difficult for an attacker to find out the amount of clients that have used the introduction point for a specific HS. Closes ticket 15745.
  • Minor features (logging):
    • Include the Tor version in all LD_BUG log messages, since people tend to cut and paste those into the bugtracker. Implements ticket 15026.
  • Minor features (pluggable transports):
    • When launching managed pluggable transports on Linux systems, attempt to have the kernel deliver a SIGTERM on tor exit if the pluggable transport process is still running. Resolves ticket 15471.
    • When launching managed pluggable transports, setup a valid open stdin in the child process that can be used to detect if tor has terminated. The "TOR_PT_EXIT_ON_STDIN_CLOSE" environment variable can be used by implementations to detect this new behavior. Resolves ticket 15435.
  • Minor bugfixes (torrc exit policies):
    • In each instance above, usage advice is provided to avoid the message. Resolves ticket 16069. Patch by "teor". Fixes part of bug 16069; bugfix on
    • In torrc, "accept6 *" and "reject6 *" ExitPolicy lines now only produce IPv6 wildcard addresses. Previously they would produce both IPv4 and IPv6 wildcard addresses. Patch by "teor". Fixes part of bug 16069; bugfix on
    • When parsing torrc ExitPolicies, we now issue an info-level message when expanding an "accept/reject *" line to include both IPv4 and IPv6 wildcard addresses. Related to ticket 16069.
    • When parsing torrc ExitPolicies, we now warn for a number of cases where the user's intent is likely to differ from Tor's actual behavior. These include: using an IPv4 address with an accept6 or reject6 line; using "private" on an accept6 or reject6 line; and including any ExitPolicy lines after accept *:* or reject *:*. Related to ticket 16069.
  • Minor bugfixes (command-line interface):
    • When "--quiet" is provided along with "--validate-config", do not write anything to stdout on success. Fixes bug 14994; bugfix on
    • When complaining about bad arguments to "--dump-config", use stderr, not stdout.
    • Print usage information for --dump-config when it is used without an argument. Also, fix the error message to use different wording and add newline at the end. Fixes bug 15541; bugfix on
  • Minor bugfixes (compilation):
    • Fix compilation of sandbox.c with musl-libc. Fixes bug 17347; bugfix on Patch from 'jamestk'.
    • Repair compilation with the most recent (unreleased, alpha) vesions of OpenSSL 1.1. Fixes part of ticket 17237.
  • Minor bugfixes (compilation, also in
    • Build with --enable-systemd correctly when libsystemd is installed, but systemd is not. Fixes bug 16164; bugfix on Patch from Peter Palfrader.
  • Minor bugfixes (configuration, unit tests):
    • Only add the default fallback directories when the DirAuthorities, AlternateDirAuthority, and FallbackDir directory config options are set to their defaults. The default fallback directory list is currently empty, this fix will only change tor's behavior when it has default fallback directories. Includes unit tests for consider_adding_dir_servers(). Fixes bug 15642; bugfix on 90f6071d8dc0 in Patch by "teor".
  • Minor bugfixes (controller):
    • Add the descriptor ID in each HS_DESC control event. It was missing, but specified in control-spec.txt. Fixes bug 15881; bugfix on
  • Minor bugfixes (correctness):
    • For correctness, avoid modifying a constant string in handle_control_postdescriptor. Fixes bug 15546; bugfix on
    • Remove side-effects from tor_assert() calls. This was harmless, because we never disable assertions, but it is bad style and unnecessary. Fixes bug 15211; bugfix on,, and
    • When calling channel_free_list(), avoid calling smartlist_remove() while inside a FOREACH loop. This partially reverts commit 17356fe7fd96af where the correct SMARTLIST_DEL_CURRENT was incorrectly removed. Fixes bug 16924; bugfix on
  • Minor bugfixes (crypto error-handling, also in
    • Check for failures from crypto_early_init, and refuse to continue. A previous typo meant that we could keep going with an uninitialized crypto library, and would have OpenSSL initialize its own PRNG. Fixes bug 16360; bugfix on, introduced when implementing ticket 4900. Patch by "teor".
  • Minor bugfixes (hidden service):
    • Fix an out-of-bounds read when parsing invalid INTRODUCE2 cells on a client authorized hidden service. Fixes bug 15823; bugfix on
    • Remove an extraneous newline character from the end of hidden service descriptors. Fixes bug 15296; bugfix on
  • Minor bugfixes (Linux seccomp2 sandbox):
    • Use the sandbox in tor_open_cloexec whether or not O_CLOEXEC is defined. Patch by "teor". Fixes bug 16515; bugfix on
    • Allow bridge authorities to run correctly under the seccomp2 sandbox. Fixes bug 16964; bugfix on
    • Add the "hidserv-stats" filename to our sandbox filter for the HiddenServiceStatistics option to work properly. Fixes bug 17354; bugfix on tor- Patch from David Goulet.
  • Minor bugfixes (Linux seccomp2 sandbox, also in
    • Allow pipe() and pipe2() syscalls in the seccomp2 sandbox: we need these when eventfd2() support is missing. Fixes bug 16363; bugfix on Patch from "teor".
  • Minor bugfixes (Linux seccomp2 sandbox, also in
    • Allow systemd connections to work with the Linux seccomp2 sandbox code. Fixes bug 16212; bugfix on Patch by Peter Palfrader.
    • Fix sandboxing to work when running as a relay, by allowing the renaming of secret_id_key, and allowing the eventfd2 and futex syscalls. Fixes bug 16244; bugfix on Patch by Peter Palfrader.
  • Minor bugfixes (logging):
    • When building Tor under Clang, do not include an extra set of parentheses in log messages that include function names. Fixes bug 15269; bugfix on every released version of Tor when compiled with recent enough Clang.
  • Minor bugfixes (network):
    • When attempting to use fallback technique for network interface lookup, disregard loopback and multicast addresses since they are unsuitable for public communications.
  • Minor bugfixes (open file limit):
    • Fix set_max_file_descriptors() to set by default the max open file limit to the current limit when setrlimit() fails. Fixes bug 16274; bugfix on tor- Patch by dgoulet.
  • Minor bugfixes (portability):
    • Check correctly for Windows socket errors in the workqueue backend. Fixes bug 16741; bugfix on
    • Try harder to normalize the exit status of the Tor process to the standard-provided range. Fixes bug 16975; bugfix on every version of Tor ever.
    • Use libexecinfo on FreeBSD to enable backtrace support. Fixes part of bug 17151; bugfix on Patch from Marcin Cieślak.
  • Minor bugfixes (relay):
    • Ensure that worker threads actually exit when a fatal error or shutdown is indicated. This fix doesn't currently affect the behavior of Tor, because Tor workers never indicates fatal error or shutdown except in the unit tests. Fixes bug 16868; bugfix on
    • Fix a rarely-encountered memory leak when failing to initialize the thread pool. Fixes bug 16631; bugfix on Patch from "cypherpunks".
    • Unblock threads before releasing the work queue mutex to ensure predictable scheduling behavior. Fixes bug 16644; bugfix on
  • Minor bugfixes (security, exit policies):
    • ExitPolicyRejectPrivate now also rejects the relay's published IPv6 address (if any), and any publicly routable IPv4 or IPv6 addresses on any local interfaces. ticket 17027. Patch by "teor". Fixes bug 17027; bugfix on
  • Minor bugfixes (statistics):
    • Disregard the ConnDirectionStatistics torrc options when Tor is not a relay since in that mode of operation no sensible data is being collected and because Tor might run into measurement hiccups when running as a client for some time, then becoming a relay. Fixes bug 15604; bugfix on
  • Minor bugfixes (systemd):
    • Tor's systemd unit file no longer contains extraneous spaces. These spaces would sometimes confuse tools like deb-systemd- helper. Fixes bug 16162; bugfix on
  • Minor bugfixes (test networks):
    • When self-testing reachability, use ExtendAllowPrivateAddresses to determine if local/private addresses imply reachability. The previous fix used TestingTorNetwork, which implies ExtendAllowPrivateAddresses, but this excluded rare configurations where ExtendAllowPrivateAddresses is set but TestingTorNetwork is not. Fixes bug 15771; bugfix on Patch by "teor", issue discovered by CJ Ess.
  • Minor bugfixes (tests, also in
    • Fix a crash in the unit tests when built with MSVC2013. Fixes bug 16030; bugfix on Patch from "NewEraCracker".
  • Code simplification and refactoring:
    • Change the function that's called when we need to retry all downloads so that it only reschedules the downloads to happen immediately, rather than launching them all at once itself. This further simplifies Tor's callgraph.
    • Define WINVER and _WIN32_WINNT centrally, in orconfig.h, in order to ensure they remain consistent and visible everywhere.
    • Move some format-parsing functions out of crypto.c and crypto_curve25519.c into crypto_format.c and/or util_format.c.
    • Move the client-only parts of init_keys() into a separate function. Closes ticket 16763.
    • Move the hacky fallback code out of get_interface_address6() into separate function and get it covered with unit-tests. Resolves ticket 14710.
    • Refactor hidden service client-side cache lookup to intelligently report its various failure cases, and disentangle failure cases involving a lack of introduction points. Closes ticket 14391.
    • Remove some vestigial workarounds for the MSVC6 compiler. We haven't supported that in ages.
    • Remove the unused "nulterminate" argument from buf_pullup().
    • Simplify the microdesc_free() implementation so that it no longer appears (to code analysis tools) to potentially invoke a huge suite of other microdesc functions.
    • Simply the control graph further by deferring the inner body of directory_all_unreachable() into a callback. Closes ticket 16762.
    • The link authentication code has been refactored for better testability and reliability. It now uses code generated with the "trunnel" binary encoding generator, to reduce the risk of bugs due to programmer error. Done as part of ticket 12498.
    • Treat the loss of an owning controller as equivalent to a SIGTERM signal. This removes a tiny amount of duplicated code, and simplifies our callgraph. Closes ticket 16788.
    • Use our own Base64 encoder instead of OpenSSL's, to allow more control over the output. Part of ticket 15652.
    • When generating an event to send to the controller, we no longer put the event over the network immediately. Instead, we queue these events, and use a Libevent callback to deliver them. This change simplifies Tor's callgraph by reducing the number of functions from which all other Tor functions are reachable. Closes ticket 16695.
    • Wrap Windows-only C files inside '#ifdef _WIN32' so that tools that try to scan or compile every file on Unix won't decide that they are broken.
  • Documentation:
    • Fix capitalization of SOCKS in sample torrc. Closes ticket 15609.
    • Improve the descriptions of statistics-related torrc options in the manpage to describe rationale and possible uses cases. Fixes issue 15550.
    • Improve the layout and formatting of ./configure --help messages. Closes ticket 15024. Patch from "cypherpunks".
    • Include a specific and (hopefully) accurate documentation of the torrc file's meta-format in doc/torrc_format.txt. This is mainly of interest to people writing programs to parse or generate torrc files. This document is not a commitment to long-term compatibility; some aspects of the current format are a bit ridiculous. Closes ticket 2325.
    • Include the TUNING document in our source tarball. It is referred to in the ChangeLog and an error message. Fixes bug 16929; bugfix on
    • Note that HiddenServicePorts can take a unix domain socket. Closes ticket 17364.
    • Recommend a 40 GB example AccountingMax in torrc.sample rather than a 4 GB max. Closes ticket 16742.
    • Standardize on the term "server descriptor" in the manual page. Previously, we had used "router descriptor", "server descriptor", and "relay descriptor" interchangeably. Part of ticket 14987.
    • Advise users on how to configure separate IPv4 and IPv6 exit policies in the manpage and sample torrcs. Related to ticket 16069.
    • Fix an error in the manual page and comments for TestingDirAuthVoteHSDir[IsStrict], which suggested that a HSDir required "ORPort connectivity". While this is true, it is in no way unique to the HSDir flag. Of all the flags, only HSDirs need a DirPort configured in order for the authorities to assign that particular flag. Patch by "teor". Fixed as part of 14882; bugfix on
    • Fix the usage message of tor-resolve(1) so that it no longer lists the removed -F option. Fixes bug 16913; bugfix on
  • Removed code:
    • Remove `USE_OPENSSL_BASE64` and the corresponding fallback code and always use the internal Base64 decoder. The internal decoder has been part of tor since tor-, and no one should be using the OpenSSL one. Part of ticket 15652.
    • Remove the 'tor_strclear()' function; use memwipe() instead. Closes ticket 14922.
    • Remove the code that would try to aggressively flush controller connections while writing to them. This code was introduced in, in order to keep output buffers from exceeding their limits. But there is no longer a maximum output buffer size, and flushing data in this way caused some undesirable recursions in our call graph. Closes ticket 16480.
    • The internal pure-C tor-fw-helper tool is now removed from the Tor distribution, in favor of the pure-Go clone available from . The libraries used by the C tor-fw-helper are not, in our opinion, very confidence- inspiring in their secure-programming techniques. Closes ticket 13338.
  • Removed features:
    • Remove the (seldom-used) DynamicDHGroups feature. For anti- fingerprinting we now recommend pluggable transports; for forward- secrecy in TLS, we now use the P-256 group. Closes ticket 13736.
    • Remove the HidServDirectoryV2 option. Now all relays offer to store hidden service descriptors. Related to 16543.
    • Remove the VoteOnHidServDirectoriesV2 option, since all authorities have long set it to 1. Closes ticket 16543.
    • Remove the undocumented "--digests" command-line option. It complicated our build process, caused subtle build issues on multiple platforms, and is now redundant since we started including git version identifiers. Closes ticket 14742.
    • Tor no longer contains checks for ancient directory cache versions that didn't know about microdescriptors.
    • Tor no longer contains workarounds for stat files generated by super-old versions of Tor that didn't choose guards sensibly.
  • Testing:
    • The script now supports performance testing. Requires corresponding chutney performance testing changes. Patch by "teor". Closes ticket 14175.
    • Add a new set of callgraph analysis scripts that use clang to produce a list of which Tor functions are reachable from which other Tor functions. We're planning to use these to help simplify our code structure by identifying illogical dependencies.
    • Add new 'test-full' and 'test-full-online' targets to run all tests, including integration tests with stem and chutney.
    • Autodetect CHUTNEY_PATH if the chutney and Tor sources are side- by-side in the same parent directory. Closes ticket 16903. Patch by "teor".
    • Document use of coverity, clang static analyzer, and clang dynamic undefined behavior and address sanitizers in doc/HACKING. Include detailed usage instructions in the blacklist. Patch by "teor". Closes ticket 15817.
    • Make "bridges+hs" the default test network. This tests almost all tor functionality during make test-network, while allowing tests to succeed on non-IPv6 systems. Requires chutney commit 396da92 in test-network-bridges-hs. Closes tickets 16945 (tor) and 16946 (chutney). Patches by "teor".
    • Make the test-workqueue test work on Windows by initializing the network before we begin.
    • New make target (make test-network-all) to run multiple applicable chutney test cases. Patch from Teor; closes 16953.
    • Now that OpenSSL has its own scrypt implementation, add an unit test that checks for interoperability between libscrypt_scrypt() and OpenSSL's EVP_PBE_scrypt() so that we could not use libscrypt and rely on EVP_PBE_scrypt() whenever possible. Resolves ticket 16189.
    • The link authentication protocol code now has extensive tests.
    • The relay descriptor signature testing code now has extensive tests.
    • The test_workqueue program now runs faster, and is enabled by default as a part of "make check".
    • Unit test dns_resolve(), dns_clip_ttl() and dns_get_expiry_ttl() functions in dns.c. Implements a portion of ticket 16831.
    • Use environment variables rather than autoconf substitutions to send variables from the build system to the test scripts. This change should be easier to maintain, and cause 'make distcheck' to work better than before. Fixes bug 17148.
    • When building Tor with testing coverage enabled, run Chutney tests (if any) using the 'tor-cov' coverage binary.
    • When running test-network or test-stem, check for the absence of stem/chutney before doing any build operations.
    • Add a test to verify that the compiler does not eliminate our memwipe() implementation. Closes ticket 15377.
    • Add make rule `check-changes` to verify the format of changes files. Closes ticket 15180.
    • Add unit tests for control_event_is_interesting(). Add a compile- time check that the number of events doesn't exceed the capacity of control_event_t.event_mask. Closes ticket 15431, checks for bugs similar to 13085. Patch by "teor".
    • Command-line argument tests moved to Stem. Resolves ticket 14806.
    • Integrate the ntor, backtrace, and zero-length keys tests into the automake test suite. Closes ticket 15344.
    • Remove assertions during builds to determine Tor's test coverage. We don't want to trigger these even in assertions, so including them artificially makes our branch coverage look worse than it is. This patch provides the new test-stem-full and coverage-html-full configure options. Implements ticket 15400.
    • New TestingDirAuthVote{Exit,Guard,HSDir}IsStrict flags to explicitly manage consensus flags in testing networks. Patch by "robgjansen", modified by "teor". Implements part of ticket 14882.
    • Check for matching value in server response in Fixes bug 15591; bugfix on Reported and fixed by "joelanders".
    • Set the severity correctly when testing get_interface_addresses_ifaddrs() and get_interface_addresses_win32(), so that the tests fail gracefully instead of triggering an assertion. Fixes bug 15759; bugfix on Reported by Nicolas Derive.

Nov 16, 2015

This is an interview with a Tor developer who works on hidden services. Please note that Tor Browser and hidden services are two different things. Tor Browser (downloadable at allows you to browse, or surf, the web, anonymously. A hidden service is a site you visit or a service you use that uses Tor technology to stay secure and, if the owner wishes, anonymous. The secure messaging app ricochet is an example of a hidden service. Tor developers use the terms "hidden services" and "onion services" interchangeably.
1. What are your priorities for onion services development?
Personally I think it’s very important to work on the security of hidden services; that’s a big priority.
The plan for the next generation of onion services includes enhanced security as well as improved performance. We’ve broken the development down into smaller modules and we’re already starting to build the foundation. The whole thing is a pretty insane engineering job.

2. What don't people know about onion Services?
Until earlier this year, hidden services were a labor of love that Tor developers did in their spare time. Now we have a very small group of developers, but in 2016 we want to move the engineering capacity a bit farther out. There is a lot of enthusiasm within Tor for hidden services but we need funding and more high level developers to build the next generation.
3. What are some of Tor's plans for mitigating attacks?
The CMU attack was fundamentally a "guard node" attack; guard nodes are the first hop of a Tor circuit and hence the only part of the network that can see the real IP address of a hidden service. Last July we fixed the attack vector that CMU was using (it was called the RELAY_EARLY confirmation attack) and since then we've been divising improved designs for guard node security.
For example, in the past, each onion service would have three guard nodes assigned to it. Since last September, each onion service only uses one guard node—-it exposes itself to fewer relays. This change alone makes an attack against an onion service much less likely.
Several of our developers are thinking about how to do better guard node selection. One of us is writing code on this right now.
We are modeling how onion services pick guard nodes currently, and we're simulating other ways to do it to see which one exposes itself to fewer relays—the fewer relays you are exposed to, the safer you are.
We’ve also been working on other security things as well. For instance, a series of papers and talks have abused the directory system of hidden services to try to estimate the activity of particular hidden services, or to launch denial-of-service attacks against hidden services.

We’re going to fix this by making it much harder for the attacker's nodes to become the responsible relay of a hidden service (say, catfacts) and be able to track uptime and usage information. We will use a "distributed random number generator"--many computers teaming up to generate a single, fresh unpredictable random number. 

Another important thing we're doing is to make it impossible for a directory service to harvest addresses in the new design. If you don't know a hidden service address, then under the new system, you won't find it out just by hosting its HSDir entry.

There are also interesting performance things: We want to make .onion services scalable in large infrastructures like Facebook--we want high availability and better load balancing; we want to make it serious.

[Load balancing distributes the traffic load of a website to multiple servers so that no one server gets overloaded with all the users. Overloaded servers stop responding and create other problems. An attack that purposely overloads a website to cause it to stop responding is called a Denial of Service (DoS) attack.  - Kate]
There are also onion services that don’t care to stay hidden, like Blockchain or Facebook; we can make those much faster, which is quite exciting.
Meanwhile Nick is working on a new encryption design--magic circuit crypto that will make it harder to do active confirmation attacks. [Nick Mathewson is the co-founder of the Tor Project and the chief architect of our software.] Active confirmation attacks are much more powerful than passive attacks, and we can do a better job at defending against them.
A particular type of confirmation attack that Nick's new crypto is going to solve is a "tagging attack"—Roger wrote a blog post about them years ago called, "One Cell Is Enough"—it was about how they work and how they are powerful.
4. Do you run an onion service yourself?  
Yes, I do run onion services; I run an onion services on every box I have.  I connect to the PC in my house from anywhere in the world through SSH—I connect to my onion service instead of my house IP. People can see my laptop accessing Tor but don’t know who I am or where I go. 
Also, onion services have a property called NAT-punching; (NAT=Network Address Translation). NAT blocks incoming connections;it builds walls around you. Onion services have NAT punching and can penetrate a firewall. In my university campus, the firewall does not allow incoming connections to my SSH server, but with an onion service the firewall is irrelevant.
5. What is your favorite onion service that a nontechnical person might use? 
I use ricochet for my peer to peer chatting--It has a very nice UI and works well.
6. Do you think it’s safe to run an onion service? 
It depends on your adversary. I think onion services provide adequate security against most real life adversaries.

However, if a serious and highly motivated adversary were after me, I would not rely solely on the security of onion services. If your adversary can wiretap the whole Western Internet, or has a million dollar budget, and you only depend on hidden services for your anonymity then you should probably up your game. You can add more layers of anonymity by buying the servers you host your hidden service on anonymously (e.g. with bitcoin) so that even if they deanonymize you, they can't get your identity from the server. Also studying and actually understanding the Tor protocol and its threat model is essential practice if you are defending against motivated adversaries.

7. What onion services don’t exist yet that you would like to see? 
Onion services right now are super-volatile; they may appear for three months and then they disappear. For example, there was a Twitter clone, Tor statusnet; it was quite fun--small but cozy. The guy or girl who was running it couldn’t do it any longer. So, goodbye! It would be very nice to have a Twitter clone in onion services. Everyone would be anonymous. Short messages by anonymous people would be an interesting thing.
I would like to see apps for mobile phones using onion services more—SnapChat over Tor, Tinder over Tor—using Orbot or whatever. 
A good search engine for onion services. This volatility comes down to not having a search engine—you could have a great service, but only 500 sketchoids on the Internet might know about it.
Right now, hidden services are misty and hard to see, with the fog of war all around. A sophisticated search engine could highlight the nice things and the nice communities; those would get far more traffic and users and would stay up longer.

The second question is how you make things. For many people, it’s not easy to set up an onion service. You have to open Tor, hack some configuration files, and there's more.

We need a system where you double click, and bam, you have an onion service serving your blog. Griffin Boyce is developing a tool for this named Stormy. If we have a good search engine and a way for people to start up onion services easily, we will have a much nicer and more normal Internet in the onion space. 
8. What is the biggest misconception about onion services?
People don't realize how many use cases there are for onion services or the inventive ways that people are using them already. Only a few onion services ever become well known and usually for the wrong reasons.
I think it ties back to the previous discussion--—the onion services we all enjoy have no way of getting to us. Right now, they are marooned on their island of hiddenness. 
9. What is the biggest misconception about onion services development?
It’s a big and complex project—it’s building a network inside a network; building a thing inside a thing. But we are a tiny team. We need the resources and person power to do it.

(Interview conducted by Kate Krauss)

Nov 11, 2015

The Tor Project has learned more about last year's attack by Carnegie Mellon researchers on the hidden service subsystem. Apparently these researchers were paid by the FBI to attack hidden services users in a broad sweep, and then sift through their data to find people whom they could accuse of crimes. We publicized the attack last year, along with the steps we took to slow down or stop such an attack in the future:

Here is the link to their (since withdrawn) submission to the Black Hat conference:
along with Ed Felten's analysis at the time:

We have been told that the payment to CMU was at least $1 million.

There is no indication yet that they had a warrant or any institutional oversight by Carnegie Mellon's Institutional Review Board. We think it's unlikely they could have gotten a valid warrant for CMU's attack as conducted, since it was not narrowly tailored to target criminals or criminal activity, but instead appears to have indiscriminately targeted many users at once.

Such action is a violation of our trust and basic guidelines for ethical research. We strongly support independent research on our software and network, but this attack crosses the crucial line between research and endangering innocent users.

This attack also sets a troubling precedent: Civil liberties are under attack if law enforcement believes it can circumvent the rules of evidence by outsourcing police work to universities. If academia uses "research" as a stalking horse for privacy invasion, the entire enterprise of security research will fall into disrepute. Legitimate privacy researchers study many online systems, including social networks — If this kind of FBI attack by university proxy is accepted, no one will have meaningful 4th Amendment protections online and everyone is at risk.

When we learned of this vulnerability last year, we patched it and published the information we had on our blog:

We teach law enforcement agents that they can use Tor to do their investigations ethically, and we support such use of Tor — but the mere veneer of a law enforcement investigation cannot justify wholesale invasion of people's privacy, and certainly cannot give it the color of "legitimate research".

Whatever academic security research should be in the 21st century, it certainly does not include "experiments" for pay that indiscriminately endanger strangers without their knowledge or consent.

Nov 11, 2015

Draft 1.1

1. Goals of this document.

  • In general, to describe how to conduct responsible research on Tor and similar privacy tools.
  • To develop guidelines for research activity that researchers can use to evaluate their proposed plan.
  • Produce a (non-exhaustive) list of specific types of unacceptable activity.
  • Develop a “due diligence” process for research that falls in the scope of “potentially dangerous” activities. This process can require some notification and feedback from the Tor network or other third parties.

2. General principles

Experimentation does not justify endangering people. Just as in medicine, there are experiments in privacy that can only be performed by creating an unacceptable degree of human harm. These experiments are not justified, any more than the gains to human knowledge would justify unethical medical research on human subjects.

Research on humans' data is human research. Over the last century, we have made enormous strides in what research we consider ethical to perform on people in other domains. For example, we have generally decided that it's ethically dubious to experiment on human subjects without their informed consent. We should make sure that privacy research is at least as ethical as research in other fields.

We should use our domain knowledge concerning privacy when assessing risks. Privacy researchers know that information which other fields consider non-invasive can be used to identify people, and we should take this knowledge into account when designing our research.

Finally, users and implementors must remember that "should not" does not imply "can not." Guidelines like these can serve to guide researchers who are genuinely concerned with doing the right thing and behaving ethically; they cannot restrain the unscrupulous or unethical. Against invasions like these, other mechanisms (like improved privacy software) are necessary.

3. Guidelines for research

  1. Only collect data that is acceptable to publish. If it would be inappropriate to share it with the world, it is invasive to collect it. In the case of encrypted or secret-shared data, it can be acceptable to assume that the keys or some shares are not published.
  2. Only collect as much data as is needed: practice data minimization.
    1. Whenever possible, use analysis techniques that do not require sensitive data, but which work on anonymized aggregates.
  3. Limit the granularity of the data. For example, "noise" (added data inaccuracies) should almost certainly be added. This will require a working statistical background, but helps to avoid harm to users.
  4. Make an explicit description of benefits and risks, and argue that the benefits outweigh the risks.
    1. In order to be sure that risks have been correctly identified, seek external review from domain experts. Frequently there are non-obvious risks.
    2. Consider auxiliary data when assessing the risk of your research. Data which is not damaging on its own can become dangerous when other data is also available. For example, data from exit traffic can be combined with entry traffic to deanonymize users.
    3. Respect people's own judgments concerning their privacy interests in their own data.
    4. It's a warning sign if you can't disclose details of your data collection in advance. If knowing about your study would cause your subjects to object to it, that's a good sign that you're doing something dubious.
  5. Use a test network when at all possible.
    1. If you can experiment either on a test network without real users, or on a live network, use the test network.
    2. If you can experiment either on your own traffic or on the traffic of strangers, use your own traffic.
    3. "It was easier that way" is not justification for using live user traffic over test network traffic.

4. Examples of unacceptable research activity

  • It is not acceptable to run an HSDir, harvest onion addresses, and publish or connect to those onion addresses.
  • Don't set up exit relays to sniff, or tamper with exit traffic. Some broad measurements (relative frequency of ports; large-grained volume) may be acceptable depending on risk/benefit tradeoffs; fine-grained measures are not.
  • Don't set up relays that are deliberately dysfunctional (e.g., terminate connections to specific sites).

Nov 05, 2015

We are pleased to announce the first release in our new hardened Tor Browser series. The download can be found in the 5.5a4-hardened distribution directory and on the download page for hardened builds.

For now this is for Linux 64bit systems only but we are thinking about supporting OS X and Windows in the future as well. As always, these builds are fully bit-for-bit reproducible.

The hardened series is built on top of the regular alpha series: it contains all the changes of the latter and further hardening, mainly against exploitation of memory corruption bugs. To this end Tor and Firefox are compiled with Address Sanitizer enabled (Tor even ships with another checker, the Undefined Behavior Sanitizer).

This additional hardening helps in two ways:

  • It gives users an even more secure Tor Browser (especially at higher security levels where Javascript is partially or completely disabled).
  • It helps identifying issues earlier allowing us to develop and backport fixes to the regular alpha and stable series.

This hardening comes with some downsides: these builds are slower than regular builds, and consume more memory. And, above all, they are considerably larger than alpha or release builds. That's why we decided to make another big change for this new series: there will only be one bundle shipped supporting all the languages found in alpha builds. Tor Launcher should help selecting the desired locale during the first start taking the operating system locale into account.

We should also point out that the hardening provided by Address Sanitizer is not perfect. In particular, if an adversary is able to determine that Address Sanitizer is in use, they may be able to use JavaScript to take advantage of this information and retain their ability to still exploit some classes of bugs. We are especially interested to learn if there are any clear ways to fingerprint our Address Sanitizer builds with a high degree of certainty for this reason. (Fair warning: performance-only fingerprinting may not be convincing without a lot of rigorous analysis, especially given that variables such as the JIT being enabled or disabled on many different types of hardware need to be taken into account).

Our initial hope was to use SoftBounds+CETS (or SafeCode), which do not have the weaknesses of Address Sanitizer, but these projects are not mature enough to compile Tor Browser (or Firefox, for that matter). We are actively exploring other hardening options, as well, and are happy to hear more suggestions.

We're especially eager to hear reports and stack traces from any crashes experienced in these builds, as they may be evidence of potentially exploitable memory issues that have not been detected in our normal builds! Advanced users may find these GDB instructions useful for this, but even the plain Address Sanitizer crash output should still be helpful.

Nov 04, 2015

A new alpha Tor Browser release is available for download in the 5.5a4 distribution directory and on the alpha download page.

This release features important security updates to Firefox.

Moreover, it comes with Tor and a number of other improvements. Most notably, we included Yan Zhu's fix for not leaking the Referer header when leaving a .onion domain and finally sorted out the HTTPS-Everywhere build problems allowing us to ship its latest version in our bundles again.

We fixed usability issues caused by our font fingerprinting patches and included a new defense against figerprinting users via available MIME types and plugins. Finally, besides additional minor bug fixes and clean-ups, we included an updated NoScript version.

Here is the complete changelog since 5.5a3:

  • All Platforms
    • Update Firefox to 38.4.0esr
    • Update Tor to
    • Update NoScript to
    • Update HTTPS-Everywhere to 5.1.1
    • Update Torbutton to
      • Bug 9623: Spoof Referer when leaving a .onion domain
      • Bug 16620: Remove old handling code
      • Bug 17164: Don't show text-select cursor on circuit display
      • Bug 17351: Remove unused code
      • Translation updates
    • Bug 17207: Hide MIME types and plugins from websites
    • Bug 16909+17383: Adapt to HTTPS-Everywhere build changes
    • Bug 16620: Move handling into a Firefox patch
    • Bug 17220: Support math symbols in font whitelist
    • Bug 10599+17305: Include updater and build patches needed for hardened builds
    • Bug 17318: Remove dead ScrambleSuit bridge
    • Bug 17428: Remove default Flashproxy bridges
    • Bug 17473: Update meek-amazon fingerprint
  • Windows
    • Bug 17250: Add localized font names to font whitelist
  • OS X
    • Bug 17122: Rename Japanese OS X bundle
  • Linux
    • Bug 17329: Ensure that non-ASCII characters can be typed (fixup of #5926)

Nov 04, 2015

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

This release features important security updates to Firefox.

Additionally, we included Yan Zhu's fix for not leaking the Referer header when leaving a .onion domain and are shipping an updated NoScript version.

These and all the other changes (minor bug fixes and clean-ups) can be found in the complete changelog since 5.0.3:

  • All Platforms
    • Update Firefox to 38.4.0esr
    • Update NoScript to
    • Update Torbutton to
      • Bug 9623: Spoof Referer when leaving a .onion domain
      • Bug 16735: about:tor should accommodate different fonts/font sizes
      • Bug 16937: Don't translate the homepage/spellchecker dictionary string
      • Bug 17164: Don't show text-select cursor on circuit display
      • Bug 17351: Remove unused code
      • Translation updates
    • Bug 16937: Remove the en-US dictionary from non en-US Tor Browser bundles
    • Bug 17318: Remove dead ScrambleSuit bridge
    • Bug 17473: Update meek-amazon fingerprint
    • Bug 16983: Isolate favicon requests caused by the tab list dropdown
    • Bug 17102: Don't crash while opening a second Tor Browser
  • Windows
    • Bug 16906: Don't depend on Windows crypto DLLs
  • Linux
    • Bug 17329: Ensure that non-ASCII characters can be typed (fixup of #5926)