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

Sep 30, 2015


We are very happy to tell you that the Tor meeting in Berlin is currently underway!

During the past days we've been busy discussing the future of Tor as an organization and designing the protocols and features that we want to see in the future.

We would like to inform you that tomorrow (Thursday, October 1st) we will be
having an open day where everyone is welcome to come and discuss Tor
with us. People interested in Tor are welcome regardless of their
background or skills.

The meeting is taking place at Betahaus in Berlin all day, and you can find more information in the wiki.

Looking forward to see you here!

Thank you!

Sep 25, 2015

Tor is the first release candidate in the 0.2.7 series. It contains numerous usability fixes for Ed25519 keys, safeguards against several misconfiguration problems, significant simplifications to Tor's callgraph, and numerous bugfixes and small features.

This is the most tested release of Tor to date. The unit tests cover 39.40% of the code, and the integration tests (accessible with "make test-full-online", requiring stem and chutney and a network connection) raise the coverage to 64.49%.

NOTE: This is a release candidate. We think we've squashed most of the bugs, but there are probably a few more left over.

Changes in version - 2015-09-25

  • Major features (security, 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.
  • Major features (Ed25519 keys, keypinning):
    • The key-pinning option on directory authorities is now advisory- only by default. In a future version, or when the AuthDirPinKeys option is set, pins are enforced again. Disabling key-pinning seemed like a good idea so that we can survive the fallout of any usability problems associated with Ed25519 keys. Closes ticket 17135.


  • Major features (Ed25519 performance):
    • 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 signature verification by using Ed25519-donna's batch verification support. Implements ticket 16533.
  • Major features (performance testing):
    • The script now supports performance testing. Requires corresponding chutney performance testing changes. Patch by "teor". Closes ticket 14175.
  • Major features (relay, Ed25519):
    • 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!
    • 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.
    • Add a --newpass option to allow changing or removing the passphrase of an encrypted key with tor --keygen. Implements part of ticket 16769.
    • On receiving a HUP signal, check to see whether the Ed25519 signing key has changed, and reload it if so. Closes ticket 16790.
  • Major bugfixes (relay, Ed25519):
    • Avoid crashing on 'tor --keygen'. Fixes bug 16679; bugfix on Reported by "s7r".
    • Improve handling of expired signing keys with offline master keys. Fixes bug 16685; bugfix on Reported by "s7r".
  • Minor features (client-side privacy):
    • New KeyAliveSOCKSAuth 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 (compilation):
    • Give a warning as early as possible when trying to build with an unsupported OpenSSL version. Closes ticket 16901.
    • Fail during configure if we're trying to build against an OpenSSL built without ECC support. Fixes bug 17109, bugfix on which started requiring ECC.
  • Minor features (geoip):
    • Update geoip and geoip6 to the September 3 2015 Maxmind GeoLite2 Country database.
  • Minor features (hidden services):
    • 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.
    • 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.
  • Minor features (testing, authorities, documentation):
    • 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.
  • 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 bug fixes (torrc exit policies):
    • 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 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.
    • 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.
    • 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
  • Minor bugfixes (authority):
    • Don't assign "HSDir" to a router if it isn't Valid and Running. Fixes bug 16524; bugfix on
    • Downgrade log messages about Ed25519 key issues if they are in old cached router descriptors. Fixes part of bug 16286; bugfix on
    • When we find an Ed25519 key issue in a cached descriptor, stop saying the descriptor was just "uploaded". Fixes another part of bug 16286; bugfix on
  • Minor bugfixes (control port):
    • Repair a warning and a spurious result when getting the maximum number of file descriptors from the controller. Fixes bug 16697; bugfix on
  • Minor bugfixes (correctness):
    • 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 (documentation):
    • Advise users on how to configure separate IPv4 and IPv6 exit policies in the manpage and sample torrcs. Related to ticket 16069.
    • Fix the usage message of tor-resolve(1) so that it no longer lists the removed -F option. Fixes bug 16913; bugfix on
    • 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
  • Minor bugfixes (Ed25519):
    • Fix a memory leak when reading router descriptors with expired Ed25519 certificates. Fixes bug 16539; bugfix on
  • Minor bugfixes (linux seccomp2 sandbox):
    • Allow bridge authorities to run correctly under the seccomp2 sandbox. Fixes bug 16964; bugfix on
    • Allow routers with ed25519 keys to run correctly under the seccomp2 sandbox. Fixes bug 16965; bugfix on
  • 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):
    • 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.
    • Check correctly for Windows socket errors in the workqueue backend. Fixes bug 16741; bugfix on
    • Fix the behavior of crypto_rand_time_range() when told to consider times before 1970. (These times were possible when running in a simulated network environment where time()'s output starts at zero.) Fixes bug 16980; bugfix on
    • Restore correct operation of TLS client-cipher detection on OpenSSL 1.1. Fixes bug 14047; bugfix on
  • 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
    • Unblock threads before releasing the work queue mutex to ensure predictable scheduling behavior. Fixes bug 16644; bugfix on
  • 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.
    • 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.
    • 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.
    • 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.
    • 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.
    • Remove the unused "nulterminate" argument from buf_pullup().
  • Documentation:
    • Recommend a 40 GB example AccountingMax in torrc.sample rather than a 4 GB max. Closes ticket 16742.
    • Include the TUNING document in our source tarball. It is referred to in the ChangeLog and an error message. Fixes bug 16929; bugfix on
  • Removed code:
    • 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.
    • 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.
  • Testing:
    • 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".
    • Autodetect CHUTNEY_PATH if the chutney and Tor sources are side- by-side in the same parent directory. Closes ticket 16903. Patch by "teor".
    • 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.
    • 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.
    • 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.
    • Unit test dns_resolve(), dns_clip_ttl() and dns_get_expiry_ttl() functions in dns.c. Implements a portion of ticket 16831.
    • 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.

Sep 22, 2015

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

This release features important security updates to Firefox.

Beginning with this alpha version Tor Browser is available in Japanese as well. In addition to that it contains usability improvements for our font fingerprinting defense, a better notification of Tor Browser changes after an update and regression fixes that were caused by our switch to ESR 38 back in August.

Here is the complete changelog since 5.5a2:

  • All Platforms
    • Update Firefox to 38.3.0esr
    • Update Torbutton to 1.9.4
      • Bug 16937: Don't translate the hompepage/spellchecker dictionary string
      • Bug 16735: about:tor should accommodate different fonts/font sizes
      • Bug 16887: Update intl.accept_languages value
      • Bug 15493: Update circuit display on new circuit info
      • Bug 16797: brandShorterName is missing from
      • Translation updates
    • Bug 10140: Add new Tor Browser locale (Japanese)
    • Bug 17102: Don't crash while opening a second Tor Browser
    • Bug 16983: Isolate favicon requests caused by the tab list dropdown
    • Bug 13512: Load a static tab with change notes after an update
    • Bug 16937: Remove the en-US dictionary from non en-US Tor Browser bundles
    • Bug 7446: Tor Browser should not "fix up" .onion domains (or any domains)
    • Bug 16837: Disable Firefox Hotfix updates
    • Bug 16855: Allow blobs to be downloaded on first-party pages (fixes
    • Bug 16781: Allow saving pdf files in built-in pdf viewer
    • Bug 16842: Restore Media tab on Page information dialog
    • Bug 16727: Disable about:healthreport page
    • Bug 16783: Normalize NoScript default whitelist
    • Bug 16775: Fix preferences dialog with security slider set to "High"
    • Bug 13579: Update download progress bar automatically
    • Bug 15646: Reduce keyboard layout fingerprinting in KeyboardEvent
    • Bug 17046: Event.timeStamp should not reveal startup time
    • Bug 16872: Fix warnings when opening about:downloads
    • Bug 17097: Fix intermittent crashes when using the print dialog
  • Windows
    • Bug 16906: Fix Mingw-w64 compilation breakage
    • Bug 16707: Allow more system fonts to get used on Windows
  • OS X
    • Bug 16910: Update copyright year in OS X bundles
    • Bug 16707: Allow more system fonts to get used on OS X
  • Linux
    • Bug 16672: Don't use font whitelisting for Linux users

Update: It seems claiming that our builds are reproducible with LXC as well now was a bit premature (see bug 12240 for details). Thus, this part got removed from the changelog.

Sep 22, 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.

We fixed a number of regressions from our switch to ESR 38 back in August and reduced keyboard layout fingerprinting to mention just some highlights.

These and all the other changes can be found in the complete changelog since 5.0.2:

  • All Platforms
    • Update Firefox to 38.3.0esr
    • Update Torbutton to
      • Bug 16887: Update intl.accept_languages value
      • Bug 15493: Update circuit display on new circuit info
      • Bug 16797: brandShorterName is missing from
      • Bug 14429: Make sure the automatic resizing is disabled
      • Translation updates
    • Bug 7446: Tor Browser should not "fix up" .onion domains (or any domains)
    • Bug 16837: Disable Firefox Hotfix updates
    • Bug 16855: Allow blobs to be downloaded on first-party pages (fixes
    • Bug 16781: Allow saving pdf files in built-in pdf viewer
    • Bug 16842: Restore Media tab on Page information dialog
    • Bug 16727: Disable about:healthreport page
    • Bug 16783: Normalize NoScript default whitelist
    • Bug 16775: Fix preferences dialog with security slider set to "High"
    • Bug 13579: Update download progress bar automatically
    • Bug 15646: Reduce keyboard layout fingerprinting in KeyboardEvent
    • Bug 17046: Event.timeStamp should not reveal startup time
    • Bug 16872: Fix warnings when opening about:downloads
    • Bug 17097: Fix intermittent crashes when using the print dialog
  • Windows
    • Bug 16906: Fix Mingw-w64 compilation breakage
  • OS X
    • Bug 16910: Update copyright year in OS X bundles

Sep 14, 2015

This blog post is also available in Chinese, translated by our friends from

Roya, David, Nick, nweaver, Vern, and I just finished a research project in which we revisited the Great Firewall of China's (GFW) active probing system. This system was brought to life several years ago to reactively probe and block circumvention proxies, including Tor. You might remember an earlier blog post that gave us some first insight into how the active probing system works. Several questions, however, remained. For example, we were left wondering what the system's physical infrastructure looked like. Is the GFW using dedicated machines behind their thousands of probing IP addresses? Does the GFW even "own" all these IP addresses? Rumour had it that the GFW was hijacking IP addresses for a short period of time, but there was no conclusive proof. As a result, we teamed up and set out to answer these, and other questions.

Because this was a network measurement project, we started by compiling datasets. We created three datasets, comprising hours (a Sybil-like experiment to attract many probes), months (an experiment to measure reachability for clients in China), and even years (log files of a long-established server) worth of active probing data. Together, these datasets allow us to look at the GFW's active probing system from different angles, illuminating aspects we wouldn't be able to observe with just a single dataset. We are able to share two of our datasets, so you are very welcome to reproduce our work, or do your own analysis.

We now want to give you an overview of our most interesting findings.

  • Generally, once a bridge is detected and blocked by the GFW, it remains blocked. But does this mean that the bridge is entirely unreachable? We measured the blocking effectiveness by continuously making a set of virtual private systems in China connect to a set of bridges under our control. We found that every 25 hours, for a short period of time, our Tor clients in China were able to connect to our bridges. This is illustrated in the diagram shown below. Every point represents one connection attempt, meaning that our client in China was trying to connect to our bridge outside of China. Note the curious periodic availability pattern for both Unicom and CERNET (the two ISPs in China we measured from). Sometimes, network security equipment goes into "fail open" mode while it updates its rule set, but it is not clear if this is happening here.

  • We were able to find patterns in the TCP headers of active probes that suggest that all these thousands of IP addresses are, in fact, controlled by a single source. Check out the initial sequence number (ISN) pattern in the diagram below. It shows the value of ISNs (y-axis) over time (x-axis). Every point in the graph represents the SYN segment of one active probing connection. If all probing connections would have come from independent computers, we would have expected a random distribution of points. That's because ISNs are typically chosen randomly to protect against off-path attackers. Instead, we see a clear linear pattern across IP addresses. We believe that active probes derive their ISN from the current time.

  • We discovered that Tor is not the only victim of active probing attacks; the GFW is targeting other circumvention systems, namely SoftEther and GoAgent. This highlights the modular nature of the active probing system. It appears to be easy for GFW engineers to add new probing modules to react to emerging, proxy-based circumvention tools.
  • The GFW is able to (partially) speak the vanilla Tor protocol, obfs2, and obfs3 to probe bridges. Interestingly, node-Tor—a JavaScript implementation of the Tor protocol—is immune to active probing because it implements the Tor protocol differently, which seems to confuse active probes. We were also able to resist active probes by modifying a bridge of ours to ignore old VERSIONS Tor cells. This is unlikely to be a sustainable circumvention technique, though.
  • Back in 2012, the system worked in 15-minute-queues. These days, it seems to be able to scan bridges in real-time. On average, it takes only half a second after a bridge connection for an active probe to show up.
  • Using a number of traceroute experiments, we could show that the GFW's sensor is stateful and seems unable to reassemble TCP streams.

Luckily, we now have several pluggable transports that can defend against active probing. ScrambleSuit and its successor, obfs4, defend against probing attacks by relying on a shared secret that is distributed out of band. Meek tunnels traffic over cloud infrastructure, which does not prevent active probing, but greatly increases collateral damage when blocked. While we keep developing and maintaining circumvention tools, we need to focus more on usability. A powerful and carefully-engineered circumvention tool is of little use if folks find it too hard to use. That's why projects like the UX sprint are so important.

Finally, you can find our research paper as well as our datasets and code on our project page. And don't hesitate to get in touch with us if you have any questions or feedback!

Sep 10, 2015

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

Introducing the tor-teachers list

Just as the the Tor network itself grows and evolves through the efforts of volunteer relay operators in numerous countries, information about how and why users should make use of the protections that Tor offers is also spread by an informal network of teachers and activists working in many different communities around the world. Tor talks and trainings are often a feature of free public privacy events like cryptoparties, as well as Internet security workshops put on by groups and organizations especially in need of online privacy in their activities.

Until now, Tor teachers have had no central meeting-place to share advice, compare experiences, or make future plans, so Alison Macrina and Nima Fatemi this week announced the creation of the tor-teachers mailing list. According to Alison, whose Library Freedom Project is itself engaged in teaching Tor and other online privacy tools to librarians and library patrons across America (and beyond), “this list is for all the awesome people around the world who are teaching Tor to their communities, who want to work collectively with other teachers of Tor to support each other, build community, and make our work even better”. Topics of discussion will range from “visionary stuff” like the philosophical underpinnings of the right to free expression and inquiry, to more prosaic Tor-related questions such as “how to use the darn thing” and how best to convey this to users from all backgrounds.

If this sounds like the sort of thing you either would like to be doing or are already an old hand at, you are most welcome to join! Visit the list-info page to sign up. As with almost all of Tor’s mailing lists, messages are publicly visible and archived, so you can take a look at current discussions to see if you want to get involved. Good luck!

Miscellaneous news

Luke Millanta announced the launch of OnionView, a web service which utilizes Tor relay data, gathered using the Onionoo network status protocol, to plot the location of active Tor nodes onto an interactive map of the world. Created in collaboration with Tor’s Measurement team, OnionView’s relay database is updated every thirty minutes to help ensure map accuracy. Join the developers in the #tor-dev IRC channel to become involved in future work on OnionView.

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

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!

Sep 04, 2015

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

Tor Browser 5.0.2 and 5.5a2 are out

The Tor Browser team announced new stable and alpha releases of the privacy-preserving web browser. Version 5.0.2 fixes a bug that was causing the browser’s launcher icons in the Ubuntu Unity and GNOME desktops to be duplicated, and includes a newer version of the NoScript add-on. Version 5.5a2 incorporates these updates along with another small crash bug fix from the stable series.

Both new releases include important security updates to their respective Firefox versions, so please ensure you upgrade as soon as possible. If you are already running a recent Tor Browser, it has probably updated itself already; if not, head to the project page to download your copy now.

Final reports from two Summer of Privacy students

Two of the developers participating in Tor’s first-ever Summer of Privacy coding season, Jesse Victors and Donncha O’Cearbhaill, submitted their final progress reports after months of intensive development.

Jesse’s DNS-like naming system for onion services is already in a testable state. “All of the infrastructure for OnioNS is in place”, and while a few protocols are still to be finished, “the client-side and HS-side software is pretty reliable and stable at this point”, with support for Debian, Ubuntu, Mint, and Fedora. Development will continue into the future, and “once the OnioNS software is fully ready, no modifications to Tor should be necessary to merge OnioNS into the Tor network”.

Donncha’s project, the onion service load-balancing manager OnionBalance, has also seen one testing release, and the next steps in development are to package the software for Debian, clarify the documentation, and implement “smartcard / HSM support master service key storage and signing”. “I’ll continue developing OnionBalance so that if possible, it can facilitate some form of load balancing and redundancy with next-gen hidden services”.

Congratulations to Jesse and Donncha on getting their innovative projects to this stage, and thanks to the mentors and coordinators who have made the Summer of Privacy a success. The southern-hemisphere development timetable is still ongoing, however, so stay tuned for updates from Israel and Cristóbal Leiva on their TSoP projects.

Should cloud-based Tor relays be rejected?

Observing that “we sometimes see attacks from relays that are hosted on cloud platforms”, Philipp Winter investigated the actual benefit to the Tor network that these relays provide. He found that in an average consensus from July 2015, “cloud-hosted relays contributed only around 0.8% of bandwidth” (with the caveat that “this is just a lower bound”). Rejecting such relays from the consensus might force attackers to jump through more hoops, but would mean “obtaining the netblocks that are periodically published by all three (and perhaps more) cloud providers”.

Tim Wilson-Brown (teor) wondered about the effect this might have on Tor developers and researchers who would like to use cloud-based relays, while nusenu requested that any rejection be publicly documented “so volunteers don’t waste their time and money setting up blacklisted relays”.

Miscellaneous news

Karsten Loesing announced version 2.6 of Onionoo, the Tor network data observatory. This release adds two new relay family-related fields to details documents that, together with the “effective_family” field introduced in version 2.4, replace the older “family” field, which is now deprecated. These new fields support different family-mapping use-cases that may be required by Tor network tools such as Atlas, Globe, and Roster. “The current ‘family’ field will stay available until Atlas and Globe are updated. If I should also wait for other clients to be updated, please let me know.”

After several television appearances over the past few years, Tor made its literary debut last month in the fourth installment of the late Stieg Larsson’s Millennium series. A warm Tor community welcome to Lisbeth Salander — though a subscription to Tor Weekly News might clear up some of her misconceptions

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

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

Aug 30, 2015

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

Hash visualizations to protect against onion phishing

Unlike URLs on the non-private web, the .onion addresses used by Tor hidden services are not handed out by any central authority — instead, they are derived by the hidden services themselves based on their cryptographic key information. This means that they are typically quite hard for humans to remember, unless the hidden service operator — whether by chance or by making repeated attempts — hits upon a memorable string, as in the case of Facebook’s hidden service.

“The problem”, writes George Kadianakis, is that due to these user-unfriendly strings, “many people don’t verify the whole onion address, they just trust the onion link or verify the first few characters. This is bad since an attacker can create a hidden service with a similar onion address very easily”, then trick users into visiting that address instead for a variety of malicious purposes. This species of attack that has already been seen in the wild. After discussions with other researchers in this area, George drew up a proposal to incorporate visual information into the verification process: “So when TBB connects to a hidden service, it uses the onion address to generate a randomart or key poem and makes them available for the user to examine.”

As with all new development proposals, however, there are many unanswered questions. What kind of visualization would work best? Should there also be an auditory component, like a randomly-generated tune? How should the feature be made available to users without confusing those who have no idea what it is or why it’s needed? In short, “Some real UX research needs to be done here, before we decide something terrible.”

If you have clear and constructive feedback to offer on this unusual but important proposal, please send it to the tor-dev mailing list.

Tor-enabled Debian mirrors

Richard Hartmann, Peter Palfrader, and Jonathan McDowell have set up the first official onion service mirrors of the Debian operating system’s software package infrastructure. This means that it is now possible to update your Debian system without the update information or downloaded packages leaving the Tor network at all, preventing a network adversary from discovering information about your system. A follow-up post by Richard includes guidance on using apt-transport-tor with the new mirrors.

These services are only the first in what should hopefully become a fully Tor-enabled system mirroring “the complete package lifecycle, package information, and the website”. “This service is not redundant, it uses a key which is stored on the local drive, the .onion will change, and things are expected to break”, wrote Richard, but if you are interested in trying out the new infrastructure, see the write-ups for further information.

Miscellaneous news

David Fifield announced that his 17-minute PETS talk on the theory and practice of “domain fronting”, which is the basis for Tor’s innovative and successful meek pluggable transport, is now available to view online.

Arturo Filastò announced that registration for ADINA15, the upcoming OONI hackathon at the Italian Parliament in Rome, is now open. If you’re interested in hacking on internet censorship data in this rarified location, with the possibility of “interesting prizes” for the winning teams, see Arturo’s mail for the full details.

Arturo also sent out the OONI team’s July status report, while Tor Summer of Privacy progress updates were submitted by Israel Leiva, Cristobal Leiva, and Jesse Victors.

Fabio Pietrosanti issued an open call for developers interested in working on GlobaLeaks, the open-source anonymous whistleblowing software. “Are you interested in making the world a better place by putting your development skills to use in a globally used free software project? Do you feel passionate about using web technologies for developing highly usable web applications?” If so, please see Fabio’s message for more information.

News from Tor StackExchange

saurav created a network using the Shadow simulator and started with 40 guard and 40 exit nodes. After a simulation was performed, another 40/40 nodes were added. saurav then noticed that the more recent nodes had a higher probability of being selected. Can you explain why this is the case? The users of Tor’s Q&A page will be happy to know.

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