Blogs
Tor 0.2.8.8 is released, with important fixes
Posted September 23rd, 2016 by nickmTor 0.2.8.8 fixes two crash bugs present in previous versions of the 0.2.8.x series. Relays running 0.2.8.x should upgrade, as should users who select public relays as their bridges.
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.8 - 2016-09-23
- Major bugfixes (crash):
- Fix a complicated crash bug that could affect Tor clients configured to use bridges when replacing a networkstatus consensus in which one of their bridges was mentioned. OpenBSD users saw more crashes here, but all platforms were potentially affected. Fixes bug 20103; bugfix on 0.2.8.2-alpha.
- Major bugfixes (relay, OOM handler):
- Fix a timing-dependent assertion failure that could occur when we tried to flush from a circuit after having freed its cells because of an out-of-memory condition. Fixes bug 20203; bugfix on 0.2.8.1-alpha. Thanks to "cypherpunks" for help diagnosing this one.
- Minor feature (fallback directories):
- Remove broken fallbacks from the hard-coded fallback directory list. Closes ticket 20190; patch by teor.
- Minor features (geoip):
- Update geoip and geoip6 to the September 6 2016 Maxmind GeoLite2 Country database.
Tor 0.2.9.3-alpha is released, with important fixes
Posted September 23rd, 2016 by nickmTor 0.2.9.3-alpha adds improved support for entities that want to make high-performance services available through the Tor .onion mechanism without themselves receiving anonymity as they host those services. It also tries harder to ensure that all steps on a circuit are using the strongest crypto possible, strengthens some TLS properties, and resolves several bugs -- including a pair of crash bugs from the 0.2.8 series. Anybody running an earlier version of 0.2.9.x should upgrade.
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.2-alpha.
Changes in version 0.2.9.3-alpha - 2016-09-23
- Major bugfixes (crash, also in 0.2.8.8):
- Fix a complicated crash bug that could affect Tor clients configured to use bridges when replacing a networkstatus consensus in which one of their bridges was mentioned. OpenBSD users saw more crashes here, but all platforms were potentially affected. Fixes bug 20103; bugfix on 0.2.8.2-alpha.
- Major bugfixes (relay, OOM handler, also in 0.2.8.8):
- Fix a timing-dependent assertion failure that could occur when we tried to flush from a circuit after having freed its cells because of an out-of-memory condition. Fixes bug 20203; bugfix on 0.2.8.1-alpha. Thanks to "cypherpunks" for help diagnosing this one.
Tails 2.6 is out
Posted September 20th, 2016 by tailsThis release fixes many security issues and users should upgrade as soon as possible.
New features
-
We enabled address space layout randomization in the Linux kernel (
kASLR) to improve protection from buffer overflow attacks. -
We installed
rngdto improve the entropy of the random numbers generated on computers that have a hardware random number generator.
Upgrades and changes
-
Upgrade Tor to 0.2.8.7.
-
Upgrade Tor Browser to 6.0.5.
-
Upgrade to Linux 4.6. This should improve the support for newer hardware (graphics, Wi-Fi, etc.)
-
Upgrade Icedove to 45.2.0.
-
Upgrade Tor Birdy to 0.2.0.
-
Upgrade Electrum to 2.6.4.
-
Install firmware for Intel SST sound cards (
firmware-intel-sound). -
Install firmware for Texas Instruments Wi-Fi interfaces (
firmware-ti-connectivity). -
Remove
non-freeAPT repositories. We documented how to configure additional APT repositories using the persistent volume. -
Use a dedicated page as the homepage of Tor Browser so we can customize it for our users.
-
Set up the trigger for RAM erasure on shutdown earlier in the boot process. This should speed up shutdown and make RAM erasure more robust.
Fixed problems
-
Disable the automatic configuration of Icedove when using OAuth.
This should fix the automatic configuration for GMail accounts. (#11536) -
Make the Disable all networking and Tor bridge mode options of Tails Greeter more robust. (#11593)
For more details, read our changelog.
Known issues
- For some users memory wiping fails more often than in Tails 2.5, and for some users it fails less often. Please report any such changes to #11786.
See the list of long-standing issues.
Get Tails 2.6
-
To install, follow our installation instructions.
-
To upgrade, an automatic upgrade is available from 2.5 to 2.6.
If you cannot do an automatic upgrade or if you fail to start after an automatic upgrade, please try to do a manual upgrade.
What's coming up?
Tails 2.7 is scheduled for November 8.
Have a look at our roadmap to see where we are heading to.
We need your help and there are many ways to contribute to Tails (donating is only one of them). Come talk to us!
Support and feedback
For support and feedback, visit the Support section on the Tails website.
Tor Browser 6.5a3-hardened is released
Posted September 20th, 2016 by boklmA new hardened Tor Browser release is available. It can be found in the 6.5a3-hardened distribution directory and on the download page for hardened builds.
This release features important security updates to Firefox including the recently disclosed extension update vulnerability. All users should upgrade as soon as possible.
In addition to the changes from Tor Browser 6.5a3, the creation of incremental MARs for hardened builds is now fixed.
Note: Due to bug 20185 Tor Browser will not work correctly if the path where it is installed is too long. As a workaround you may need to move it to a directory with a shorter path.
- All Platforms
- Update Firefox to 45.4.0esr
- Update Tor to 0.2.9.2-alpha
- Update OpenSSL to 1.0.2h (bug 20095)
- Update Torbutton to 1.9.6.4
- Bug 17334: Move referrer spoofing for .onion domains into tor-browser.git
- Bug 17767: Make "JavaScript disabled" more visible in Security Slider
- Bug 19995: Clear site security settings during New Identity
- Bug 19906: "Maximizing Tor Browser" Notification can exist multiple times
- Bug 19837: Whitelist internal URLs that Firefox requires for media
- Bug 15852: Remove/synchronize Torbutton SOCKS pref logic
- Bug 19733: GETINFO response parser doesn't handle AF_UNIX entries + IPv6
- Bug 14271: Make Torbutton work with Unix Domain Socket option
- Translation updates
- Update Tor Launcher to 0.2.11
- Update HTTPS-Everywhere to 5.2.4
- Update NoScript to 2.9.0.14
- Bug 19851: Fix ASan error by upgrading GCC to 5.4.0
- Bug 17858: Fix creation of incremental MARs for hardened builds
- Bug 14273: Backport patches for Unix Domain Socket support
- Bug 19890: Disable installation of system addons
- Bug 17334: Spoof referrer when leaving a .onion domain
- Bug 20092: Rotate ports for default obfs4 bridges
- Bug 20040: Add update support for unpacked HTTPS Everywhere
- Bug 20118: Don't unpack HTTPS Everywhere anymore
- Bug 19336+19835: Enhance about:tbupdate page
- Build system
Tor Browser 6.5a3 is released
Posted September 20th, 2016 by boklmTor Browser 6.5a3 is now available from the Tor Browser Project page and also from our distribution directory.
This release features important security updates to Firefox including the recently disclosed extension update vulnerability. All users should upgrade as soon as possible.
This release bumps the versions of several of our components: Firefox to 45.4.0esr, Tor to 0.2.9.2-alpha and OpenSSL to 1.0.2h, HTTPS-Everywhere to 5.2.4, NoScript to 2.9.0.14. Additionally we are adding Unix Domain Socket support on Linux and OSX, the about:tbupdate page giving information about the update has been improved, the referrer spoofing for .onion domains has been moved from Torbutton to C++ patches.
Note: Due to bug 20185 Tor Browser on Linux and OS X will not work correctly if the path where it is installed is too long. As a workaround you may need to move it to a directory with a shorter path.
Update (9/22 07:15 UTC): We got reports about updates failing on OS X systems. We are still investigating the problem but this is likely due to a combination of issues. For one we might have introduced a permission problem by trying to get our incremental updates working again. Secondly, unix domain socket paths for the control port that contain spaces are not working. See comment 5 in bug 20210 for a preliminary analysis and workarounds. We are sorry for the inconvenience.
Here is the full changelog since 6.5a2:
- All Platforms
- Update Firefox to 45.4.0esr
- Update Tor to 0.2.9.2-alpha
- Update OpenSSL to 1.0.2h (bug 20095)
- Update Torbutton to 1.9.6.4
- Bug 17334: Move referrer spoofing for .onion domains into tor-browser.git
- Bug 17767: Make "JavaScript disabled" more visible in Security Slider
- Bug 19995: Clear site security settings during New Identity
- Bug 19906: "Maximizing Tor Browser" Notification can exist multiple times
- Bug 19837: Whitelist internal URLs that Firefox requires for media
- Bug 15852: Remove/synchronize Torbutton SOCKS pref logic
- Bug 19733: GETINFO response parser doesn't handle AF_UNIX entries + IPv6
- Bug 14271: Make Torbutton work with Unix Domain Socket option
- Translation updates
- Update Tor Launcher to 0.2.10.1
- Update HTTPS-Everywhere to 5.2.4
- Update NoScript to 2.9.0.14
- Bug 14273: Backport patches for Unix Domain Socket support
- Bug 19890: Disable installation of system addons
- Bug 17334: Spoof referrer when leaving a .onion domain
- Bug 20092: Rotate ports for default obfs4 bridges
- Bug 20040: Add update support for unpacked HTTPS Everywhere
- Bug 20118: Don't unpack HTTPS Everywhere anymore
- Bug 19336+19835: Enhance about:tbupdate page
- Android
- Bug 19706: Store browser data in the app home directory
- Build system
Cooking with Onions: Finding the OnionBalance
Posted September 19th, 2016 by asnHello,
This blog post is the first part of the Cooking with Onions series which aims to highlight various interesting developments on the .onion space. This particular post presents a technique for efficiently scaling busy onion services.
The need for scaling
Onion services have been around for a while. During the past few years, they have been deployed by many serious websites like major media organizations (like the Washington Post), search engines (such as DuckDuckGo) and critical Internet infrastructure (e.g. PGP keyservers). This has been a great opportunity for us, the development team, since our code has been hardened and tested by the sheer volume of clients that use it every day.
This recent widespread usage also gave us greater insights on the various scalability issues that onion service operators face when they try to take their service to the next level. More users means more load to the onion service, and there is only so much that a single machine can handle. The scalability of the onion service protocol has been a topic of interest to us for a while, and recently we've made advancements in this area by releasing a tool called OnionBalance.
So what is OnionBalance?
OnionBalance is software designed and written by Donncha O'Cearbhaill as part of Tor's Summer of Privacy 2015. It allows onion service operators to achieve the property of high availability by allowing multiple machines to handle requests for a single onion service. You can think of it as the onion service equivalent of load balancing using round-robin DNS.
OnionBalance has recently started seeing more and more usage by onion service operators! For example, the Debian project recently started providing onion services for its entire infrastructure, and the whole project is kept in line by OnionBalance.
How OnionBalance works
Consider Alice, an onion operator, who wants to load balance her overloaded onion service using OnionBalance.
She starts by setting up multiple identical instances of that onion service in multiple machines, makes a list of their onion addresses, and passes the list to OnionBalance. OnionBalance then fetches their descriptors, extracts their introduction points, and publishes a "super-descriptor" containing all their introduction points. Alice now passes to her users the onion address that corresponds to the "super-descriptor". Multiple OnionBalance instances can be run with the same configuration to provide redundancy when publishing the super descriptor.
When Bob, a client, wants to visit Alice's onion service, his Tor client will pick a random introduction point out of the super-descriptor and use it to connect to the onion service. That introduction point can correspond to any of the onion service instances, and this way the client load gets spread out.
With OnionBalance, the "super-descriptor" can be published from a different machine to the one serving the onion service content. Your onion service private key can be kept in a more isolated location, reducing the risk of key compromise.
For information on how to set up OnionBalance, please see the following article:
http://onionbalance.readthedocs.io/en/latest/
Conclusion
OnionBalance is a handy tool that allows operators to spread the load of their onion service to multiple machines. It's easy to set up and configure and more people should give it a try.
In the meanwhile, we'll keep ourselves busy coming up with other ways to scale onion services in this brave new world of onions that is coming!
Take care until the next episode :)
Tor Browser 6.0.5 is released
Posted September 16th, 2016 by gkTor Browser 6.0.5 is now available from the Tor Browser Project page and also from our distribution directory.
This release features important security updates to Firefox including the recently disclosed extension update vulnerability. All users should upgrade as soon as possible.
That vulnerability allows an attacker who is able to obtain a valid certificate for addons.mozilla.org to impersonate Mozilla's servers and to deliver a malicious extension update, e.g. for NoScript. This could lead to arbitrary code execution. Moreover, other built-in certificate pinnings are affected as well. Obtaining such a certificate is not an easy task, but it's within reach of powerful adversaries (e.g. nation states).
Thanks to everyone who helped investigating this bug and getting a bugfix release out as fast as possible.
We are currently building the alpha and hardened bundles (6.5a3 and 6.5a3-hardened) that will contain the fix for alpha/hardened channel users. We expect them to get released at the beginning of next week. Until then users are strongly encouraged to use Tor Browser 6.0.5.
Apart from fixing Firefox vulnerabilities this release comes with a new Tor stable version (0.2.8.7), an updated HTTPS-Everywhere (5.2.4), and fixes minor bugs.
Here is the full changelog since Tor Browser 6.0.4:
- All Platforms
- Windows
- Bug 19725: Remove old updater files left on disk after upgrade to 6.x
- Linux
- Bug 19725: Remove old updater files left on disk after upgrade to 6.x
- Android
- Bug 19706: Store browser data in the app home directory
- Build system
- All platforms
- Upgrade Go to 1.4.3
- All platforms
The FBI's Quiet Plan to Begin Mass Hacking
Posted September 12th, 2016 by ailanthusSenator 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
