Blogs

Tor Project is hiring a developer!

Are you or do you know an experienced, passionate developer who wants to work on the core tor proxy software? We are looking for a talented developer to join the network team as a full-time employee.
(https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam).

The job posting, including instructions for how to apply, can be viewed at this link:
https://www.torproject.org/about/jobs-coredev.html.en

Please help us spread the word! You can direct people to the above link or retweet our Twitter announcement:
https://twitter.com/torproject/status/801515058131931136

This will be a remote position, so people from all over the world are encouraged to apply. Deadline for applications is December 31, 2016.

Cheers!
Erin Wyatt
Tor Project, HR Manager

Tor Browser 6.0.7 is released

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

This release features an important security update to Firefox and contains, in addition to that, an update to NoScript (2.9.5.2).

The security flaw responsible for this urgent release is already actively exploited on Windows systems. Even though there is currently, to the best of our knowledge, no similar exploit for OS X or Linux users available the underlying bug affects those platforms as well. Thus we strongly recommend that all users apply the update to their Tor Browser immediately. A restart is required for it to take effect.

Tor Browser users who had set their security slider to "High" are believed to have been safe from this vulnerability.

We will have alpha and hardened Tor Browser updates out shortly. In the meantime, users of these series can mitigate the security flaw in at least two ways:

1) Set the security slider to "High" as this is preventing the exploit from working.
2) Switch to the stable series until updates for alpha and hardened are available, too.

Here is the full changelog since 6.0.6:

  • All Platforms
    • Update Firefox to 45.5.1esr
    • Update NoScript to 2.9.5.2

Update: We would like to remind everyone that we (The Tor Project) are having our 2016 fundraising campaign! Donate today!

Support the Tor Project 2016!

Today the Tor Project launches our end-of-year crowdfunding campaign, themed "Tor: at the Heart of Internet Freedom." This is part of our initiative to diversify our funding sources and improve our communications with you, our contributors and supporters. We're using the open-source membership platform CiviCRM to help us manage things, and donors should receive thank-you notes and swag in a timely fashion.

The Tor Project has been around for ten years, making tools that promote and protect the essential human rights of people around the world. Our work protects activists from persecution, whistleblowers from retribution, and vulnerable and marginalized people from further attacks and isolation.

The need for Tor is greater than ever.

Surveillance and censorship harm our freedom to exchange ideas, connect with our families and friends, and improve our lives--matters of the head...and the heart.

The Tor Project is more than a software organization. Tor is a labor of love by an international community passionate about preserving your freedom to express yourself fearlessly and keep private things private.

As another year comes to a close, won't you join us as we provide anonymizing technologies crucial to protecting our human rights? Please support this important work by making a tax-deductible donation now:

https://donate.torproject.org/

Here are some of the things we've accomplished over the last year, thanks in part to donations from our community:

· Updated and released over a dozen stable versions of the Tor Browser, a critical tool for securely and anonymously accessing the Tor Network and all Internet websites, to add features and fix bugs in coordination with new releases of Mozilla Firefox.

· Added additional Pluggable Transports (PTs) to the Tor Browser, making it easier for users under repressive governments to connect to the Tor network and bypass censorship.

· Improved the security and performance of the core Tor program, the underlying proxy software that Tor Browser uses to protect your traffic.

· Researched post-quantum cryptography alternatives for deployment to ensure the security of our systems into the future.

· Upgraded our cryptographic backends to ensure that Tor can provide the widest number of supported cryptographic algorithms, as well as support platform specific implementations.

· Strengthened our external community by ramping up work on better user support and documentation, including a new Tor Browser manual.

· Strengthened our internal community by coming together around the Tor Social Contract, which affirms our commitment to our beliefs, including our promise to never put backdoors into Tor.

· Grew the Community Team to build the network of people around the world doing Tor outreach and to provide them with training resources.

· Empowered people in Brazil, Russia, Turkey, and other countries suffering from increased censorship in 2016.

· Improved GetTor, helping more people who live under oppressive censorship regimes to easily access the Tor Browser and other vital information.

· Released the public beta of OONI Explorer, a global map of Internet censorship (and how well Tor circumvents it) in over 100 countries over the last three years.

· Made great progress toward next-generation Onion Services, including deployment throughout the Debian infrastructure, and tools like OnionBalance, a server tool that helps improve the stability and availability of popular Onion Services.

· Conducted an informal review of our major bugs from the last few years to look for trends and patterns to help us use our time and resources more effectively to write our code more safely over the coming years.

· Served as a founding partner in a Day of Action protesting changes to Rule 41 of the US Federal Rules of Criminal Procedure. This rule will make it easier for the FBI to legally hack into devices that use Tor or a VPN, wherever in the world those devices are located.

· Released an experimental prototype of a Tor Android phone, an important step in providing uncensored Internet access for millions of worldwide mobile device users.

· Built a sandbox system for Tor Browser for Linux, to be released in alpha form by the end of the year, that will help protect users from malicious attacks at the application layer.

· Grew the community of enthusiastic privacy and security developers, including mentoring seven students in the Google Summer of Code program.

· Continued our central role in the privacy research community, pointing academic research groups at the most pressing problems and helping their results to have real-world impact.

In the coming year, we can do so much more! Please help us keep up the good fight. Make your tax-deductible contribution to the Tor Project today:

https://donate.torproject.org/

Thank you for your support!

Shari Steele
Executive Director
The Tor Project

Stem Release 1.5

in

Damn this was long overdue. I'm delighted to announce Stem 1.5.2, the accumulation of seventeen months of improvements.

What is Stem, you ask? For those who aren't familiar with it Stem is a Python library for interacting with Tor. With it you can script against your relay, descriptor data, or even write applications similar to Nyx and Vidalia.

So what's new in this release? Short answer: a lot.

For full details see our release announcement.

Tor Messenger 0.3.0b1 is released

We are pleased to announce another public beta release of Tor Messenger. This release features important improvements to the stability and security of Instantbird. All users are highly encouraged to upgrade.

Tor Browser Build

Starting with this release, Tor Messenger will be built on top of Tor Browser instead of Mozilla ESR. This will help us in improving the security of Tor Messenger by making use of Tor Browser's patches. We will also try to keep in sync with the Tor Browser stable release cycle.

Secure Updates

Tor Messenger 0.2.0b2 users will be automatically prompted to install the update (similar to Tor Browser). On installing and restarting, the update will be applied; your account settings and OTR keys will be preserved.

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

macOS

sha256sums-unsigned-build.txt
sha256sums-unsigned-build.txt.asc

The sha256sums-unsigned-build.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

Tor Messenger 0.3.0b1 -- 22 November 2016

  • All Platforms
    • Use the tor-browser-45.5.0esr-6.0-1 branch (e5dafab8) on tor-browser
    • Use the THUNDERBIRD_45_4_0_RELEASE tag on comm-esr45
    • Update ctypes-otr to 0.0.3
    • Trac 16489: Only show "close" button on Windows
    • Trac 16491: Contact list entries don't adapt to the actual font size
    • Trac 16536: Investigate Tor Browser patches relevant to Tor Messenger
    • Trac 17471: Investigate Tor Browser preferences relevant to Tor Messenger
    • Trac 17480: Make url linkification toggleable
    • Trac 19816: Build process should generate mar files
    • Trac 20205: Support SASL ECDSA-NIST256P-CHALLENGE
    • Trac 20208: Put conversations on hold by default
    • Trac 20231: Remove incomplete translations
    • Trac 20276: Fix toggling sounds
    • Trac 20608: Use Instantbird app version
    • Bugzilla 1246431: Properly handle incoming xmpp server messages
    • Bugzilla 1313137: Fix irc "msg is not defined" error
    • Bugzilla 1316000: Remove old Yahoo! Messenger support
  • Mac
    • Trac 20204: Windows don't drag on macOS Sierra
    • Trac 20206: Avoid prompting to download font "Osaka" on macOS Sierra
    • Trac 20207: IB and Tor Messenger still share a notification key
  • Windows
    • Trac 20062: Make stripping signatures reproducible on TM .exe files

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

Tor Browser 6.5a4-hardened is released

A new hardened Tor Browser release is available. It can be found in the 6.5a4-hardened distribution directory and on the download page for hardened builds.

This release features important security updates to Firefox. Other components got an update as well: Tor to 0.2.9.5-alpha, HTTPS-Everywhere to 5.2.7, and OpenSSL to 1.0.2j.

This release includes numerous bug fixes and improvements. Most notably we improved our Unix domain socket support by resolving all the issues that showed up in the previous alpha and by making sure all connections to tor (not only the control port related ones) are using this feature now.

Additionally, we fixed a lot of usability bugs, most notably those caused by our window resizing logic. We moved the relevant code out of Torbutton into a C++ patch which we hope to get upstreamed into Firefox. We improved the usability of our security slider as well by reducing the amount of security levels available and redesigning the custom mode.

Finally, we added a donation banner shown in some localized bundles starting on Nov 23 in order to point to our end-of-the-year 2016 donation campaign.

For those who want to know in which ways the alpha and the hardened series differ: check out the discussion we had on the tbb-dev mailing list a while back.

Update (11/16 2213UTC): We currently have problems with our auto-updater at least on Linux systems. The updates are downloaded but don't get applied for yet unknown reasons. We therefore have decided to disable the automatic updates until we understand the problem and provide a fix for it. Progress on that task can be tracked in ticket 20691 in our bug tracker. We are sorry for this inconvenience. Fresh bundles are available on our download page, though.

Update (11/18 0937UTC): We enabled the updates again with an information prompt. One of the following workarounds can be used to avoid the updater error:

  • in about:config, set app.update.staging.enabled to false before attempting to update
  • in about:config, set extensions.torlauncher.control_port_use_socket to false (disabling the control port Unix domain socket) and restart the browser before attempting to update

Here is the full changelog since 6.5a3-hardened:

  • All Platforms
    • Update Firefox to 45.5.0esr
    • Update Tor to tor-0.2.9.5-alpha
    • Update OpenSSL to 1.0.2j
    • Update Torbutton to 1.9.6.7
      • Bug 20414: Add donation banner on about:tor for 2016 campaign
      • Bug 20111: Use Unix domain sockets for SOCKS port by default
      • Bug 19459: Move resizing code to tor-browser.git
      • Bug 20264: Change security slider to 3 options
      • Bug 20347: Enhance security slider's custom mode
      • Bug 20123: Disable remote jar on all security levels
      • Bug 20244: Move privacy checkboxes to about:preferences#privacy
      • Bug 17546: Add tooltips to explain our privacy checkboxes
      • Bug 17904: Allow security settings dialog to resize
      • Bug 18093: Remove 'Restore Defaults' button
      • Bug 20373: Prevent redundant dialogs opening
      • Bug 20388+20399+20394: Code clean-up
      • Translation updates
    • Update Tor Launcher to 0.2.11.1
      • Bug 20111: Use Unix domain sockets for SOCKS port by default
      • Bug 20185: Avoid using Unix domain socket paths that are too long
      • Bug 20429: Do not open progress window if tor doesn't get started
      • Bug 19646: Wrong location for meek browser profile on OS X
      • Translation updates
    • Update HTTPS-Everywhere to 5.2.7
    • Update meek to 0.25
      • Bug 19646: Wrong location for meek browser profile on OS X
      • Bug 20030: Shut down meek-http-helper cleanly if built with Go > 1.5.4
    • Bug 20304: Support spaces and other special characters for SOCKS socket
    • Bug 20490: Fix assertion failure due to fix for bug 20304
    • Bug 19459: Size new windows to 1000x1000 or nearest 200x100 (Firefox patch)
    • Bug 20442: Backport fix for local path disclosure after drag and drop
    • Bug 20160: Backport fix for broken MP3-playback
    • Bug 20043: Isolate SharedWorker script requests to first party
    • Bug 20123: Always block remote jar files
    • Bug 20244: Move privacy checkboxes to about:preferences#privacy
    • Bug 19838: Add dgoulet's bridge and add another one commented out
    • Bug 19481: Point the update URL to aus1.torproject.org
    • Bug 20296: Rotate ports again for default obfs4 bridges
    • Bug 20651: DuckDuckGo does not work with JavaScript disabled
    • Bug 20399+15852: Code clean-up
    • Bug 15953: Weird resizing dance on Tor Browser startup
  • Build System
    • All Platforms

Tor Browser 6.5a4 is released

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

This release features important security updates to Firefox. Other components got an update as well: Tor to 0.2.9.5-alpha, HTTPS-Everywhere to 5.2.7, and OpenSSL to 1.0.2j.

This release includes numerous bug fixes and improvements. Most notably we improved our Unix domain socket support by resolving all the issues that showed up in the previous alpha and by making sure all connections to tor (not only the control port related ones) are using this feature on OS X and Linux now.

Additionally, we fixed a lot of usability bugs, some caused by Apple's macOS Sierra (meek did not work anymore and windows could not be dragged either). Others were caused by our window resizing logic. We moved that one into a C++ patch which we hope to get upstreamed into Firefox. We improved the usability of our security slider as well by reducing the amount of security levels available and redesigning the custom mode.

Finally, we added a donation banner shown in some localized bundles starting on Nov 23 in order to point to our end-of-the-year 2016 donation campaign.

Update (11/16 2215UTC): We currently have problems with our auto-updater at least on Linux systems. The updates are downloaded but don't get applied for yet unknown reasons. We therefore have decided to disable the automatic updates until we understand the problem and provide a fix for it. Progress on that task can be tracked in ticket 20691 in our bug tracker. We are sorry for this inconvenience. Fresh bundles are available on our download page, though.

Update (11/17 1012UTC): After some investigation and testing it turned out that the Windows platform is not affected by the updating problems. We therefore have enabled updates for it again. Updates for OS X and Linux stay disabled while we are trying to get to the bottom of our problems and to provide fixes/workarounds for them.

Update (11/17 1422UTC): Updates for OS X are enabled now as well as Mac systems are not affected by the bug in the updater code either.

Update (11/18 0953UTC): Updates for Linux are enabled now as well, with an information prompt listing the workarounds. One of the following workarounds can be used to avoid the updater error:

  • in about:config, set app.update.staging.enabled to false before attempting to update
  • in about:config, set extensions.torlauncher.control_port_use_socket to false (disabling the control port Unix domain socket) and restart the browser before attempting to update

Here is the full changelog since 6.5a3:

  • All Platforms
    • Update Firefox to 45.5.0esr
    • Update Tor to tor-0.2.9.5-alpha
    • Update OpenSSL to 1.0.2j
    • Update Torbutton to 1.9.6.7
      • Bug 20414: Add donation banner on about:tor for 2016 campaign
      • Bug 20111: Use Unix domain sockets for SOCKS port by default
      • Bug 19459: Move resizing code to tor-browser.git
      • Bug 20264: Change security slider to 3 options
      • Bug 20347: Enhance security slider's custom mode
      • Bug 20123: Disable remote jar on all security levels
      • Bug 20244: Move privacy checkboxes to about:preferences#privacy
      • Bug 17546: Add tooltips to explain our privacy checkboxes
      • Bug 17904: Allow security settings dialog to resize
      • Bug 18093: Remove 'Restore Defaults' button
      • Bug 20373: Prevent redundant dialogs opening
      • Bug 20388+20399+20394: Code clean-up
      • Translation updates
    • Update Tor Launcher to 0.2.10.2
      • Bug 20111: Use Unix domain sockets for SOCKS port by default
      • Bug 20185: Avoid using Unix domain socket paths that are too long
      • Bug 20429: Do not open progress window if tor doesn't get started
      • Bug 19646: Wrong location for meek browser profile on OS X
      • Translation updates
    • Update HTTPS-Everywhere to 5.2.7
    • Update meek to 0.25
      • Bug 19646: Wrong location for meek browser profile on OS X
      • Bug 20030: Shut down meek-http-helper cleanly if built with Go > 1.5.4
    • Bug 20304: Support spaces and other special characters for SOCKS socket
    • Bug 20490: Fix assertion failure due to fix for bug 20304
    • Bug 19459: Size new windows to 1000x1000 or nearest 200x100 (Firefox patch)
    • Bug 20442: Backport fix for local path disclosure after drag and drop
    • Bug 20160: Backport fix for broken MP3-playback
    • Bug 20043: Isolate SharedWorker script requests to first party
    • Bug 20123: Always block remote jar files
    • Bug 20244: Move privacy checkboxes to about:preferences#privacy
    • Bug 19838: Add dgoulet's bridge and add another one commented out
    • Bug 19481: Point the update URL to aus1.torproject.org
    • Bug 20296: Rotate ports again for default obfs4 bridges
    • Bug 20651: DuckDuckGo does not work with JavaScript disabled
    • Bug 20399+15852: Code clean-up
  • Windows
    • Bug 20342: Add tor-gencert.exe to expert bundle
    • Bug 18175: Maximizing window and restarting leads to non-rounded window size
    • Bug 13437: Rounded inner window accidentally grows to non-rounded size
  • OS X
    • Bug 20204: Windows don't drag on macOS Sierra anymore
    • Bug 20250: Meek fails on macOS Sierra if built with Go < 1.7
    • Bug 20590: Badly resized window due to security slider notification bar on OS X
    • Bug 20439: Make the build PIE on OSX
  • Linux
    • Bug 15953: Weird resizing dance on Tor Browser startup
  • Build System
    • All Platforms
    • OS X
      • Bug 20258: Make OS X Tor archive reproducible again
      • Bug 20184: Make OS X builds reproducible again
      • Bug 20210: In dmg2mar, extract old mar file to copy permissions to the new one
Syndicate content Syndicate content