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

Jul 28, 2015

Hello Tor Community!

We first introduced you to the Library Freedom Project back in February after we won the Knight News Challenge on Libraries. Since then, we’ve been hard at work bringing privacy education to libraries across the United States, with stops in the UK and Ireland, virtual trainings in Canada and Australia, and more plans to visit international libraries in the works.

Today, we're excited to announce a new initiative, a collaboration between the Library Freedom Project and Tor Project: Tor exit relays in libraries. Nima Fatemi, the Tor Project member who's already helped Library Freedom Project in a number of ways, is our main partner on this project. This is an idea whose time has come; libraries are our most democratic public spaces, protecting our intellectual freedom, privacy, and unfettered access to information, and Tor Project creates software that allows all people to have these rights on the internet. We're excited to combine our efforts to help libraries protect internet freedom, strengthen the Tor network, and educate the public about how Tor can help protect their right to digital free expression.

Libraries have been committed to intellectual freedom and privacy for decades, outlining these commitments in the ALA Core Values of Librarianship, the Freedom to Read Statement, and the ALA Code of Ethics. They're also centers of education in their local communities, offering free classes on a variety of subjects, including computer instruction. Libraries serve a diverse audience; many of our community members are people who need Tor but don't know that it exists, and require instruction to understand and use it.

Some of these patrons are part of vulnerable groups, like domestic violence survivors, racial and ethnic minorities, student activists, or queer and trans communities. Others belong to local law enforcement or municipal government. All of them could benefit from learning about Tor in a trusted, welcoming environment like the library.

Bringing Tor exit relays into libraries would not only be a powerful symbolic gesture demonstrating our commitment to a free internet, but also a practical way to help the Tor network, and an excellent opportunity to help educate library patrons, staff, boards of trustees, and other stakeholders about the importance of Tor. For libraries that have already installed Tor Browser on library PCs, running a relay is the obvious next step toward supporting free expression in their communities and all over the world.

As public internet service providers, libraries are shielded from some of the legal concerns that an individual exit relay operator might face, such as trying to explain to law enforcement that the traffic leaving her exit is not her own. Furthermore, libraries are protected from DMCA takedowns by safe harbor provisions. Importantly, librarians know their rights and are ready to fight back when those rights are challenged.

In order to begin this new project, we needed a pilot, and we had just the library in mind – Kilton Library in Lebanon, New Hampshire, one of two Lebanon Libraries. Chuck McAndrew is the IT librarian there, and he's done amazing things to the computers on his network, like running them all on GNU/Linux distributions. Why is this significant? Most library environments run Microsoft Windows, and we know that Microsoft participated in the NSA's PRISM surveillance program. By choosing GNU/Linux and installing some privacy-protecting browser extensions too, Chuck's helping his staff and patrons opt-out of pervasive government and corporate surveillance. Pretty awesome.

Kilton Library is not only exemplary because of its GNU/Linux computer environment; it's also beautiful and brand-new, LEED Gold-certified, with an inviting and sunny open floor plan and an outdoor community garden. It's an example of the amazing potential inherent in libraries. We drove up to New Hampshire last week to start phase one.

We decided to set our pilot up as a middle relay to start – we want to ensure that it is stable and doesn't interfere in any way with the library's other network traffic. We nicknamed the new relay LebLibraries, and you can check out how our relay is doing here, on Globe.

After the LebLibraries relay is up for a few months, we'll return for phase two of the project and convert it into an exit node. Our goal is to make exit relay configuration a part of the Library Freedom Project's privacy trainings for librarians; we'll meet with library directors and boards of trustees to talk about how Tor fits into the mission of libraries as beacons of intellectual freedom, and how libraries are perfectly positioned not only to help our patrons use Tor Browser, but are the ideal location to run Tor exit relays to help give back to the Tor community.

We need more libraries to join us in this initiative. Want your local library to be our next exit relay site? Know an awesome librarian who wants to help protect free expression locally and globally? Please have them contact us with the answers to this questionnaire. We're also looking for libraries to host FOSS seedboxes. And as always, we want libraries to install and run the Tor Browser on library computers.

Want to support this project and more like it? You can make a donation to the Library Freedom Project, or donate directly to Tor Project. And stay tuned for phase two of our pilot with Kilton Library.

Alison Macrina and Nima Fatemi


A version of this post also appeared on The Library Freedom Project’s blog

Note: This post was drafted by Alison. (Thank you!)

Jul 27, 2015

This, the second alpha in the Tor 0.2.7 series, has a number of new features, including a way to manually pick the number of introduction points for hidden services, and the much stronger Ed25519 signing key algorithm for regular Tor relays (including support for encrypted offline identity keys in the new algorithm).

Support for Ed25519 on relays is currently limited to signing router descriptors; later alphas in this series will extend Ed25519 key support to more parts of the Tor protocol.

If you typically build Tor from source, you can download the source code from the usual place on the website.
Packages should be up in a few days.

Changes in version 0.2.7.2-alpha - 2015-07-27
  • Major features (Ed25519 identity keys, Proposal 220):
    • 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 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.
  • Major features (Hidden services):
    • 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 features (performance):
    • 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 bugfixes (client-side privacy, also in 0.2.6.9):
    • 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 0.2.6.3-alpha. Patch by "jojelino".
  • Major bugfixes (hidden service clients, stability, also in 0.2.6.10):
    • 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 0.2.6.3-alpha.
  • Major bugfixes (hidden services):
    • 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 0.1.0.1-rc.
  • 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 0.1.1.1-alpha.
  • Major bugfixes (stability, also in 0.2.6.10):
    • Stop crashing with an assertion failure when parsing certain kinds of malformed or truncated microdescriptors. Fixes bug 16400; bugfix on 0.2.6.1-alpha. 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 0.1.0.1-rc.
  • Minor features (directory authorities, security, also in 0.2.6.9):
    • 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 (client):
    • 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.
    • 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 0.2.6.2-alpha.
    • 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.
  • Minor features (control protocol):
    • Support network-liveness GETINFO key and NETWORK_LIVENESS event in the control protocol. Resolves ticket 15358.
  • 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 (geoip, also in 0.2.6.10):
    • Update geoip to the June 3 2015 Maxmind GeoLite2 Country database.
    • Update geoip6 to the June 3 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.
  • Minor features (portability):
    • 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 bugfixes (compilation, also in 0.2.6.9):
    • Build with --enable-systemd correctly when libsystemd is installed, but systemd is not. Fixes bug 16164; bugfix on 0.2.6.3-alpha. Patch from Peter Palfrader.
  • 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 0.2.5.2-alpha.
  • Minor bugfixes (crypto error-handling, also in 0.2.6.10):
    • 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 0.2.5.2-alpha, introduced when implementing ticket 4900. Patch by "teor".
  • Minor bugfixes (hidden services):
    • Fix a crash when reloading configuration while at least one configured and one ephemeral hidden service exists. Fixes bug 16060; bugfix on 0.2.7.1-alpha.
    • Avoid crashing with a double-free bug when we create an ephemeral hidden service but adding it fails for some reason. Fixes bug 16228; bugfix on 0.2.7.1-alpha.
  • 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 0.2.3.1-alpha.
  • Minor bugfixes (Linux seccomp2 sandbox, also in 0.2.6.10):
    • Allow pipe() and pipe2() syscalls in the seccomp2 sandbox: we need these when eventfd2() support is missing. Fixes bug 16363; bugfix on 0.2.6.3-alpha. Patch from "teor".
  • Minor bugfixes (Linux seccomp2 sandbox, also in 0.2.6.9):
    • 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 0.2.6.1-alpha. Patch by Peter Palfrader.
    • Allow systemd connections to work with the Linux seccomp2 sandbox code. Fixes bug 16212; bugfix on 0.2.6.2-alpha. Patch by Peter Palfrader.
  • Minor bugfixes (relay):
    • Fix a rarely-encountered memory leak when failing to initialize the thread pool. Fixes bug 16631; bugfix on 0.2.6.3-alpha. Patch from "cypherpunks".
  • Minor bugfixes (systemd):
    • Fix an accidental formatting error that broke the systemd configuration file. Fixes bug 16152; bugfix on 0.2.7.1-alpha.
    • 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 0.2.5.5-alpha.
  • Minor bugfixes (tests):
    • Use the configured Python executable when running test-stem-full. Fixes bug 16470; bugfix on 0.2.7.1-alpha.
  • Minor bugfixes (tests, also in 0.2.6.9):
    • Fix a crash in the unit tests when built with MSVC2013. Fixes bug 16030; bugfix on 0.2.6.2-alpha. Patch from "NewEraCracker".
  • Minor bugfixes (threads, comments):
    • Always initialize return value in compute_desc_id in rendcommon.c Patch by "teor". Fixes part of bug 16115; bugfix on 0.2.7.1-alpha.
    • Check for NULL values in getinfo_helper_onions(). Patch by "teor". Fixes part of bug 16115; bugfix on 0.2.7.1-alpha.
    • Remove undefined directive-in-macro in test_util_writepid clang 3.7 complains that using a preprocessor directive inside a macro invocation in test_util_writepid in test_util.c is undefined. Patch by "teor". Fixes part of bug 16115; bugfix on 0.2.7.1-alpha.
  • Code simplification and refactoring:
    • Define WINVER and _WIN32_WINNT centrally, in orconfig.h, in order to ensure they remain consistent and visible everywhere.
    • Remove some vestigial workarounds for the MSVC6 compiler. We haven't supported that in ages.
    • 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.
  • Documentation:
    • 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.
  • Removed features:
    • Tor no longer supports copies of OpenSSL that are missing support for Elliptic Curve Cryptography. (We began using ECC when available in 0.2.4.8-alpha, 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.
    • 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.
  • Testing:
    • 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.
    • 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".
    • 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.

Jul 22, 2015

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

More TSoP status reports

The students in this year’s Tor Summer of Privacy continued work on their respective projects, as their status reports show.

Jesse Victors made significant progress on his DNS-like Onion Naming System (OnioNS) project at the recent onion service development meeting in Washington, DC. Many bugs were fixed and the software is now in a demonstration-ready state. The issue of implementing a global source of randomness, which is important for the next generation of onion services as well as for OnionNS, was also worked on. “The server-to-server communication needs a few bug fixes, but most of that code is in place. As soon as that is complete, I should be about ready for a beta test.”

Israel Leiva sent the first report on his GetTor enhancement project. GetTor now distributes links to copies of Tor Browser hosted on Github as well as Dropbox, and the text of the autoresponder was expanded with more information. Upcoming additions include a Google Drive script, distribution of mirror links, and the promotion of Github to the default download source.

Cristobal Leiva also sent his first report, for the relay web status dashboard project. A prototype UI has been created and development milestones have been prioritized: “Over the next two weeks I’ll be coding the graph and log components”.

Finally, Donncha O’Cearbhaill’s OnionBalance load-balancing system has been enhanced with unit tests, and has received some real-world testing courtesy of s7r .

Exciting progress all round!

Miscellaneous news

The Guardian Project announced new releases of Chatsecure and Orbot. Chatsecure v14.2.0 is “all about squashing bugs, reducing memory and improving network stability”, while Orbot 15.0.3-RC-3 features “overall improvements to system and server stability, improvements to Apps VPN mode support…improved launch and hidden service API for third-party app interaction”, and updates to Tor and OpenSSL.

Anthony G. Basile announced a new release of tor-ramdisk, the micro Linux distribution whose only purpose is to host a Tor server in an environment that maximizes security and privacy. Version 20150714 includes updates to the distribution’s core software.

Nick Mathewson published proposal 248 , which offers a migration path for “finally removing our old Ed25519 keys”.

Following the recent outage of meek-azure, David Fifield published a workaround for those who want to use this backend.

The Tails team is planning a sprint in November, possibly face-to-face, focusing on porting Tails to the current stable release of Debian, Jessie. “If you want to join the fun, let me know. If you’re interested in having a face-to-face sprint to work on this in November, let me know. If these dates don’t work for you, let me know”, wrote intrigeri.

The Intercept’s Micah Lee published a detailed beginner’s guide to secure online chat, including how to configure your chat client to use Tor.

For those who wish the modern world looked more like “Johnny Mnemonic” than “CITIZENFOUR”: you can hear Keanu Reeves narrating an unexpectedly soothing animation about the “Deep Web” and Tor onion services as part of Alex Winter’s upcoming documentary film on the subject.


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!

Jul 21, 2015

The Tor Project is continuing its world-wide search for our new Executive Director. We need your help to find this person, whether they work for a nonprofit organization, for a tech company, at a university, for an open software project, or somewhere else entirely. We are open to candidates from lots of different backgrounds.

Here's a link to our original blog post with many more details, including how to submit candidates: Tor Project Launches Worldwide Search for a New Executive Director

An excerpt:

"The Tor Project, one of the world’s strongest advocates for privacy and anonymous, open communications is currently seeking an experienced Executive Director to lead the organization. The new Executive Director will spearhead key initiatives to make the organization even more robust in its work to advance human rights and freedoms by creating and deploying anonymity and privacy technologies, advancing their scientific and popular understanding, and encouraging their use."

Please take a moment to consider whether you know a candidate, likely or unlikely, who might be a great fit for this position.

Thanks!

Jul 15, 2015

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

Caspar Bowden

Caspar Bowden, a leading advocate for many years in the field of civil liberties, and a member of the Tor Project, Inc.’s board of directors, has died after a short illness. As the Tor Project wrote in a statement, Caspar “was a passionate supporter of universal human rights, including the right to privacy”: “The world has lost a voice of tremendous moral courage.”

A Caspar Bowden Legacy Fund has been established “to promote advocacy for privacy as a universal human right and privacy enhancing technologies as one means to protect it”, in accordance with Caspar’s request “that we work to ensure equal protection regardless of nationality”. If you would like to make a contribution to this fund in Caspar’s memory, please see the web page for further details.

The Tor Project launches its search for a new Executive Director

Following the departure of long-time Executive Director Andrew Lewman earlier this year, the Tor Project, Inc. has opened a world-wide search for its new Executive Director. As Wendy Seltzer, a member of the board of directors, writes: “We have engaged The Wentworth Company to help us with the search process, and invite the broader Tor community and friends to share the job posting among your networks. If you are or know a great leader with a passion for anonymous communication and free software, please contact Judy Tabak at Wentworth (judytabak at wentco.com, other contact details in the posting) for more information or to be considered for the job.”

Tor 0.2.6.10 is out

Nick Mathewson put out a new release in the current Tor stable series. Version 0.2.6.10 contains a fix for a regression introduced in 0.2.6.3-alpha that made it difficult for clients to access onion services under certain circumstances — for example, if a hidden service restarts after a client connects, the same client would have been unable to connect again until the next hour. This version also “bulletproofs the cryptography init process, and fixes a bug when using the sandbox code with some older versions of Linux”.

“Everyone running an older version, especially an older version of 0.2.6, should upgrade”, writes Nick. Source code is downloadable from the distribution directory; packages will become available as their packagers package them.

New onion service-related proposals

A gathering of experts in Tor onion service research and development resulted (among other things) in two new Tor proposals for improving the anonymity and efficiency of services hosted inside the Tor network.

John Brooks and George Kadianakis expanded John’s earlier suggestion that the roles of “hidden service directory” and “introduction point” could be merged in the next generation of onion services, into what is now proposal 246. This innovation would simplify the relevant code, reduce load on the network, and limit the number of relays that can observe the service’s activity or serve as a fingerprint for an observer.

George also wrote up draft proposal 247, which tries to prevent “guard discovery attacks” (where an adversary is able to work out which Tor relay is being contacted directly by the target client, thereby allowing them to attack that relay itself and deanonymize the client) by making the attack significantly more costly to perform, using “vanguards”. By enabling a Tor configuration option, the service operator could pin the second and third hops (the “vanguards” in question) of their circuits for a longer period. A would-be attacker is then forced to carry out “a Sybil attack and two coercion attacks” before succeeding, as opposed to the current situation “where the Sybil attack is trivial to pull off, and only a single coercion attack is required”. “I consider this issue very important and any feedback is greatly appreciated”, wrote George.

This is privacy development at the most advanced level, and the waters are very much uncharted: there may be major design flaws, improvements, and counter-arguments lurking up ahead. If this is an area in which you feel you have a contribution to make, by all means take a look at the proposals, and then pitch in on the tor-dev mailing list!

ExoneraTor gets an update

The ExoneraTor service lets you use historical Tor network data to quickly determine whether or not a particular IP address was being used by a public Tor relay on a given date. This is useful if, for example, you’re the administrator of a web service that received malicious traffic on that date, and you want to find out if the IP address will be useful to your investigation of the problem.

After much discussion and feedback on the tor-relays list, Karsten Loesing and Julius Mittenzwei have updated ExoneraTor to offer a simpler, more intuitive service without unnecessary details that might confuse a non-specialist. Searches are now restricted to full days, rather than precise timestamps, to avoid most issues relating to timezone differences (ExoneraTor’s results are given in UTC, and searchers might forget to make adjustments for their local timezone); the form allowing searchers to check whether a relay permitted exit traffic to a target address and port has been replaced by an “Exit” column indicating whether or not any exit traffic was allowed by that relay, again for the sake of simplicity; and the overall look of the service has been streamlined, with clearer, non-technical explanations of Tor and Exonerator, and a translation into German (with more languages planned).

“Please give it a try, including the tricky edge cases where you expect it to break”, wrote Karsten. “And if you have any further feedback,” please send it to the tor-relays mailing list.

The Vegas plan continues to roll out

The “Vegas plan” — a reorganization of Tor’s active contributors into a more focused team-based structure, named after the fair city in which it was developed — continues to roll out, with the Measurement, Community, Networks, and Applications teams holding their first or second IRC meetings this week. Isabela Bagueros, Tor’s project manager, writes: “Keep an eye out for teams’ updates, and for things that can be done better; feedback will be key for making this successful, and that is why we will have a check-in during our next dev meeting. So follow up, participate, bring feedback!”

If you aren’t already working with one of the new teams, and feel you should be, please check in on IRC or the mailing lists, and someone will help direct you to the right place.

Miscellaneous news

The upcoming IETF Meeting in Prague will have a DNS Operations meeting on 20th July that will discuss both the draft proposal to reserve .onion as a special-use domain suffix (about which Tor Weekly News has written before), and other proposals for related projects like I2P and Gnunet. If you're going to Prague, consider attending this meeting and humming in support of reserving .onion and these other domains!

After a hiatus in activity on the tor-mirrors list, Sebastian Hahn updated the file used to build the directory of mirrors on the Tor Project website with changes made in the last few months. “If you notice any unexpected entries or think you should be on the list but aren’t, I’ll check what the problem is.”


This issue of Tor Weekly News has been assembled by Karsten Loesing, Tom Ritter, Wendy Seltzer, Isabela Bagueros, 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!

Jul 12, 2015

Hi, all! There's a new stable Tor release out, and source code is now available on the website. If you build Tor from source code, you'll want to upgrade. Otherwise, packages should be available reasonably soon.

Remember to check signatures! (See the FAQ for information how)

Tor version 0.2.6.10 fixes some significant stability and hidden service client bugs, bulletproofs the cryptography init process, and fixes a bug when using the sandbox code with some older versions of Linux. Everyone running an older version, especially an older version of 0.2.6, should upgrade.

Changes in version 0.2.6.10 - 2015-07-12

  • Major bugfixes (hidden service clients, stability):
    • 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 0.2.6.3-alpha.
  • Major bugfixes (stability):
    • Stop crashing with an assertion failure when parsing certain kinds of malformed or truncated microdescriptors. Fixes bug 16400; bugfix on 0.2.6.1-alpha. 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 0.1.0.1-rc.

 

  • Minor features (geoip):
    • Update geoip to the June 3 2015 Maxmind GeoLite2 Country database.
    • Update geoip6 to the June 3 2015 Maxmind GeoLite2 Country database.
  • Minor bugfixes (crypto error-handling):
    • 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 0.2.5.2-alpha, introduced when implementing ticket 4900. Patch by "teor".
  • Minor bugfixes (Linux seccomp2 sandbox):
    • Allow pipe() and pipe2() syscalls in the seccomp2 sandbox: we need these when eventfd2() support is missing. Fixes bug 16363; bugfix on 0.2.6.3-alpha. Patch from "teor".

Jul 10, 2015

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

Tails 1.4.1 is out

The Tails team announced version 1.4.1 of the anonymous live operating system. Most notable in this release is the fix of automatic upgrades in Windows Camouflage mode, and plugging a hole in Tor Browser’s AppArmor sandbox that previously allowed it to access the list of recently-used files.

For a full list of changes, see the team’s announcement. This release contains important security updates, so head to the download page (or the automatic upgrader) as soon as possible.

Tor Browser 4.5.3 and 5.0a3 are out

The Tor Browser team put out new releases in both the stable and alpha series of the secure, private web browser. Tor Browser 4.5.3 contains updates to Firefox, OpenSSL, NoScript, and Torbutton; it also fixes a crash triggered by .svg files when the security slider was set to “High”, and backports a Tor patch that allows domain names containing underscores (a practice generally discouraged) to resolve properly. For example, users should now be able to view the website of the New York Times without problems.

Tor Browser 5.0a3, meanwhile, is the first release to be based on Firefox 38 ESR. “For this release, we performed a thorough network and feature review of Firefox 38, and fixed the most pressing privacy issues, as well as all Tor proxy safety issues that we discovered during the audit”, wrote Georg Koppen. Changes to the toolchain used to build the browser mean “we are […] especially interested in feedback if there are stability issues or broken Tor Browser bundles due to these toolchain upgrades.

These are important security releases, and you should upgrade to the new version in whichever series you prefer. Head to the download page to get your first copy of Tor Browser, or use the in-browser updater.

Tor unaffected by new OpenSSL security issue

A few days ago, the team behind the essential Internet encryption toolkit OpenSSL announced that a security issue classified as “high” would shortly be disclosed and fixed, leading to concern that another Heartbleed was on the cards. In the event, the now-disclosed CVE-2015-1793 vulnerability does not appear to affect either the Tor daemon or Tor Browser, as Nick Mathewson explained. However, you should still upgrade your OpenSSL as soon as possible, in order to protect the other software you use which may be vulnerable.

OVH is the largest and fastest-growing AS on the Tor network

nusenu observed that the hosting company OVH is both the largest autonomous system on the Tor network by number of relays, and the fastest-growing. While it’s no bad thing to have multiple relays located on the same network, it becomes a problem if any one entity (or someone who watches them closely enough) is able to observe too large a fraction of Tor traffic — they would then be in a position to harm the anonymity of Tor users.

This is what is meant by “diversity” on the Tor network. If you’re considering running a Tor relay, then as nusenu says, “choose non-top 10 ASes when adding relays (10 is an arbitrary number)”. See nusenu’s post for more information on how to select a hosting location for a stronger and more diverse Tor network.

More monthly status reports for June 2015

The wave of regular monthly reports from Tor project members for the month of June continued, with reports from Leiah Jansen (working on graphic design and branding), Georg Koppen (developing Tor Browser), Isabela Bagueros (overall project management), Sukhbir Singh (developing Tor Messenger), Arlo Breault (also working on Tor Messenger, as well as Tor Check), Colin Childs (carrying out support, localization, and outreach), and Juha Nurmi (working on onion service indexing).

Donncha O’Cearbhaill sent his third Tor Summer of Privacy status report with updates about the OnionBalance onion service load-balancing tool, while Jesse Victors did the same for the DNS-like Onion Naming System, and Israel Leiva submitted a status update for the GetTor alternative software distributor, which is also being expanded as part of TSoP, as explained in Israel’s re-introduction of the project. Cristobal Leiva also introduced his TSoP project, a web-based status dashboard for Tor relay operators

Miscellaneous news

David Fifield published the regular summary of costs incurred by the infrastructure for the meek pluggable transport over the past month. “The rate limiting of meek-google and meek-amazon has been partially effective in bringing costs down. […] meek-azure bandwidth use continues to increase, up 17% compared to the previous month. Keep in mind that our grant expires in October, so you should not count on it continuing to work after that.”

Following Donncha O’Cearbhaill’s 0.0.1 alpha release of OnionBalance, s7r called for help putting it to the test on a running onion service. One week on, there have been four million hits on the service, with hardly a murmur of complaint from OnionBalance or the service it is handling: “the same instances are running since service first started, no reboot or application restart”. See s7r’s post for more numbers.


This issue of Tor Weekly News has been assembled by the Tails team, Karsten Loesing, teor, 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!

Jul 07, 2015

A few weeks ago, Hacking Team was bragging publicly about a Tor Browser exploit. We've learned some details of their proposed attack from a leaked powerpoint presentation that was part of the Hacking Team dump.

The good news is that they don't appear to have any exploit on Tor or on Tor Browser. The other good news is that their proposed attack doesn't scale well. They need to put malicious hardware on the local network of their target user, which requires choosing their target, locating her, and then arranging for the hardware to arrive in the right place. So it's not really practical to launch the attack on many Tor users at once.

But they actually don't need an exploit on Tor or Tor Browser. Here's the proposed attack in a nutshell:

1) Pick a target user (say, you), figure out how you connect to the Internet, and install their attacking hardware on your local network (e.g. inside your ISP).

2) Wait for you to browse the web without Tor Browser, i.e. with some other browser like Firefox or Chrome or Safari, and then insert some sort of exploit into one of the web pages you receive (maybe the Flash 0-day we learned about from the same documents, or maybe some other exploit).

3) Once they've taken control of your computer, they configure your Tor Browser to use a socks proxy on a remote computer that they control. In effect, rather than using the Tor client that's part of Tor Browser, you'll be using their remote Tor client, so they get to intercept and watch your traffic before it enters the Tor network.

You have to stop them at step two, because once they've broken into your computer, they have many options for attacking you from there.

Their proposed attack requires Hacking Team (or your government) to already have you in their sights. This is not mass surveillance — this is very targeted surveillance.

Another answer is to run a system like Tails, which avoids interacting with any local resources. In this case there should be no opportunity to insert an exploit from the local network. But that's still not a complete solution: some coffeeshops, hotels, etc will demand that you interact with their local login page before you can access the Internet. Tails includes what they call their 'unsafe' browser for these situations, and you're at risk during that brief period when you use it.

Ultimately, security here comes down to having safer browsers. We continue to work on ways to make Tor Browser more resilient against attacks, but the key point here is that they'll go after the weakest link on your system — and at least in the scenarios they describe, Tor Browser isn't the weakest link.

As a final point, note that this is just a powerpoint deck (probably a funding pitch), and we've found no indication yet that they ever followed through on their idea.

We'll update you with more information if we learn anything further. Stay safe out there!