Blogs

The FBI's Quiet Plan to Begin Mass Hacking

Senator Ron Wyden delivered a speech on the floor of the Senate on Thursday calling for passage of a bill that would annul new rules for judges. These rules will give the FBI authority to hack millions of people's computers with a single search warrant, regardless of where the device is located.

The Stop Mass Hacking Act (S. 2952, H.R. 5321), which has bipartisan support, is composed of a single sentence:

"To prevent the proposed amendments to rule 41 
of the Federal Rules of Criminal Procedure from taking effect."

Wyden's bill attempts to stop the upcoming changes to Rule 41, set to take effect in less than 90 days.

The changes to Rule 41 would allow judges to grant warrants to search and seize electronic media located outside of their home districts when the location of the information is “concealed through technological means."

For instance, when a person is using Tor.

The broad search warrants allowable under these new rules will apply to people using Tor in any country—even if they are journalists, members of a legislature, or human rights activists. The FBI will be permitted to hack into a person’s computer or phone remotely and to search through and remove their data. The FBI will be able to introduce malware into computers. It will create vulnerabilities that will leave users exposed.

To quote a tweet from Daniel Shuman of the NGO Demand Progress, "Even if you like mass FBI hacking, shouldn't the Senate hold a hearing first before it automatically becomes law?"

We are at a critical point in the United States regarding surveillance law. Some public officials, like those at the US Department of Justice (the FBI is a department of DOJ), understand very well how surveillance technology works and the implications of the Rule 41 changes. But the judges who must approve these warrants under the new rules vary widely in their technical expertise and understanding of how these decisions affect the larger Constitutional issues of search and seizure. Rule 41 will allow savvy law enforcement officials to seek those judges who don't yet understand the tech.

Similarly, there are many members of Congress who don't yet understand either the technology or its impact on democratic institutions and values. Some understand that Tor and encryption are currently used by politicians, judges, and even the FBI to keep their communications private--but others do not. Some—but not all—know that privacy tools like Tor can help enforce the separation of powers by preventing one branch of government from spying on another. Some know that a back door for one good guy is eventually a back door for multiple bad guys. Many others do not.

So some US officials can take advantage of this ignorance in order to expand their power. And since the FBI works for the Department of Justice, and the Department of Justice works for the White House, Rule 41 gives new surveillance power to the Administrative branch of US government. New power over millions of people--that Congress never discussed or approved.

Why go through Congress, the reasoning goes, and risk public exposure, debate, and possible defeat, when law enforcement can tweak a rulebook and get the same new hacking power?

If you care about FBI mass hacking, urge Congress to pass the Stop Mass Hacking bill on social media with the hashtag #SMHAct (one of the better legislative hashtags).

If you are an American citizen, there is much more you can do. Here is a seemingly minor thing--but one that can have great impact. Call and leave a message with the Washington, DC, office of the US Senator from your state. Senators actually count these calls, and they influence their decisions--Perhaps they don't want to be voted out of office by the constituents they ignored.

Here is a list of Senators' phone numbers (calling is much more effective than email for this purpose): http://www.senate.gov/general/contact_information/senators_cfm.cfm?OrderBy=state

Your call or voicemail can be very simple:

"My name is _____, I am Senator ____'s constituent in the state of ___, and I support the "Stop Mass Hacking Act." I ask Senator _____ to support The Stop Mass Hacking Act also and that it be considered during this work period. Thank you.”

You can also leave a thank you message with Senator Wyden's office--This gives Wyden more ballast to encourage his colleagues to support the bill).

If you make those calls or leave voicemails and you're on Twitter, tweet that you called your Senator using their Twitter handle and the #SMHAct hashtag. This amplifies the power of the phone call.

The Stop Mass Hacking Act has bipartisan support. Senator Steve Daines (R-Montana), along with Senator Rand Paul (R-Kentucky) Senators Tammy Baldwin (D-Wisconsin) and Jon Tester (D-Montana) are original co-sponsors of the Senate bill.

People listen to the Tor community on issues of anonymity technology. But the threat to anonymity can be just as destructive when it comes because of a small rule change--a bureaucratic sleight of hand---as when it comes through a attack on our software by a state intelligence agency. As Tor users, our threat model includes both, so our response as a community must also include both.

UPDATE: Phoning is by far most important. Then you can tweet to your Senator.

The Twitter accounts for US Senators are here: http://www.socialseer.com/resources/us-senator-twitter-accounts/ #SMHAct

-----
H.R.5321: https://www.congress.gov/bill/114th-congress/house-bill/5321
S.2952: https://www.congress.gov/bill/114th-congress/senate-bill/2952

Tor Messenger 0.2.0b2 is released

We are pleased to announce another public beta release of Tor Messenger. This release features a secure automatic updater and important security fixes to Instantbird. All users are highly encouraged to upgrade.

Secure Updater

This is the first release that contains ported patches from Tor Browser to securely update the application (#14388). Moving forward, Tor Messenger will prompt you when a new release is available, automatically download the update over Tor, and apply it upon restart. Keeping Tor Messenger up-to-date should now be seamless, painless, and secure.

OS X Profile Directory

In previous releases, Tor Messenger stored its profile directory inside the application bundle. This was a result of the Tor Messenger team building on the work done for Tor Browser. While normally straightforward, this caused some trouble with Mac users who said that there's a common expectation to be able to copy extracted applications to someone else's computer. This could lead to them unknowingly transferring accounts and OTR keys.

Tor Browser has since switched courses and, in the 6.0 series, it now stores its profile in ~/Library/Application\ Support/TorBrowser-Data (#13252). With that change, we can now follow suit and store the Tor Messenger profile in ~/Library/Application\ Support/TorMessenger-Data (#13861). However, this should only be case when the application is placed in /Applications. Otherwise, the profile is stored beside the application bundle.

Windows and OS X bundles are now signed

In past releases, users may have seen cumbersome and scary warnings that the Tor Messenger application is not signed by a known developer (#17452), and may not be trustworthy. We are now signing the Windows and OS X bundles with the Tor Browser developer keys.

Google Summer of Code (GSoC)

This summer, the Tor Messenger team participated in Google's Summer of Code program, mentoring a project by Vu Quoc Huy, titled "CONIKS for Tor Messenger" (#17961). CONIKS is a key management and verification system for end-to-end secure communication services, using a model called key transparency. In this model, our users' keys are managed in a publicly (and cryptographically) auditable yet privacy preserving key directory in order to provide stronger security and better usability.

Although we hope to have a prototype deployed for testing in the near future, much work remains before we can consider turning it on in production. So far, we've produced an implementation of a CONIKS keyserver and several patches to Tor Messenger to support the additional logic and interface. This has been a collaboration between researchers Marcela Melara (CONIKS' project lead) from Princeton, Ismail Khoffi from EPFL, our student Huy, and the Tor Messenger team. We'd like to thank all who participated.

Before upgrading, back up your OTR keys

You will need to back up your OTR keys to preserve them across this upgrade. Please see the steps to back them up, or consider simply generating new ones after upgrading.

Note that with the advent of the secure updater, this step will no longer be necessary in future releases. All profile data will be preserved upon automatic update, including accounts and OTR keys (#13861).

Downloads

Please note that Tor Messenger is still in beta. The purpose of this release is to help test the application and provide feedback. At-risk users should not depend on it for their privacy and safety.

Linux (32-bit)

Linux (64-bit)

Windows

OS X (Mac)

sha256sums.txt
sha256sums.txt.asc

The sha256sums.txt file containing hashes of the bundles is signed with the key 0xB01C8B006DA77FAA (fingerprint: E4AC D397 5427 A5BA 8450 A1BE B01C 8B00 6DA7 7FAA). Please verify the fingerprint from the signing keys page on Tor Project's website.

Changelog

Here is the complete changelog since v0.1.0b6:

Tor Messenger 0.2.0b2 -- September 06, 2016

  • Mac
    • Bug 19269: Fix OS X file permissions
    • Fix OS X profile when application is not placed in /Applications

Tor Messenger 0.2.0b1 -- September 02, 2016

  • All Platforms
    • Use the THUNDERBIRD_45_3_0_RELEASE tag on mozilla-esr45
    • Use the THUNDERBIRD_45_3_0_RELEASE tag on comm-esr45
    • Bug 19053: Display plaintext in notifications
    • Bug 17363: Remove redundant Tor Messenger folders
    • Bug 14388: Secure automatic updates for Tor Messenger
    • Bug 13861: Preserve user profiles after updates
    • Update libgcrypt to 1.6.6 for CVE-2016-6316
    • Update ctypes-otr to 0.0.2
  • Linux
    • Bug 18634: Switch to building Tor Messenger on Debian Wheezy
  • Mac
    • Bug 13861: Profile directory stored in ~/Library/Application\ Support/TorMessenger-Data
    • Bug 17460: Add graphics for OS X drag and drop to Applications
    • Bug 17648: Fix update service error in error console

A New Bridge Authority

After ten years of volunteer maintenance of Tonga, Tor's bridge Authority—a piece of critical infrastructure within the Tor network—our colleague and friend, Lucky Green, a long time cypherpunk, and free speech and privacy advocate, has decided to step down from this role. Tonga's cryptographic keys will be destroyed this week. We are incredibly thankful to Lucky for all his support and selfless labour in maintaining a key component of our censorship circumvention efforts, grateful for the years we have spent working with him, and very sorry to see him go.

The Bridge Authority is a simple but essential piece of the Tor Network. Unlike the other directory authorities, the Bridge Authority does not get a vote in Tor's consensus protocol. Instead, it serves to aggregate relay descriptors which Tor Bridges send to it, checking their cryptographic validity and testing that the Bridges' ORPorts within these descriptors are reachable. It then sends these descriptors to BridgeDB, which does all the deduplication, cryptographic signature verification (again), stability calculations, pluggable transport argument validation, assignment into the hashring of each Bridge distribution mechanism, and finally distributing the Bridges to Tor clients.



Number of bridges reported by both Tonga and Bifröst during the bridge authority transition period. Graph by Karsten Loesing.

This transition does not affect Tor users, regardless of whether or not Bridges are used to connect to the Tor network. However, it is extremely important that relay operators running Bridges upgrade to tor-0.2.8.7 or tor-0.2.9.2.-alpha, which contains a patch to replace Tonga with the new Bridge Authority. Bridges which do not upgrade will cease to be distributed to new clients; however, clients which have connected to your Bridge previously will still be able to connect (at least until your Bridge's IP address, port, or fingerprint changes).


"The same thing, but made of rainbows and on fire."

As a replacement for Tonga, I am happy to announce that Greenhost has donated hardware and hosting for the new Bridge Authority, Bifröst. Bifröst is a Norse mythological bridge that connects Midgard, the mortal realm, and Asgard, the realm of the gods, and is described in the poem Grímnismál within the Poetic Edda as a burning bridge, constructed out of a rainbow whose end lies upon Himinbjorg, or "Heaven's cliffs." The name was suggested by both our colleagues Alison Macrina of the Library Freedom Project and Moritz Bartl of Torservers.net. Despite the personal temptation to follow Nick Mathewson's suggestion to christen it after that iconic symbol of my home, I could not help but name it Bifröst, because why go with some boring normal thing, when you could have the same thing, but made of rainbows and on fire. RAINBOWS. FIRE. Clear choice.

The Tor Project is incredibly thankful to Greenhost for their generous donation of hardware, hosting, and bandwidth. In particular, I am thankful to my colleagues at Greenhost, Sacha von Geffen and Jurre van Bergen, for all the work they put into the organisation, collaboration, and technical efforts in setting the server up quickly. Working with Greenhost, as always, is a pleasure, and I would give my highest recommendations for Greenhost to those seeking an ethical, friendly, and experienced hosting provider.


Future Research and Hacking

Moving forward, there are several improvements to these systems which could be made, some requiring further research.

  1. We currently don't have any mechanism for testing the bandwidth capacity of bridge relays. Additional design complications may arise when Bridges have their own Guard relays (#7144), e.g. causing fast Bridges which select slower Guards to not utilize their full capacity. This might be navigated by adding support for bridges to do a self-bandwidth test before selecting a guard node.

  2. We also don't currently have anything that tests the reachability of the address/port for any of a Bridge's pluggable transports. Our previous attempts at a distributed/automated Bridge reachability testing system lead me to believe that there is no way to both reliably and securely, i.e., without literally burning the Bridge by attracting a censor's attention to it, test reachability in a distributed manner. Add on top a game of Russian roulette by mixing in N different pluggable transports with varying indistinguishability, authentication, and security properties merely compounds the issue, adding to the likelihood that the secrecy of the best transport a Bridge provides is reduced to that of its worst. That said, thorough analysis of the risks of a centralised system should be made, and there are likely other alternatives. For example, one might attempt to build a system which heuristically crowdsources this information from clients.

  3. There's no legitimate reason to have the Bridge Authority and BridgeDB be separate systems. It would make more sense to break apart the components into those which
    • receive descriptors
    • conduct reachability tests
    • archive all descriptors
    • access archived descriptors for which Bridges may currently be distributed to clients
    • distribute Bridges to clients in some manner.

  4. Decentralise the Bridge Authority/BridgeDB systems without simply turning a single point-of-failure into multiple points-of-failure.


Researchers and hackers interested in these problems are welcome and encouraged to contribute. If these problems interest you (or your sufficiently bright, self-directed, and motivated students!), please feel encouraged to contact me and/or our Research Director, Roger Dingledine to discuss ideas and projects moving forward.

Tor 0.2.8.7 is released, with important fixes

Tor 0.2.8.7 fixes an important bug related to the ReachableAddresses option in 0.2.8.6, and replaces a retiring bridge authority. Everyone who sets the ReachableAddresses option, and all bridges, are strongly encouraged to upgrade.

You can download the source from the Tor website. Packages should be available over the next week or so.

Below is a list of changes since 0.2.8.6.

Changes in version 0.2.8.7 - 2016-08-24

  • Directory authority changes:
    • The "Tonga" bridge authority has been retired; the new bridge authority is "Bifroest". Closes tickets 19728 and 19690.
  • Major bugfixes (client, security):
    • Only use the ReachableAddresses option to restrict the first hop in a path. In earlier versions of 0.2.8.x, it would apply to every hop in the path, with a possible degradation in anonymity for anyone using an uncommon ReachableAddress setting. Fixes bug 19973; bugfix on 0.2.8.2-alpha.
  • Minor features (geoip):
    • Update geoip and geoip6 to the August 2 2016 Maxmind GeoLite2 Country database.
  • Minor bugfixes (compilation):
    • Remove an inappropriate "inline" in tortls.c that was causing warnings on older versions of GCC. Fixes bug 19903; bugfix on 0.2.8.1-alpha.
  • Minor bugfixes (fallback directories):
    • Avoid logging a NULL string pointer when loading fallback directory information. Fixes bug 19947; bugfix on 0.2.4.7-alpha and 0.2.8.1-alpha. Report and patch by "rubiate".

Tor 0.2.9.2-alpha is released, with important fixes

Tor 0.2.9.2-alpha continues development of the 0.2.9 series with several new features and bugfixes. It also includes an important authority update and an important bugfix from 0.2.8.7. Everyone who sets the ReachableAddresses option, and all bridges, are strongly encouraged to upgrade to 0.2.8.7, or to 0.2.9.2-alpha.

You can download the source from the usual place on the website.
Packages should be available over the next several days. Remember
to check the signatures!

Please note: This is an alpha release. You should only try this one if you are interested in tracking Tor development, testing new features, making sure that Tor still builds on unusual platforms, or generally trying to hunt down bugs. If you want a stable experience, please stick to the stable releases.

Below are the changes since 0.2.9.1-alpha.

Changes in version 0.2.9.2-alpha - 2016-08-24

  • Directory authority changes (also in 0.2.8.7):
    • The "Tonga" bridge authority has been retired; the new bridge authority is "Bifroest". Closes tickets 19728 and 19690.
  • Major bugfixes (client, security, also in 0.2.8.7):
    • Only use the ReachableAddresses option to restrict the first hop in a path. In earlier versions of 0.2.8.x, it would apply to every hop in the path, with a possible degradation in anonymity for anyone using an uncommon ReachableAddress setting. Fixes bug 19973; bugfix on 0.2.8.2-alpha.

  read more »

Tor Browser 6.0.4 is released

Tor Browser 6.0.4 is now available from the Tor Browser Project page and also from our distribution directory.

This release finally brings Tor Browser users the latest Tor stable, 0.2.8.6, and avoids pinging Mozilla's servers for system extensions.

Pinging Mozilla's servers was responsible for users getting an extension into their Tor Browser that resulted in annoying and confusing "Your Firefox is out of date" notifications on start-up (bug 19890). Thanks to Mozilla engineers, who fixed that issue as quickly as possible on their side, the extension is not shipped to Tor Browser users anymore since August 11 13:00 UTC. This takes care of getting the add-on removed as well in case it got installed into Tor Browser (as does the fix we ship in Tor Browser 6.0.4) which should have happened/is happening during the next extension update ping. For further information see the discussion in our bug tracker.

Users that are on the alpha channel or are using the hardened Tor Browser were not affected. The same goes for Tails users as far as we know.

The full changelog since Tor Browser 6.0.3 is:

Tor Browser 6.0.4 -- August 16

  • All Platforms
    • Update Tor to 0.2.8.6
    • Update NoScript to 2.9.0.14
    • Bug 19890: Disable installation of system addons

The Tor Social Contract

At The Tor Project, we make tools that help promote and protect the essential human rights of people everywhere. We have a set of guiding principles that make that possible, but for a long time, those principles were more or less unspoken. In order to ensure that project members build a Tor that reflects the commitment to our ideals, we've taken a cue from our friends at Debian and written the Tor Social Contract -- the set of principles that show who we are and why we make Tor.

Our social contract is a set of behaviors and goals: not just the promised results we want for our community, but the ways we seek to achieve them. We want to grow Tor by supporting and advancing these guidelines in the time we are working on Tor, while taking care not to undermine them in the rest of our time.

The principles can also be used to help recognize when people's actions or intents are hurting Tor. Some of these principles are established norms; things we've been doing every day for a long time; while others are more aspirational -- but all of them are values we want to live in public, and we hope they will make our future choices easier and more open. This social contract is one of several documents that define our community standards, so if you're looking for things that aren't here (e.g. something that might be in a code of conduct) bear in mind that they might exist, in a different document.

Social goals can be complex. If there is ever tension in the application of the following principles, we will always strive to place highest priority on the safety and freedom of any who would use the fruits of our endeavors. The social contract can also help us work through such tensions -- for example, there are times when we might have a need to use tools that are not completely open (contradicting point 2) but opening them would undermine our users' safety (contradicting point 6). Using such a tool should be weighed against how much it's needed to make our technologies usable (point 1). And if we do use such a tool, we must be honest about its capabilities and limits (point 5).

Tor is not just software, but a labor of love produced by an international community of people devoted to human rights. This social contract is a promise from our internal community to the rest of the world, affirming our commitment to our beliefs. We are excited to present it to you.

1. We advance human rights by creating and deploying usable anonymity and privacy technologies.

We believe that privacy, the free exchange of ideas, and access to information are essential to free societies. Through our community standards and the code we write, we provide tools that help all people protect and advance these rights.

2. Open and transparent research and tools are key to our success.

We are committed to transparency; therefore, everything we release is open and our development happens in the open. Whenever feasible, we will continue to make our source code, binaries, and claims about them open to independent verification. In the extremely rare cases where open development would undermine the security of our users, we will be especially vigilant in our peer review by project members.

3. Our tools are free to access, use, adapt, and distribute.

The more diverse our users, the less is implied about any person by simply being a Tor user. This diversity is a fundamental goal and we aim to create tools and services anyone can access and use. Someone's ability to pay for these tools or services should not be a determining factor in their ability to access and use them. Moreover, we do not restrict access to our tools unless access is superceded by our intent to make users more secure.

We expect the code and research we publish will be reviewed and improved by many different people, and that is only possible if everyone has the ability to use, copy, modify, and redistribute this information. We also design, build, and deploy our tools without collecting identifiable information about our users.

4. We make Tor and related technologies ubiquitous through advocacy and education.

We are not just people who build software, but ambassadors for online freedom. We want everybody in the world to understand that their human rights -- particularly their rights to free speech, freedom to access information, and privacy -- can be preserved when they use the Internet. We teach people how and why to use Tor and we are always working to make our tools both more secure and more usable, which is why we use our own tools and listen to user feedback. Our vision of a more free society will not be accomplished simply behind a computer screen, and so in addition to writing good code, we also prioritize community outreach and advocacy.

5. We are honest about the capabilities and limits of Tor and related technologies.

We never intentionally mislead our users nor misrepresent the capabilities of the tools, nor the potential risks associated with using them. Every user should be free to make an informed decision about whether they should use a particular tool and how they should use it. We are responsible for accurately reporting the state of our software, and we work diligently to keep our community informed through our various communication channels.

6. We will never intentionally harm our users.

We take seriously the trust our users have placed in us. Not only will we always do our best to write good code, but it is imperative that we resist any pressure from adversaries who want to harm our users. We will never implement front doors or back doors into our projects. In our commitment to transparency, we are honest when we make errors, and we communicate with our users about our plans to improve.

New alpha release: Tor 0.2.9.1-alpha

Tor 0.2.9.1-alpha is the first alpha release in the 0.2.9 development series. It improves our support for hardened builds and compiler warnings, deploys some critical infrastructure for improvements to hidden services, includes a new timing backend that we hope to use for better support for traffic padding, makes it easier for programmers to log unexpected events, and contains other small improvements to security, correctness, and performance.

You can download the source from the usual place on the website.
Packages should be available over the next several days. Remember
to check the signatures!

Please note: This is an alpha release. You should only try this one if
you are interested in tracking Tor development, testing new features,
making sure that Tor still builds on unusual platforms, or generally
trying to hunt down bugs. If you want a stable experience, please stick to the stable releases.

Below are the changes since 0.2.8.6.

Changes in version 0.2.9.1-alpha - 2016-08-08

  • New system requirements:
    • Tor now requires Libevent version 2.0.10-stable or later. Older versions of Libevent have less efficient backends for several platforms, and lack the DNS code that we use for our server-side DNS support. This implements ticket 19554.
    • Tor now requires zlib version 1.2 or later, for security, efficiency, and (eventually) gzip support. (Back when we started, zlib 1.1 and zlib 1.0 were still found in the wild. 1.2 was released in 2003. We recommend the latest version.)
  • Major features (build, hardening):
    • Tor now builds with -ftrapv by default on compilers that support it. This option detects signed integer overflow (which C forbids), and turns it into a hard-failure. We do not apply this option to code that needs to run in constant time to avoid side-channels; instead, we use -fwrapv in that code. Closes ticket 17983.
    • When --enable-expensive-hardening is selected, stop applying the clang/gcc sanitizers to code that needs to run in constant time. Although we are aware of no introduced side-channels, we are not able to prove that there are none. Related to ticket 17983.

  read more »

Syndicate content Syndicate content