mikeperry's blog

Mission Improbable: Hardening Android for Security And Privacy

Updates: See the Changes section for a list of changes since initial posting.

After a long wait, the Tor project is happy to announce a refresh of our Tor-enabled Android phone prototype.

This prototype is meant to show a possible direction for Tor on mobile. While I use it myself for my personal communications, it has some rough edges, and installation and update will require familiarity with Linux.

The prototype is also meant to show that it is still possible to replace and modify your mobile phone's operating system while retaining verified boot security - though only just barely. The Android ecosystem is moving very fast, and in this rapid development, we are concerned that the freedom of users to use, study, share, and improve the operating system software on their phones is being threatened. If we lose these freedoms on mobile, we may never get them back. This is especially troubling as mobile access to the Internet becomes the primary form of Internet usage worldwide.

Quick Recap

We are trying to demonstrate that it is possible to build a phone that respects user choice and freedom, vastly reduces vulnerability surface, and sets a direction for the ecosystem with respect to how to meet the needs of high-security users. Obviously this is a large task. Just as with our earlier prototype, we are relying on suggestions and support from the wider community.

Help from the Community

When we released our first prototype, the Android community exceeded our wildest expectations with respect to their excitement and contributions. The comments on our initial blog post were filled with helpful suggestions.

Soon after that post went up, Cédric Jeanneret took my Droidwall scripts and adapted them into the very nice OrWall, which is exactly how we think a Tor-enabled phone should work in general. Users should have full control over what information applications can access on their phones, including Internet access, and have control over how that Internet access happens. OrWall provides the networking component of this access control. It allows the user to choose which apps route through Tor, which route through non-Tor, and which can't access the Internet at all. It also has an option to let a specific Voice over IP app, like Signal, bypass Tor for the UDP voice data channel, while still sending call setup information over Tor.

At around the time that our blog post went up, the Copperhead project began producing hardened builds of Android. The hardening features make it more difficult to exploit Android vulnerabilities, and also provides WiFi MAC address randomization, so that it is no longer trivial to track devices using this information.

Copperhead is also the only Android ROM that supports verified boot, which prevents exploits from modifying the boot, system, recovery, and vendor device partitions. Coppherhead has also extended this protection by preventing system applications from being overridden by Google Play Store apps, or from writing bytecode to writable partitions (where it could be modified and infected). This makes Copperhead an excellent choice for our base system.

The Copperhead Tor Phone Prototype

Upon the foundation of Copperhead, Orbot, Orwall, F-Droid, and other community contributions, we have built an installation process that installs a new Copperhead phone with Orbot, OrWall, SuperUser, Google Play, and MyAppList with a list of recommended apps from F-Droid.

We require SuperUser and OrWall instead of using the VPN APIs because the Android VPN APIs are still not as reliable as a firewall in terms of preventing leaks. Without a firewall-based solution, the VPN can leak at boot, or if Orbot is killed or crashes. Additionally, DNS leaks outside of Tor still occur with the VPN APIs on some systems.

We provide Google Play primarily because Signal still requires it, but also because some users probably also want apps from the Play Store. You do not need a Google account to use Signal, but then you need to download the Signal android package and sideload it manually (via adb install).

The need to install these components to the system partition means that we must re-sign the Copperhead image and updates if we want to keep the ability to have system integrity from Verified Boot.

Thankfully, the Nexus Devices supported by Copperhead allow the use of user-generated keys. The installation process simply takes a Copperhead image, installs our additional apps, and signs it with the new keys.

Systemic Threats to Software Freedom

Unfortunately, not only is Copperhead the only Android rebuild that supports Verified Boot, but the Google Nexus/Pixel hardware is the only Android hardware that allows the user to install their own keys to retain both the ability to modify the device, as well as have the filesystem security provided by verified boot.

This, combined with Google's increasing hostility towards Android as a fully Open Source platform, as well as the difficulty for external entities to keep up with Android's surprise release and opaque development processes, means that the ability for end-users to use, study, share, and improve the Android system are all in great jeopardy.

This all means that the Android platform is effectively moving to a "Look but don't touch" Shared Source model that Microsoft tried in the early 2000s. However, instead of being explicit about this, Google appears to be doing it surreptitiously. It is a very deeply disturbing trend.

It is unfortunate that Google seems to see locking down Android as the only solution to the fragmentation and resulting insecurity of the Android platform. We believe that more transparent development and release processes, along with deals for longer device firmware support from SoC vendors, would go a long way to ensuring that it is easier for good OEM players to stay up to date. Simply moving more components to Google Play, even though it will keep those components up to date, does not solve the systemic problem that there are still no OEM incentives to update the base system. Users of old AOSP base systems will always be vulnerable to library, daemon, and operating system issues. Simply giving them slightly more up to date apps is a bandaid that both reduces freedom and does not solve the root security problems. Moreover, as more components and apps are moved to closed source versions, Google is reducing its ability to resist the demand that backdoors be introduced. It is much harder to backdoor an open source component (especially with reproducible builds and binary transparency) than a closed source one.

If Google Play is to be used as a source of leverage to solve this problem, a far better approach would be to use it as a pressure point to mandate that OEMs keep their base system updated. If they fail to do so, their users will begin to lose Google Play functionality, with proper warning that notifies them that their vendor is not honoring their support agreement. In a more extreme version, the Android SDK itself could have compiled code that degrades app functionality or disables apps entirely when the base system becomes outdated.

Another option would be to change the license of AOSP itself to require that any parties that distribute binaries of the base system must provide updates to all devices for some minimum period of time. That would create a legal avenue for class-action lawsuits or other legal action against OEMs that make "fire and forget" devices that leave their users vulnerable, and endanger the Internet itself.

While extreme, both of these options would be preferable to completely giving up on free and open computing for the future of the Internet. Google should be competing on overall Google account integration experience, security, app selection, and media store features. They should use their competitive position to encourage/enforce good OEM behavior, not to create barriers and bandaids that end up enabling yet more fragmentation due to out of date (and insecure) devices.

It is for this reason that we believe that projects like Copperhead are incredibly important to support. Once we lose these freedoms on mobile, we may never get them back. It is especially troubling to imagine a future where mobile access to the Internet is the primary form of Internet usage, and for that usage, all users are forced to choose between having either security or freedom.

Hardware Choice

The hardware for this prototype is the Google Nexus 6P. While we would prefer to support lower end models for low income demographics, only the Nexus and Pixel lines support Verified Boot with user-controlled keys. We are not aware of any other models that allow this, but we would love to hear if there are any that do.

In theory, installation should work for any of the devices supported by Copperhead, but updating the device will require the addition of an updater-script and an adaptation of the releasetools.py for that device, to convert the radio and bootloader images to the OTA update format.

If you are not allergic to buying hardware online, we highly recommend that you order them from the Copperhead store. The devices are shipped with tamper-evident security tape, for what it's worth. Otherwise, if you're lucky, you might still be able to find a 6P at your local electronics retail store. Please consider donating to Copperhead anyway. The project is doing everything right, and could use your support.

Hopefully, we can add support for the newer Pixel devices as soon as AOSP (and Copperhead) supports them, too.

Installation

Before you dive in, remember that this is a prototype, and you will need to be familiar with Linux.

With the proper prerequisites, installation should be as simple as checking out the Mission Improbable git repository, and downloading a Copperhead factory image for your device.

The run_all.sh script should walk you through a series of steps, printing out instructions for unlocking the phone and flashing the system. Please read the instructions in the repository for full installation details.

The very first device boot after installation will take a while, so be patient. During this boot, you should note the fingerprint of your key on the yellow boot splash screen. That fingerprint is what authenticates the use of your key and the rest of the boot process.

Once the system is booted, after you have given Google Play Services the Location and Storage permissions (as per the instructions printed by the script), make sure you set the Date and Time accurately, or Orbot will not be able to connect to the Tor Network.

Then, you can start Orbot, and allow F-Droid, Download Manager, the Copperhead updater, Google Play Services (if you want to use Signal), and any other apps you want to access the network.

NOTE: To keep Orbot up to date, you will have to go into F-Droid Repositories option, and click Guardian Project Official Releases.

Installation: F-Droid apps

Once you have networking and F-Droid working, you can use MyAppList to install apps from F-Droid. Our installation provides a list of useful apps for MyAppList. The MyAppsList app will allow you to select the subset you want, and install those apps in succession by invoking F-Droid. Start this process by clicking on the upward arrow at the bottom right of the screen:

Alternately, you can add links to additional F-Droid packages in the apk url list prior to running the installation, and they will be downloaded and installed during run_all.sh.

NOTE: Do not update OrWall past 1.1.0 via F-Droid until issue 121 is fixed, or networking will break.

Installation: Signal

Signal is one of the most useful communications applications to have on your phone. Unfortunately, despite being open source itself, Signal is not included in F-Droid, for historical reasons. Near as we can tell, most of the issues behind the argument have actually been since resolved. Now that Signal is reproducible, we see no reason why it can't be included in some F-Droid repo, if not the F-Droid repo, so long as it is the same Signal with the same key. It is unfortunate to see so much disagreement over this point, though. Even if Signal won't make the criterion for the official F-Droid repo (or wherever that tirefire of a flamewar is at right now), we wish that at the very least it could meet the criterion for an alternate "Non-Free" repo, much like the Debian project provides. Nothing is preventing the redistribution of the official Signal apk.

For now, if you do not wish to use a Google account with Google Play, it is possible to download the Signal apks from one of the apk mirror sites (such as APK4fun, apkdot.com, or apkplz.com). To ensure that you have the official Signal apk, perform the following:

  1. Download the apk.
  2. Unzip the apk with unzip org.thoughtcrime.securesms.apk
  3. Verify that the signing key is the official key with keytool -printcert -file META-INF/CERT.RSA
  4. You should see a line with SHA256: 29:F3:4E:5F:27:F2:11:B4:24:BC:5B:F9:D6:71:62:C0 EA:FB:A2:DA:35:AF:35:C1:64:16:FC:44:62:76:BA:26
  5. Make sure that fingerprint matches (the space was added for formatting).
  6. Verify that the contents of that APK are properly signed by that cert with: jarsigner -verify org.thoughtcrime.securesms.apk. You should see jar verified printed out.


Then, you can install the Signal APK via adb with adb install org.thoughtcrime.securesms.apk. You can verify you're up to date with the version in the app store with ApkTrack.

For voice calls to work, select Signal as the SIP application in OrWall, and allow SIP access.

Updates

Because Verified Boot ensures filesystem integrity at the device block level, and because we modify the root and system filesystems, normal over the air updates will not work. The fact that we use different device keys will prevent the official updates from installing at all, but even if they did, they would remove the installation of Google Play, SuperUser, and the OrWall initial firewall script.

When the phone notifies you of an update, you should instead download the latest Copperhead factory image to the mission-improbable working directory, and use update.sh to convert it into a signed update zip that will get sideloaded and installed by the recovery. You need to have the same keys from the installation in the keys subdirectory.

The update.sh script should walk you through this process.

Updates may also reset the system clock, which must be accurate for Orbot to connect to the Tor network. If this happens, you may need to reset the clock manually under Date and Time Settings

Usage

I use this prototype for all of my personal communications - Email, Signal, XMPP+OTR, Mumble, offline maps and directions in OSMAnd, taking pictures, and reading news and books. I use Intent Intercept to avoid accidentally clicking on links, and to avoid surprising cross-app launching behavior.

For Internet access, I personally use a secondary phone that acts as a router for this phone while it is in airplane mode. That phone has an app store and I use it for less trusted, non-private applications, and for emergency situations should a bug with the device prevent it from functioning properly. However, it is also possible to use a cheap wifi cell router, or simply use the actual cell capabilities on the phone itself. In that case, you may want to look into CSipSimple, and a VoIP provider, but see the Future Work section about potential snags with using SIP and Signal at the same time.

I also often use Google Voice or SIP numbers instead of the number of my actual phone's SIM card just as a general protection measure. I give people this number instead of the phone number of my actual cell device, to prevent remote baseband exploits and other location tracking attacks from being trivial to pull off from a distance. This is a trade-off, though, as you are trusting the VoIP provider with your voice data, and on top of this, many of them do not support encryption for call signaling or voice data, and fewer still support SMS.

For situations where using the cell network at all is either undesirable or impossible (perhaps because it is disabled due to civil unrest), the mesh network messaging app Rumble shows a lot of promise. It supports both public and encrypted groups in a Twitter-like interface run over either a wifi or bluetooth ad-hoc mesh network. It could use some attention.

Future Work

Like the last post on the topic, this prototype obviously has a lot of unfinished pieces and unpolished corners. We've made a lot of progress as a community on many of the future work items from that last post, but many still remain.

Future work: More Device Support

As mentioned above, installation should work on all devices that Copperhead supports out of the box. However, updates require the addition of an updater-script and an adaptation of the releasetools.py for that device, to convert the radio and bootloader images to the OTA update format.

Future Work: MicroG support

Instead of Google Play Services, it might be nice to provide the Open Source MicroG replacements. This requires some hackery to spoof the Google Play Service Signature field, though. Unfortunately, this method creates a permission that any app can request to spoof signatures for any service. We'd be much happier about this if we could find a way for MicroG to be the only app to be able to spoof permissions, and only for the Google services it was replacing. This may be as simple as hardcoding those app ids in an updated version of one of these patches.

Future Work: Netfilter API (or better VPN APIs)

Back in the WhisperCore days, Moxie wrote a Netfilter module using libiptc that enabled apps to edit iptables rules if they had permissions for it. This would eliminate the need for iptables shell callouts for using OrWall, would be more stable and less leaky than the current VPN APIs, and would eliminate the need to have root access on the device (which is additional vulnerability surface). That API needs to be dusted off and updated for the Copperhead compatibility, and then Orwall would need to be updated to use it, if present.

Alternatively, the VPN API could be used, if there were ways to prevent leaks at boot, DNS leaks, and leaks if the app is killed or crashes. We'd also want the ability to control specific app network access, and allow bypass of UDP for VoIP apps.

Future Work: Fewer Binary Blobs

There are unfortunately quite a few binary blobs extracted from the Copperhead build tree in the repository. They are enumerated in the README. This was done for expedience. Building some of those components outside of the android build tree is fairly difficult. We would happily accept patches for this, or for replacement tools.

Future Work: F-Droid auto-updates, crash reporting, and install count analytics

These requests come from Moxie. Having these would make him much happier about F-Droid Signal installs.

It turns out that F-Droid supports full auto-updates with the Priviledged Extension, which Copperhead is working on including.

Future Work: Build Reproducibility

Copperhead itself is not yet built reproducibly. It's our opinion that this is the AOSP's responsibility, though. If it's not the core team at Google, they should at least fund Copperhead or some other entity to work on it for them. Reproducible builds should be an organizational priority for all software companies. Moreover, in combination with free software, they are an excellent deterrent against backdoors.

In this brave new world, even if we can trust that the NSA won't be ordered to attack American companies to insert backdoors, deteriorating relationships with China and other state actors may mean that their incentives to hold back on such attacks will be greatly reduced. Closed source components can also benefit from reproducible builds, since compromising multiple build systems/build teams is inherently harder than compromising just one.

Future Work: Orbot Stability

Unfortunately, the stability of Orbot itself still leaves a lot to be desired. It is fairly fragile to network disconnects. It often becomes stuck in states that require you to go into the Android Settings for Apps, and then Force Stop Orbot in order for it to be able to reconnect properly. The startup UI is also fragile to network connectivity.

Worse: If you tap the start button either too hard or multiple times while the network is disconnected or while the phone's clock is out of sync, Orbot can become confused and say that it is connected when it is not. Luckily, because the Tor network access security is enforce by Orwall (and the Android kernel), instabilities in Orbot do not risk Tor leaks.

Future Work: Backups and Remote Wipe

Unfortunately, backups are an unsolved problem. In theory, adb backup -all should work, but even the latest adb version from the official Android SDK appears to only backup and restore partial data. Apparently this is due to adb obeying manifest restrictions on apps that request not to be backed up. For the purposes of full device backup, it would be nice to have an adb version that really backed up everything.

Instead, I use the export feature of K-9 Mail, Contacts, and the Calendar Import-Export app to export that data to /sdcard, and then adb pull /sdcard. It would be nice to have an end-to-end encrypted remote backup app, though. Flock had promise, but was unfortunately discontinued.

Similarly, if a phone is lost, it would be nice to have a cryptographically secure remote wipe feature.

Future Work: Baseband Analysis (and Isolation)

Until phones with auditable baseband isolation are available (the Neo900 looks like a promising candidate), the baseband remains a problem on all of these phones. It is unknown if vulnerabilities or backdoors in the baseband can turn on the mic, make silent calls, or access device memory. Using a portable hotspot or secondary insecure phone is one option for now, but it is still unknown if the baseband is fully disabled in airplane mode. In the previous post, commenters recommended wiping the baseband, but on most phones, this seems to also disable GPS.

It would be useful to audit whether airplane mode fully disables the baseband using either OpenBTS, OsmocommBB, or a custom hardware monitoring device.

Future Work: Wifi AP Scanning Prevention

Copperhead may randomize the MAC address, but it is quite likely that it still tries to connect to configured APs, even if they are not there (see these two XDA threads). This can reveal information about your home and work networks, and any other networks you have configured.

There is a Wifi Privacy Police App in F-Droid, and Smarter WiFi may be other options, but we have not yet had time to audit/test either. Any reports would be useful here.

Future Work: Port Tor Browser to Android

The Guardian Project is undertaking a port of Tor Browser to Android as part of their OrFox project. This port is still incomplete, however. The Tor Project is working on obtaining funding to bring it on par with the desktop Tor Browser.

Future Work: Better SIP Support

Right now, it is difficult to use two or more SIP clients in OrWall. You basically have to switch between them in the settings, which is also fragile and error prone. It would be ideal if OrWall allowed multiple SIP apps to be selected.

Additionally, SIP providers and SIP clients have very poor support for TLS and SRTP encryption for call setup and voice data. I could find only two such providers that advertised this support, but I was unable to actually get TLS and SRTP working with CSipSimple or LinPhone for either of them.

Future Work: Installation and full OTA updates without Linux

In order for this to become a real end-user phone, we need to remove the requirement to use Linux in order to install and update it. Unfortunately, this is tricky. Technically, Google Play can't be distributed in a full Android firmware, so we'd have to get special approval for that. Alternatively, we could make the default install use MicroG, as above. In either case, it should just be a matter of taking the official Copperhead builds, modifying them, changing the update URL, and shipping those devices with Google Play/MicroG and the new OTA location. Copperhead or Tor could easily support multiple device install configurations this way without needing to rebuild everything for each one. So legal issues aside, users could easily have their choice of MicroG, Google Play, or neither.

Personally, I think the demand is higher for some level of Google account integration functionality than what MicroG provides, so it would be nice to find some way to make that work. But there are solid reasons for avoiding the use of a Google account (such as Google's mistreatment of Tor users, the unavailability of Google in certain areas of the world due to censorship of Google, and the technical capability of Google Play to send targeted backdoored versions of apps to specific accounts).

Future Work: Better Boot Key Representation/Authentication

The truncated fingerprint is not the best way to present a key to the user. It is both too short for security, and too hard to read. It would be better to use something like the SSH Randomart representation, or some other visual representation that encodes a cryptographically strong version of the key fingerprint, and asks the user to click through it to boot. Though obviously, if this boot process can also be modified, this may be insufficient.

Future Work: Faster GPS Lock

The GPS on these devices is device-only by default, which can mean it is very slow. It would be useful to find out if µg UnifiedNlp can help, and which of its backends are privacy preserving enough to recommend/enable by default.

Future Work: Sensor Management/Removal

As pointed out in great detail in one of the comments below, these devices have a large number of sensors on them that can be used to create side channels, gather information about the environment, and send it back. The original Mission Impossible post went into quite a bit of detail about how to remove the microphone from the device. This time around, I focused on software security. But like the commentor suggested, you can still go down the hardware modding rabbithole if you like. Just search YouTube for teardown nexus 6P, or similar.


Changes Since Initial Posting

Like the last post, this post will likely be updated for a while based on community feedback. Here is the list of those changes so far.

  1. Added information about secondary SIP/VoIP usage in the Usage section and the Future Work sections.
  2. Added a warning not to upgrade OrWall until Issue 121 is fixed.
  3. Describe how we could remove the Linux requirement and have OTA updates, as a Future Work item.
  4. Remind users to check their key fingerprint at installation and boot, and point out in the Future Work section that this UI could be better.
  5. Mention the Neo900 in the Future Work: Baseband Isolation section
  6. Wow, the Signal vs F-Droid issue is a stupid hot mess. Can't we all just get along and share the software? Don't make me sing the RMS song, people... I'll do it...
  7. Added a note that you need the Guardian Project F-Droid repo to update Orbot.
  8. Add a thought to the Systemic Threats to Software Freedom section about using licensing to enforce the update requirement in order to use the AOSP.
  9. Mention ApkTrack for monitoring for Signal updates, and Intent Intercept for avoiding risky clicks.
  10. Mention alternate location providers as Future Work, and that we need to pick a decent backend.
  11. Link to Conversations and some other apps in the usage section. Also add some other links here and there.
  12. Mention that Date and Time must be set correctly for Orbot to connect to the network.
  13. Added a link to Moxie's netfilter code to the Future Work section, should anyone want to try to dust it off and get it working with Orwall.
  14. Use keytool instead of sha256sum to verify the Signal key's fingerprint. The CERT.RSA file is not stable across versions.
  15. The latest Orbot 15.2.0-rc8 still has issues claiming that it is connected when it is not. This is easiest to observe if the system clock is wrong, but it can also happen on network disconnects.
  16. Add a Future Work section for sensor management/removal

The Trouble with CloudFlare

Wednesday, CloudFlare blogged that 94% of the requests it sees from Tor are "malicious." We find that unlikely, and we've asked CloudFlare to provide justification to back up this claim. We suspect this figure is based on a flawed methodology by which CloudFlare labels all traffic from an IP address that has ever sent spam as "malicious." Tor IP addresses are conduits for millions of people who are then blocked from reaching websites under CloudFlare's system.

We're interested in hearing CloudFlare's explanation of how they arrived at the 94% figure and why they choose to block so much legitimate Tor traffic. While we wait to hear from CloudFlare, here's what we know:

1) CloudFlare uses an IP reputation system to assign scores to IP addresses that generate malicious traffic. In their blog post, they mentioned obtaining data from Project Honey Pot, in addition to their own systems. Project Honey Pot has an IP reputation system that causes IP addresses to be labeled as "malicious" if they ever send spam to a select set of diagnostic machines that are not normally in use. CloudFlare has not described the nature of the IP reputation systems they use in any detail.

2) External research has found that CloudFlare blocks at least 80% of Tor IP addresses, and this number has been steadily increasing over time.

3) That same study found that it typically took 30 days for an event to happen that caused a Tor IP address to acquire a bad reputation and become blocked, but once it happens, innocent users continued to be punished for it for the duration of the study.

4) That study also showed a disturbing increase over time in how many IP addresses CloudFlare blocked without removal. CloudFlare's approach to blocking abusive traffic is incurring a large amount of false positives in the form of impeding normal traffic, thereby damaging the experience of many innocent Tor and non-Tor Internet users, as well as impacting the revenue streams of CloudFlare's own customers by causing frustrated or blocked users to go elsewhere.

5) A report by CloudFlare competitor Akamai found that the percentage of legitimate e-commerce traffic originating from Tor IP addresses is nearly identical to that originating from the Internet at large. (Specifically, Akamai found that the "conversion rate" of Tor IP addresses clicking on ads and performing commercial activity was "virtually equal" to that of non-Tor IP addresses).

CloudFlare disagrees with our use of the word "block" when describing its treatment of Tor traffic, but that's exactly what their system ultimately does in many cases. Users are either blocked outright with CAPTCHA server failure messages, or prevented from reaching websites with a long (and sometimes endless) loop of CAPTCHAs, many of which require the user to understand English in order to solve correctly. For users in developing nations who pay for Internet service by the minute, the problem is even worse as the CAPTCHAs load slowly and users may have to solve dozens each day with no guarantee of reaching a particular site. Rather than waste their limited Internet time, such users will either navigate away, or choose not to use Tor and put themselves at risk.

Also see our new fact sheet about CloudFlare and Tor: https://people.torproject.org/~lunar/20160331-CloudFlare_Fact_Sheet.pdf

A Statement from The Tor Project on Software Integrity and Apple

The Tor Project exists to provide privacy and anonymity for millions of people, including human rights defenders across the globe whose lives depend on it. The strong encryption built into our software is essential for their safety.

In an age when people have so little control over the information recorded about their lives, we believe that privacy is worth fighting for.

We therefore stand with Apple to defend strong encryption and to oppose government pressure to weaken it. We will never backdoor our software.

Our users face very serious threats. These users include bloggers reporting on drug violence in Latin America; dissidents in China, Russia, and the Middle East; police and military officers who use our software to keep themselves safe on the job; and LGBTI individuals who face persecution nearly everywhere. Even in Western societies, studies demonstrate that intelligence agencies such as the NSA are chilling dissent and silencing political discourse merely through the threat of pervasive surveillance.

For all of our users, their privacy is their security. And for all of them, that privacy depends upon the integrity of our software, and on strong cryptography. Any weakness introduced to help a particular government would inevitably be discovered and could be used against all of our users.

The Tor Project employs several mechanisms to ensure the security and integrity of our software. Our primary product, the Tor Browser, is fully open source. Moreover, anyone can obtain our source code and produce bit-for-bit identical copies of the programs we distribute using Reproducible Builds, eliminating the possibility of single points of compromise or coercion in our software build process. The Tor Browser downloads its software updates anonymously using the Tor network, and update requests contain no identifying information that could be used to deliver targeted malicious updates to specific users. These requests also use HTTPS encryption and pinned HTTPS certificates (a security mechanism that allows HTTPS websites to resist being impersonated by an attacker by specifying exact cryptographic keys for sites). Finally, the updates themselves are also protected by strong cryptography, in the form of package-level cryptographic signatures (the Tor Project signs the update files themselves). This use of multiple independent cryptographic mechanisms and independent keys reduces the risk of single points of failure.

The Tor Project has never received a legal demand to place a backdoor in its programs or source code, nor have we received any requests to hand over cryptographic signing material. This isn't surprising: we've been public about our "no backdoors, ever" stance, we've had clear public support from our friends at EFF and ACLU, and it's well-known that our open source engineering processes and distributed architecture make it hard to add a backdoor quietly.

From an engineering perspective, our code review and open source development processes make it likely that such a backdoor would be quickly discovered. We are also currently accelerating the development of a vulnerability-reporting reward program to encourage external software developers to look for and report any vulnerabilities that affect our primary software products.

The threats that Apple faces to hand over its cryptographic signing keys to the US government (or to sign alternate versions of its software for the US government) are no different than threats of force or compromise that any of our developers or our volunteer network operators may face from any actor, governmental or not. For this reason, regardless of the outcome of the Apple decision, we are exploring further ways to eliminate single points of failure, so that even if a government or a criminal obtains our cryptographic keys, our distributed network and its users would be able to detect this fact and report it to us as a security issue.

Like those at Apple, several of our developers have already stated that they would rather resign than honor any request to introduce a backdoor or vulnerability into our software that could be used to harm our users. We look forward to making an official public statement on this commitment as the situation unfolds. However, since requests for backdoors or cryptographic key material so closely resemble many other forms of security failure, we remain committed to researching and developing engineering solutions to further mitigate these risks, regardless of their origin.

We congratulate Apple on their commitment to the privacy and security of their users, and we admire their efforts to advance the debate over the right to privacy and security for all.

This is What a Tor Supporter Looks Like: Edward Snowden

Edward Snowden


In mid-October, the Tor Project had an opportunity to interview Edward Snowden. Below are key excerpts from the conversation.


Tor: What would you say to a non-technical person about why they should support and care about Tor?

ES: Tor is a critical technology, not just in terms of privacy protection, but in defense of our publication right -- our ability to route around censorship and ensure that when people speak their voices can be heard.

The design of the Tor system is structured in such a way that even if the US Government wanted to subvert it, it couldn't because it's a decentralized authority. It's a volunteer based network. Nobody's getting paid to run Tor relays -- they're volunteers worldwide. And because of this, it provides a built-in structural defense against abuses and most types of adversaries.

Tor provides a level of safety, a level of guarantee, to the confidentiality, and in some cases anonymity of human communications. I think this is an incredible thing because it makes us more human. We are at the greatest peace with ourselves when nobody's watching.

Tor: Can you talk about how the world would be different if Tor did not exist?

ES: Without Tor, the streets of the Internet become like the streets of a very heavily surveilled city. There are surveillance cameras everywhere, and if the adversary simply takes enough time, they can follow the tapes back and see everything you've done.

With Tor, we have private spaces and private lives, where we can choose who we want to associate with and how, without the fear of what that is going to look like if it is abused.

What the Tor network allows is what's called a mixed routing experience where, due to a voluntary cooperation of peers around the Internet -- around the world, across borders, across jurisdictions -- you get individuals who are able to share traffic in ways that don't require them to be able to read the content of it. So you don't have to trust every participant of the Tor network to know who you are and what you're looking for.

Tor: Did you know that Tor is run by a non-profit organization?

ES: Yes, Tor has been extremely open. Almost everybody who is involved in development has an online presence; they're involved in online engagement. You can drop into the IRC and talk to these people directly and ask them questions, or criticize them (laughs). It's a very open and inclusive community, and I think that's incredibly valuable.

They also have a very rich and well-supported mailing list, which is very helpful for people who want to move beyond being a passive user of Tor and actually start being an active participant in expanding the network, in running a relay node from your home, or even starting to experiment with running an exit, which I think is one of the most interesting parts of the Tor experience.


Please join Ed in supporting Tor Today!

Tor Browser 5.0.1 is released

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

This release fixes a crash bug that caused Tor Browser to crash on certain sites (in particular, Google Maps and Tumblr). The crash bug was a NULL pointer dereference while handling blob URIs. The crash was not exploitable.

Here is the complete changelog since 5.0:

  • All Platforms
    • Bug 16771: Fix crash on some websites due to blob URIs

Tor Browser 5.5a1 is released

The Tor Browser Team is proud to announce the first alpha release in the 5.5 series. The release is available for download in the 5.5a1 distribution directory and on the alpha download page.

This release features important security updates to Firefox. In particular, while the recent PDF.js exploit did not affect 4.5 users, it does affect users of 5.0a3 and 5.0a4. Although the High security level of the Security Slider also prevented the exploit from working against even those users, all alpha users are still strongly encouraged to upgrade as soon as possible.

In addition to fixing these security issues, the remaining major issues with Firefox 38 from 5.0a4 were also fixed. This release also features improvements to fingerprinting defenses. In particular, we continue to refine our font fingerprinting defense that was added in 5.0a4. With this defense, Tor Browser now ships with a standard set of fonts, and prefers to use the provided fonts instead of native ones in most cases. Interested users are encouraged to help us refine this defense by commenting on the associated ticket in our bugtracker.

This release also will reset the permanent NoScript whitelist, due to an issue where previous NoScript updates had added certain domains to the whitelist during upgrade. The whitelist is reset to the default for all users as a result, and future updates to the whitelist by NoScript have been disabled.

Here is the complete changelog since 5.0a4:

  • All Platforms
    • Update Firefox to 38.2.0esr
    • Update NoScript to 2.6.9.34
    • Update Torbutton to 1.9.3.3
      • Bug 16731: TBB 5.0 a3/a4 fails to download a file on right click
      • Bug 16730: Reset NoScript whitelist on upgrade
      • Bug 16722: Prevent "Tiles" feature from being enabled after upgrade
      • Bug 16488: Remove "Sign in to Sync" from the browser menu (fixup)
      • Bug 14429: Make sure the automatic resizing is enabled
      • Translation updates
    • Update Tor Launcher to 0.2.7.7
      • Translation updates
    • Bug 16730: Prevent NoScript from updating the default whitelist
    • Bug 16715: Use ThreadsafeIsCallerChrome() instead of IsCallerChrome()
    • Bug 16572: Verify cache isolation for XMLHttpRequests in Web Workers
    • Bug 16311: Fix navigation timing in ESR 38
    • Bug 15646: Prevent keyboard layout fingerprinting in KeyboardEvent (fixup)
    • Bug 16672: Change font whitelists and configs for rendering issues (partial)

Tor Browser 5.0 is released

The Tor Browser Team is proud to announce the first stable release in the 5.0 series. This release is available from the Tor Browser Project page and also from our distribution directory.

This release features important security updates to Firefox. Note that the recent PDF.js exploit did not affect 4.5 users, but they should upgrade to this release immediately because numerous other potential security issues were fixed by Mozilla in this release. (Incidentally: Users who are using the 5.0-alpha series are vulnerable to the PDF.js exploit, but not if they were using the 'High' security level. Regardless, we are also upgrading 5.0-alpha users to 5.5a1 today to fix the issue as well).

This release also brings us up to date with Firefox 38-ESR, which should mean improved support for HTML5 video on Youtube, as well as a host of other improvements. Controversial and hard-to-audit binary components related to EME DRM were disabled, however.

The release also features new privacy enhancements. In particular, more identifier sources that appeared in Firefox 38 (or were otherwise disabled previously) are now isolated to the first party (URL bar) domain. This release also contains defenses from the 5.0-alpha series for keystroke (typing) fingerprinting and some instances of performance/timing fingerprinting.

Regrettably, our new defenses for font and keyboard layout fingerprinting did not stabilize in time for this release. Users who are interested in helping us improve them should try out 5.5a1.

This release also will reset the permanent NoScript whitelist, due to an issue where previous NoScript updates had added certain domains to the whitelist during upgrade. The whitelist is reset to the default for all users as a result, and future updates to the whitelist by NoScript have been disabled.

Starting with this release, Tor Browser will now also download and apply upgrades in the background, to ensure that users upgrade quicker and with less interaction. This behavior is governed by the about:config pref app.update.auto, but we do not recommend disabling it unless you really know what you're doing.

Here is the complete changelog since 4.5.3:

  • All Platforms
    • Update Firefox to 38.2.0esr
    • Update OpenSSL to 1.0.1p
    • Update HTTPS-Everywhere to 5.0.7
    • Update NoScript to 2.6.9.34
    • Update meek to 0.20
    • Update Tor to 0.2.6.10 with patches:
      • Bug 16674: Allow FQDNs ending with a single '.' in our SOCKS host name checks.
      • Bug 16430: Allow DNS names with _ characters in them (fixes nytimes.com)
      • Bug 15482: Don't allow circuits to change while a site is in use
    • Update Torbutton to 1.9.3.2
      • Bug 16731: TBB 5.0 a3/a4 fails to download a file on right click
      • Bug 16730: Reset NoScript whitelist on upgrade
      • Bug 16722: Prevent "Tiles" feature from being enabled after upgrade
      • Bug 16488: Remove "Sign in to Sync" from the browser menu (fixup)
      • Bug 16268: Show Tor Browser logo on About page
      • Bug 16639: Check for Updates menu item can cause update download failure
      • Bug 15781: Remove the sessionstore filter
      • Bug 15656: Sync privacy.resistFingerprinting with Torbutton pref
      • Bug 16427: Use internal update URL to block updates (instead of 127.0.0.1)
      • Bug 16200: Update Cache API usage and prefs for FF38
      • Bug 16357: Use Mozilla API to wipe permissions db
      • Bug 14429: Make sure the automatic resizing is disabled
      • Translation updates
    • Update Tor Launcher to 0.2.7.7
      • Bug 16428: Use internal update URL to block updates (instead of 127.0.0.1)
      • Bug 15145: Visually distinguish "proxy" and "bridge" screens.
      • Translation updates
    • Bug 16730: Prevent NoScript from updating the default whitelist
    • Bug 16715: Use ThreadsafeIsCallerChrome() instead of IsCallerChrome()
    • Bug 16572: Verify cache isolation for XMLHttpRequests in Web Workers
    • Bug 16884: Prefer IPv6 when supported by the current Tor exit
    • Bug 16488: Remove "Sign in to Sync" from the browser menu
    • Bug 16662: Enable network.http.spdy.* prefs in meek-http-helper
    • Bug 15703: Isolate mediasource URIs and media streams to first party
    • Bug 16429+16416: Isolate blob URIs to first party
    • Bug 16632: Turn on the background updater and restart prompting
    • Bug 16528: Prevent indexedDB Modernizr site breakage on Twitter and elsewhere
    • Bug 16523: Fix in-browser JavaScript debugger
    • Bug 16236: Windows updater: avoid writing to the registry
    • Bug 16625: Fully disable network connection prediction
    • Bug 16495: Fix SVG crash when security level is set to "High"
    • Bug 13247: Fix meek profile error after bowser restarts
    • Bug 16005: Relax WebGL minimal mode
    • Bug 16300: Isolate Broadcast Channels to first party
    • Bug 16439: Remove Roku screencasting code
    • Bug 16285: Disabling EME bits
    • Bug 16206: Enforce certificate pinning
    • Bug 15910: Disable Gecko Media Plugins for now
    • Bug 13670: Isolate OCSP requests by first party domain
    • Bug 16448: Isolate favicon requests by first party
    • Bug 7561: Disable FTP request caching
    • Bug 6503: Fix single-word URL bar searching
    • Bug 15526: ES6 page crashes Tor Browser
    • Bug 16254: Disable GeoIP-based search results.
    • Bug 16222: Disable WebIDE to prevent remote debugging and addon downloads.
    • Bug 13024: Disable DOM Resource Timing API
    • Bug 16340: Disable User Timing API
    • Bug 14952: Disable HTTP/2
    • Bug 1517: Reduce precision of time for Javascript
    • Bug 13670: Ensure OCSP & favicons respect URL bar domain isolation
    • Bug 16311: Fix navigation timing in ESR 38
  • Windows
    • Bug 16014: Staged update fails if meek is enabled
    • Bug 16269: repeated add-on compatibility check after update (meek enabled)
  • Mac OS
    • Use OSX 10.7 SDK
    • Bug 16253: Tor Browser menu on OS X is broken with ESR 38
    • Bug 15773: Enable ICU on OS X
  • Build System
    • Bug 16351: Upgrade our toolchain to use GCC 5.1
    • Bug 15772 and child tickets: Update build system for Firefox 38
    • Bugs 15921+15922: Fix build errors during Mozilla Tryserver builds
    • Bug 15864: rename sha256sums.txt to sha256sums-unsigned-build.txt

Tor Browser 5.0a2 is released

The second alpha release in the 5.0 series of the Tor Browser is now available from our extended downloads page as well as the distribution directory.

This release provides a fix for the Logjam attack (https://weakdh.org/) and updates a number of Tor Browser components: Tor to version 0.2.7.1-alpha, Torbutton to version 1.9.2.7, NoScript to version 2.6.9.26, meek to version 0.19 and HTTPS-Everywhere to version 5.0.5. Moreover, it fixes a possible crash on Linux and avoids breaking the Add-ons page if Torbutton is disabled, and it also fixes an update issue when using meek on Windows systems.

Here is the complete changelog

  • All Platforms
    • Update Tor to 0.2.7.1-alpha
    • Update OpenSSL to 1.0.1n
    • Update HTTPS-Everywhere to 5.0.5
    • Update NoScript to 2.6.9.26
    • Update meek to 0.19
    • Update Torbutton to 1.9.2.7
      • Bug 15984: Disabling Torbutton breaks the Add-ons Manager
      • Bug 14429: Make sure the automatic resizing is enabled
      • Translation updates
    • Bug 16130: Defend against logjam attack
    • Bug 15984: Disabling Torbutton breaks the Add-ons Manager
  • Windows
    • Bug 16014: Staged update fails if meek is enabled
    • Bug 16269: repeated add-on compatibility check after update (meek enabled)
  • Linux
    • Bug 16026: Fix crash in GStreamer
    • Bug 16083: Update comment in start-tor-browser
Syndicate content Syndicate content