Ubuntu OS updates with security and privacy

Never Forget DSA-3733
Validating signatures > MitM > RCE

The Debian developer community refused to implement transport crypto for updates because “signing packages is secure enough”. Utter bullshit.

This is a quick guide on how to dramatically improve the privacy and security of your Ubuntu web server. It requires the installation of “apt-transport-tor”, an application that will allow APT transfers to occur over Tor. There is also an application called “apt-transport-https” that is already installed in Ubuntu that we’ll use.

After reviewing the existing Ubuntu updates mirrors in the USA, I found that Wikimedia has a great TLS configuration. Please contribute to the Google Doc list!

First add Tor Project’s Debian/Ubuntu repository to your system for up-to-date Tor software: https://www.torproject.org/docs/debian.html.en

Then perform the following:

sudo apt-get update

sudo apt-get install apt-transport-tor

sudo vim /etc/apt/sources.list

Edit “sources.list” to just use only “deb”. “deb-src” is only needed if you build from source which most people do not. You can safely delete the deb-src lines from the file. Replace all of the default Ubuntu repos with Wikimedia’s and be sure to add “tor+” before the “https”. Doing so adds end-to-end encryption via HTTPS, and it becomes Torified meaning network adversaries will have a more difficult time analyzing what software and what versions of said software are installed on your web server.

deb tor+https://mirrors.wikimedia.org/ubuntu/ xenial main restricted universe multiverse
deb tor+https://mirrors.wikimedia.org/ubuntu/ xenial-updates main restricted universe multiverse
deb tor+https://mirrors.wikimedia.org/ubuntu/ xenial-backports main restricted universe multiverse
deb tor+https://mirrors.wikimedia.org/ubuntu/ xenial-security main restricted universe multiverse
deb tor+https://deb.torproject.org/torproject.org xenial main

All your future apt-get update, upgrade, and dist-upgrade commands will now be performed over Tor and using high-grade HTTPS.

Firewall changes

If you use UFW to manage your iptables firewall rules, and if you’re properly restricting outbound connections, below is what your config might change to. First reset your UFW rules:

sudo ufw reset

Then:

sudo ufw limit 22/tcp
sudo ufw allow 443/tcp
sudo ufw allow out 22/tcp
sudo ufw allow out 25/tcp
sudo ufw allow out 53/udp
sudo ufw allow out 443/tcp
sudo ufw allow out 9050/tcp
sudo ufw deny out to any
sudo ufw enable
sudo ufw status verbose

Or with one command:

sudo ufw limit 22/tcp && sudo ufw allow 443/tcp && sudo ufw allow out 22/tcp && sudo ufw allow out 25/tcp && sudo ufw allow out 53/udp && sudo ufw allow out 443/tcp && sudo ufw allow out 9050/tcp && sudo ufw deny out to any && sudo ufw enable && sudo ufw status verbose

This UFW (iptables) rule set makes it so brute forcing SSH won’t work and allows all incoming HTTPS traffic. These rules also make it so no traffic can leave the web server unless it is SSH (22), SMTP (25), DNS (53), HTTPS (443), or Tor Socks (9050) traffic. Most web servers do not go as far as block all outbound traffic by default, but it is important in case the web server does become compromised. I would usually allow outbound HTTP (80) traffic because the default Ubuntu update repositories require HTTP. However, we will be Torifying Apt so that’s why we allow outbound 9050/tcp. If you don’t want to Torify Apt, you’ll need to allow outbound 80/tcp instead of 9050/tcp.

Debian update repos: transport security and privacy

Some friends and I have started thinking about ways to bring attention to this important issue.

In short, network adversaries can view not only what repositories your server operating system connects to (metadata), when (metadata), but precisely which updates are being applied. This allows a network adversary to not only know what vulnerabilities your operating system and applications are vulnerable to, but they know what applications are installed and likely running.

This critical issue is aside from the fact that most repository signing keys are using 1024-bit keys, some of which created in 2004 and do not expire. This is also aside from the fact that there are many man-in-the-middle attacks that HTTP is vulnerable to that high-grade HTTPS is not.

Further, no different than standard HTTP / HTTPS web browsing, non-Torified traffic is vulnerable to all types of Certificate Authority, Domain Name System, and Border Gateway Protocol attacks. It is equally critical to discuss apt-transport-tor.

Debian claims that HTTPS is not for privacy. In August 2014, B_Meson filed a bug on this issue, and it was closed.

Debian claims that apt-secure is good enough for security. This boils down to: “By adding a key to apt’s keyring, you’re telling apt to trust everything signed by the key.” Debian cannot assure that these keys have not been compromised. In Ubuntu, there is still a 1024-bit master signing key from 2004 in the apt-key keychain that does not expire!

I’ve purchased “apt-transport-https.org” (not active) presuming that this will be the homepage for this initiative. The initiative includes documenting popular repos, grade their SSL/TLS, and shame organizations that are neglecting our security and privacy. Default security and privacy is a requirement.

Below is my initial list of popular repositories. Most fail. I am looking for feedback and advice on how we should document these problems and how we can best influence repository maintainers to care about modern security concerns.

Basically…

  • http is bad.
  • https is better for security.
  • tor+http is better for privacy.
  • tor+https is better for security and privacy.
  • http .onion is best for security and privacy.

Questions

  • Does apt-transport-https support configurations such as PFS, HSTS, HSTS Preload, or HPKP?
  • Can installing apt-transport-tor be configured to automatically replace known repos with an Onion replacement in sources.list?
  • Post-Snowden, why isn’t apt-transport-tor the default for all OS distributions?

Defaults

Debian OS:
http://httpredir.debian.org/
http://security.debian.org/

Ubuntu OS:
http://us.archive.ubuntu.com/
http://security.ubuntu.com/

Tails OS (using apt-transport-tor by default):
tor+http://deb.tails.boum.org/
tor+http://deb.torproject.org/
tor+http://ftp.us.debian.org/
tor+http://security.debian.org/

Subgraph OS (using apt-transport-tor by default):
tor+https://devrepo.subgraph.com/
tor+http://security.debian.org/
tor+http://httpredir.debian.org/

Kali OS:
http://http.kali.org/
http://security.kali.org/

Optional

Debian nor Ubuntu distinguishes HTTPS mirrors:

Debian OS mirrors (ideal):
http://m4dcywym6p6poxdm.onion/debian/ (Info: http://onionmirors63y7c.onion/)

Ubuntu PPAs:
http://ppa.launchpad.net/

Tor Project, Inc apps:
https://deb.torproject.org/

Notes

An excellent discussion concerning Tails. Tails is a Debian based client and has different threat models than Debian based servers.

I’ve started a Google Doc list grading mirrors.

Configurations

Here’s what an improved Ubuntu configuration might look like:

sudo apt-get install apt-transport-tor
sudo vim /etc/apt/sources.list
deb tor+https://ubuntu.wikimedia.org/ubuntu/ wily main restricted
deb tor+https://ubuntu.wikimedia.org/ubuntu/ wily-updates main restricted
deb tor+https://ubuntu.wikimedia.org/ubuntu/ wily universe
deb tor+https://ubuntu.wikimedia.org/ubuntu/ wily-updates universe
deb tor+https://ubuntu.wikimedia.org/ubuntu/ wily multiverse
deb tor+https://ubuntu.wikimedia.org/ubuntu/ wily-updates multiverse
deb tor+https://ubuntu.wikimedia.org/ubuntu/ wily-backports main restricted universe multiverse
deb tor+https://ubuntu.wikimedia.org/ubuntu/ wily-security main restricted
deb tor+https://ubuntu.wikimedia.org/ubuntu/ wily-security universe
deb tor+https://ubuntu.wikimedia.org/ubuntu/ wily-security multiverse

Debian example:

sudo apt-get install apt-transport-tor
sudo vim /etc/apt/sources.list
deb tor+http://m4dcywym6p6poxdm.onion/debian/ jessie main
deb tor+http://m4dcywym6p6poxdm.onion/debian/ jessie-updates main
deb tor+http://security.debian.org/ jessie-updates main

GlobaLeaks and SecureDrop: which is right for you?

GlobaLeaks and SecureDrop are both secure and anonymous document submission systems. However, there are important differences between the two that must be understood before choosing either.

TL;DR

Use SecureDrop to best defend legally privileged work, or when utmost security is needed.

Use GlobaLeaks if:

  • You or your organization needs an internal auditing and/or whistleblowing platform, a survey/questionnaire platform, or a file submission platform.
  • You or your organization does not have dedicated technical support to properly manage SecureDrop.
  • You or your organization wants to trial-run a secure and anonymous document submission system to understand the policy and procedural impacts before investing in SecureDrop.
  • You or your organization cannot monetarily afford the SecureDrop infrastructure.

Similarities

  • Both systems are free software.
  • Both are regularly audited by independent software security firms, and the audit results are published.
  • Both use the Tor network to support user anonymity.
  • Both require consistent administration and updates to maintain software security.
  • Both require careful thought about the system’s physical security.
  • Both require careful thought about organizational policy changes and the organizational procedural changes.

Differences

There are many important consequences of their usability decisions. Always perform a careful threat assessment before deploying, and periodically after deployment.

GlobaLeaks

Docs: https://github.com/globaleaks/globaleaks/wiki

GlobaLeaks aims for ease-of-use for both the administrator and users. GlobaLeaks only requires one small Ubuntu 14.04 x86-64 system with root or sudo privileges for installation and system updates. Anyone with basic Linux systems administration can install GlobaLeaks onto, for example, a $200 laptop. Freedom of the Press foundation recommends the Intel NUC for SecureDrop, and that is a good system choice for GlobaLeaks, too.

The administrator needs to be able to install GlobaLeaks onto an Ubuntu system, either Virtual Machine (VM) or computer. After Ubuntu is installed, the GlobaLeaks install script is super simple. Once the install script has completed, the end of the install script will report the Onion site for submissions and administraiton.

GlobaLeaks is incredibly flexible. An administrator could choose to install their GlobaLeaks instance in “the cloud” (someone else’s computer). But there are many security and legal consequences if you have someone else manage the service. The security consequences include the risks associated with hosting sensitive material in a virtual machine that is shared with an unknown amount of unknown people or organizations. Shared virtual hosting environments are notorius, especially if you are trying to keep the location of your Onion service hidden. Additionally, if your work is threatening to any adversary, getting services shutdown or losing access to materials is a higher risk if a 3rd party manages it.

My first encounter with GlobaLeaks was in 2012 when I met one of the core developers at a Tor hackathon. I was so inspired by the project that I wrote the first GlobaLeaks Wikipedia article to help bring attention to the project. Since I’m not a developer, information activism is one of the best things that I can do to support free software and the amazing people that choose to work on free software.

I’ve deployed GlobaLeaks for several small projects. One of the projects needed a secure and anonymous document submission system (non- privileged, professional work), and another needed a secure and anonymous questionnaire to support a privacy-technology workshop.

SecureDrop

Docs: https://securedrop.readthedocs.org/en/latest/

SecureDrop aims to be as secure as possible for both the administrator and users. Administration requires intermediate Linux systems administration expertise. Once SecureDrop has been deployed, administration can only be performed locally and is command line only. Further, it is ideal for there to be an administration team, but not everyone needs to have technical skills. It is very important to understand the different systems needed and the roles they play.

SecureDrop requires, at a minimum, four independent but low-power x86-64 computer systems. The four computer systems are necessary to properly compartmentalize specific SecureDrop properties for ideal security via defense-in-depth.

One of these computer systems is connected to the Internet, the SecureDrop web server. Contrary to the default option in GlobaLeaks, the SecureDrop web server is only accessible via Onion services. A second computer system connects to the web server for the sole purpose of event reporting. This is necessary so that if the web server experiences any issues, a dedicated, compartmentalized system will be alerted of trouble. The other two computer systems needed for SecureDrop should never be networked and are called “air-gapped”. One of the air-gapped computer systems is needed to perform administrative functions; namely, the creation of Tails Linux USB drives. The second air-gapped computer system is solely used for reviewing SecureDrop submissions. Both of the air-gapped computer systems run Tails linux.

My first and only SecureDrop deployment was for the ACLU of Washington, which is really incredible. ACLU-WA was many firsts:

– The first non- journalist organization in the world.
– The first ACLU organization.
– The first legal organization.
– The first organization in the Pacific Northwest.

At ACLU-WA, there was a desire to begin experimenting with secure submission systems as an alternative to existing, common forms of communication like e-mail and HTTPS forms that come with inherent vulnerabilities. This decision was made without a fully developed sense of what the myriad internal policy implications would be. We knew ahead of deployment that a system like SecureDrop would pose certain organizational policy and procedural consequences, but waited until after receiving our first submission to finalize all our administrative practices. Most importantly, we know that existing legal intake methods used by legal organizations pose concrete risks because they all depend on communication systems that are not designed to withstand certain passive surveillance systems.

I was not part of ACLU-WA staff or part of the technical team that installed SecureDrop. My voluntary role at ACLU-WA was to design the landing page, to create our advanced threat modeling page, to advise on website and SecureDrop hardening, and to advise on organizational policy changes.

An open letter for organizations to support Tor onion services

DRAFT 1

There was a time when organizations used to ask the question, why would we want to use the Internet? There were no easy paradigms for business leaders to understand the implications. Early adopters of the Web slowly learned the value and effects of persistent information broadcasting, including reach into new and unexpected audiences. These organizations not only seeded their presence in online communities, but online communities started to shape the motivations and goals of organizations.

Following the early adoption phase, mass adoption took hold and organizations deepened their understanding. It became clear that connecting with people on this extraordinary level is not without risk and that businesses need to incorporate organizational information assurance policies. Since the beginning, encryption has been critically important to protect business interests.

Organizations are still in the process of adapting to new paradigm shifts. We take for granted TCP protocols that make web pages show up, complete, on user’s screens, because we consider that satisfactory. We take for granted the increasing affordability of data storage because we can do more for less. We not only ignore the effects of billion-dollar industries the are built and driven by the collection of personal data, but we support those industries by focusing on usability and profit. At what point do we ask the question, how much do we actually love our users?

In 2013, a significant opportunity opened up that allows organizations that use Information and Communication Technologies to understand the unintended consequences of clear-text content and metadata sharing. As more and more users depend on the services that organizations provide, organizations are learning more and more about how their technology and policy choices affect their users.

We have reached a point that it is no longer ethically acceptable to claim that our services, and thus our users, do not require both default security and also a choice in security technologies. It is no longer ethically acceptable to prioritize the security of our databases over the security and empowerment of our users.

Employing high-grade HTTPS is step one in adapting to the use of open standards and protocols. However, HTTPS reinforces the use of centralized trust authorities that, fundamentally, have deep security problems of their own. Organizations have long had the opportunity to leverage a free and decentralized security technology, and that technology is called Tor onion services.

Tor onion services mitigate many wide-spread security concerns including Certificate Authority attacks, Border Gateway Protocol attacks, and Domain Name System attacks. Adopting Tor onion services also happens to empower our users by giving them greater autonomy and control of their data and information. We can never understand individualized threat models for all our users; it is our responsibility to first admit that we will never understand such a complex landscape, and second we must employ this free and adaptive technology that raises the bar of security best practices.

Signed,

What is encryption, anyway?

When we stand in front of someone and speak to that privileged individual “in real life,” we are generally aware of our environment.

We can easily asses that our communication is confidential because we can autonomously choose to speak when unprivileged people are not physically around to listen in.

We know that our communication has perfect integrity because we are physically present, observing and assuring that the speech is not getting messed with.

We also know that our communication is authentic because we are physically near the intended individual actively verifying them.

The foundation to communications confidentiality, integrity, and authenticity is trust, and the only way that we can assure technology-driven communication is trustworthy is with encryption.

Encryption is the technological requirement to assuring the foundation of trust that we fundamentally lose when people cannot be physically near.

Create an anonymous document drop with any Android

Honestly I have no idea why I didn’t think about this before. I’m sorry it’s taken so long. This guide will show you how to use any Android to host a Tor hidden service and send it files from anywhere in the world with SSH or SCP. I tested this with a Nexus 6 (shamu) running Android 6 but I will test this on Android 4.4.4 soon. Root is not needed, you could perform these steps on any Android. Play around with this. I do not currently have a lot of confidence (stability) in an Android (Wifi), SSHelper (app), Orbot (app), and Tor (circuit) hidden-service combination. But I’ll try this out on an extra Android and see if I can still access it after a week or so and update the post.

Much wow.

There are several amazing things about this setup:

1. Easy. It’s so easy, omg. Even securing the Android is super easy with this narrow of use case.

2. Cheap. Like, as little as $10 cheap, or, “can I have your old Android for free, please” cheap.

3. You could drop a burner Android, using any Wifi you can connect to, in so many places. And if you don’t have a wall outlet where it could sit and charge forever, you could have several days or weeks worth of uptime before it dies.

Guide

0. Buy a cheap Android in person with cash, you may prefer one with an SD card slot for additional storage. Go to a coffee shop you’ve never been that has free Wifi. Turn on your Android and connect to the public Wifi. Create a new Google account with an unattributable username and password. Put the phone into airplane mode then reactivate the Wifi. Disable any apps and services not needed (dependent on the device) then install any Android OS or app updates that are necessary. Ensure the Android’s storage is encrypted, and ensure that devices access requires a long passphrase for boot and for device entry.

Note on “buy any Android” — some burners that I’ve purchased before, like a $30 one from Verizon, forces you to activate the device as soon as you turn it on, making it extremely difficult to control any aspect of Android until phoning home to Verizon and activating with a phone number. If you want to be sure you don’t have to deal with carrier crap, spend a little more and go with an unlocked Moto E for $120. The 1st Gen and 2nd Gen Moto E’s conveniently support a 32GB microSD.

1. Download “Orbot: Proxy with Tor” (by: The Tor Project) from the Play Store. Open “Orbot”. Go into settings and scroll down to “Hidden Service Hosting” and enable “Hidden Service Hosting”. Tap “Hidden Service Ports” and enter “2222”. Back out of settings and long-press the power button to connect to the Tor network. Go back into settings then scroll down and tap “.Onion Hostname” to view your hidden service address. Document that address on your laptop with Tails or Torified SSH ready to go.

2. Download “SSHelper” (by: Paul Lutus) from the Play Store. Open the “SSHelper” app. That’s it. The default user is “admin”, default password is “admin”. The default ssh, scp, and rsync directory is your normal user’s home directory, which is one below the virtualized (or real) “SDCard”. I was able to connect with an ECDSA key pair.

3. Download “NetGuard – no-root firewall” (by: Marcel Bokhorst) from the Play Store. Open “NetGuard”. In the top right corner are three vertically aligned dots. Tap that button to enter into the Settings menu. Activate “Block Wi-Fi by default”, “Block mobile by default”, and “Manage system applications”. Click back to save the settings changes. Now scroll down and find “Orbot” and tap the orange Wifi icon (it will turn from a striked-out orange icon to a green icon) which will allow it to access the network over Wifi only. Scroll down a little bit more to “SSHelper” and tap the orange Wifi icon to give it Wifi access too. Now at the very top, to the right of “NetGuard”, tap the switch icon to activate your firewall rules. Accept (OK) the two prompts that follow.

Your Android is now ready to go.

4. From your Linux or OS X command line interlace (CLI), you should now be able to send it any files. It only took 22 seconds for me to transfer an 8 MB PDF:

scp -P 2222 bulletproof-ssl-and-tls.pdf admin@c3dznupj493fgtd5j.onion:.

Torify SSH (Ubuntu) for connecting to hidden service addresses

Install tor and openssh-client. Then:

sudo vim /etc/ssh/ssh_config

Add (under “Host *”)

proxyCommand ncat --proxy 127.0.0.1:9050 --proxy-type socks5 %h %p

Then:

sudo service ssh restart

YubiKey 4 and Ubuntu 15.10

yubi4

sudo apt-add-repository ppa:yubico/stable

sudo apt-get update

from: https://github.com/Yubico/yubioath-desktop

sudo apt-get install python-setuptools python-crypto python-pyscard python-pyside pyside-tools libykpers-1-1 pcscd -y

sudo apt-get install yubioath-desktop yubikey-personalization yubikey-personalization-gui -y

Insert YubiKey 4 (the ‘Y’ flashes green every ~4 seconds).

yubikey4start

yubikey4main

Now you’re set! https://www.yubico.com/support/documentation/

For easy Google 2FA (Thanks Yael): https://support.google.com/accounts/answer/6103534?hl=en

Custom stamp for my Signal fingerprint

I ordered a self-inking, custom, wood “1.25 x 2 Rubber Stamp” from rubberstamps.net. I ordered it on a Monday and got it the following Thursday.

Text Line 1: +1.XXX.XXX.XXXX
Text Line 2: 05 b8 6d 44 95 5c 5b 6b f5
Text Line 3: 61 09 22 33 05 b2 c4 c5 db
Text Line 4: f3 85 4a 4b a1 e8 aa 12 36
Text Line 5: 70 20 19 00 0e 4c .. .. ..

Font: Courier New (for all lines)
Justification: L (for all lines)
Style: Bold (for the first line only)

Ink: (added separately) Versafine, crimson red

I added the “.. .. ..” at the end because the preview seemed like it was going to auto adjust toward the center a little bit. I did this to be safe, but it might not be needed.

With 3-5 business days shipping, the total was $29.12.

Top
IMG_20151119_175903

Bottom
IMG_20151119_175911

Card (before)
IMG_20151119_180048

Card (after)
IMG_20151119_180147

Highly recommended!

A guide for journalists that need to defend their work from governments

This is a brain dump guide that may be expanded depending on feedback. The goal is for a journalist to be able to keep all of their work “in the cloud” (on a personally controlled Tor hidden service) and not keep any sensitive data with them when they travel.

Most journalists are not able to commit to the requirements (high technical competency) of this guide. Dedicated journalists should consult with a technical expert that they trust.

Skeleton guide

1. Find some secure and stable places to host a few Tor hidden service web hosts. Choose different places that small actors (non-targeted malice, etc) and big actors (targeting by private companies, local law enforcement searches, intelligence agencies, etc) would have trouble finding. Inexpensive “netbooks” are great options because they are portable, inconspicuous, have built in batteries, surge protectors, and RAM that’s integrated into the system board (can’t be removed for evil maid attacks). Always presume adversaries will find them, so always use layered security.

1.1. The web hosts must at least be behind a basic firewall, even a residential Internet connection using NAT. The host itself must not have any externally-accessible ports, must employ LUKS disk encryption, and must be running the most current version of Tor. OwnCloud Community edition or WordPress are ideal platforms that allow remote uploading of files or note taking. Access to the web resource must be hardened and password protected in case a random adversary is able to uncover the hidden service address.

1.2. Physical access to the host, and remote access to the host, must require high-entropy passwords. You must remember them, or you must have a secure way of documenting and retrieving them like disposable SpiderOak accounts. Never carry passwords or your hidden service addresses with you. Two-factor authentication options cannot be used because you must presume said authentication devices will be taken from you.

1.3. Hosting multiple Tor hidden service web servers, for redundancy, can be configured to automatically sync with each other via Tor.

2. Carry the following:

2.1. An inexpensive laptop that has an unencrypted hard drive and operating system that has some “use” (don’t ever use it). Some passive-search actors will force you to turn on the device to demonstrate its legitimacy. Turning it on and opening apps keeps the friction low between you and your adversary. Always presume that adversaries will take it all from you. If any device is taken from you and removed from your sight, dispose of the device immediately.

2.2. Several USB drives with Tails Linux, and in different locations (on-person necklace, pockets, bags). If you’re able to maintain ownership of at least one, and you trust it was not tampered with, you won’t need to create a new one after passing through security check points.

2.2.1. Presume that the drives will be confiscated, so you must know how to recreate a Tails drive from any operating system. Don’t use pre-created drives if you think leaving them behind in “secure” places will help you. And don’t mail pre-created drives to yourself, they are trivially intercepted. Plan ahead to determine where you can create a new Tails drive, such as a retail electronics store or a local library. If you can’t assure that your Tails drive is clean, and your computer is free from any hardware or firmware compromise, do not access your Tor hidden service resources.

InfoCamp Seattle: The privacy web application called Tor

The Tor Project

https://www.torproject.org/


How to: Use Tor for Windows

by Electronic Frontier Foundation
https://ssd.eff.org/en/module/how-use-tor-windows

How to: Use Tor on Mac OS X

by Electronic Frontier Foundation
https://ssd.eff.org/en/module/how-use-tor-mac-os-x


torbrochure

Spread the word about Tor

by The Tor Project
https://blog.torproject.org/blog/spread-word-about-tor


torhops

Everything about Tor

by Tom Ritter
https://ritter.vg/p/tor-vlatest.pdf


torstinks

NSA and GCHQ target Tor network that protects anonymity of web users

by The Guardian
http://www.theguardian.com/world/2013/oct/04/nsa-gchq-attack-tor-network-encryption


Tor exit relays in libraries: a new LFP project

by Alison Macrina
https://libraryfreedomproject.org/torexitpilotphase1/


Configuring a Tor relay on Debian/Ubuntu

https://www.torproject.org/docs/tor-relay-debian.html.en

Configuring Hidden Services for Tor

https://www.torproject.org/docs/tor-hidden-service.html.en

Tor: Bridges

https://www.torproject.org/docs/bridges.html.en


Building Enterprise Tor Onions: Tips and Notes

by Alec Muffett
https://storify.com/AlecMuffett/tor-tips

How to Get a Company or Organisation to implement an Onion Site, i.e. a Tor Hidden Service

by Alec Muffett
https://www.facebook.com/notes/alec-muffett/how-to-get-a-company-or-organisation-to-implement-an-onion-site-ie-a-tor-hidden-/10153762090530962


Tor Hidden (Onion) Services Best Practices

by Rise Up
https://help.riseup.net/en/security/network-security/tor/onionservices-best-practices


SecureDrop

https://securedrop.org/


The Official SecureDrop Directory

by Freedom of the Press Foundation
https://freedom.press/securedrop/directory


Organizations Supporting Tor: Help Us Help You!

by ACLU of Washington
https://aclu-wa.org/blog/organizations-supporting-tor-help-us-help-you


City of Seattle could lead privacy and transparency efforts with SecureDrop and Tor

by ACLU of Washington
https://yawnbox.com/?p=3742


Tor outreach materials

by The Tor Project
https://people.torproject.org/~lunar/outreach-material/


Tails Linux

https://tails.boum.org/


Orfox: Tor Browser for Android

by The Tor Project
https://play.google.com/store/apps/details?id=info.guardianproject.orfox

Orbot: Proxy with Tor

by The Tor Project
https://play.google.com/store/apps/details?id=org.torproject.android


Anonabox

https://www.anonabox.com/

Invizibox

https://www.invizbox.io/