Urban@UW individual questions

1. How would you define the question/ challenge/ focus in a manner that you find compelling?

Privacy has been defined by different groups indifferent ways. Often times the best way to protect personal privacy rights is to empower people to have greater control over what data is shared. Policy makers need to think broadly and specifically about the unintended consequences of data collection, not just how valuable it can be to special interests. Supporting privacy initiatives is often something that can turn into government transparency, accountability, and trust. Seattle could exclusively adopt free software solutions when deploying technology that interfaces with the public.

Two related points:

White House Commits to Open Access, Open Education and Open data in New Open Government Plan

Emerging threats for lawyers and human rights defenders: surveillance on massive scale in real time

Concerns from others in the group:

— Justice?
— Democratizing data?
— Supporting an advocacy agenda?
— Access? Affordability? Income barriers? How to keep people out of the criminal justice system?
— What is the overarching process for developing questions about data?
— Is the data driving the questions, instead of the questions driving the data? Who owns the data?
— Who gets to frame the questions? Who gets to think about how the data is used?
— Public vs private sector influence?

2. What is the most important need or area of impact that we could have addressing this challenge?

3. What is needed to address this challenge and what are the gaps to fulfilling this need?

4. What has failed in the past, and why?

5. What risks are there?

6. Who else should be involved?

7. What’s missing from this challenge, as you see it?

Comparing HTTP, HTTPS, VPN, and Tor with “snail mail” metaphors

Revision 76

The goal of this article is to break down how the Tor network protects your network metadata. All of the examples are based on what is commonly done in order to best represent reality. I only look at basic network operations and some basic network attacks, not client side, server side, Tor bridge, or Tor authority attacks. I may expand this article later to include more complex scenarios. In general, “HTTP” and “HTTPS” could be replaced with other, similar clear-text or encrypted transport protocols. Special thanks to Edward Snowden for giving the world factual evidence about network adversary capabilities that degrade fundamental human rights and intellectual freedoms.

I often meet intelligent people who are misinformed about what Tor allows people to do. Having this article allows me to share it with them so they can constructively point out which process(es) they’re criticizing. Sometimes people are right but fail to juxtapose an alternative technology’s vulnerabilities, like HTTPS or a VPN. Sometimes people are right but ignore probabilistic or subjective threat models. Tor is a complex system and requires thorough understanding.


1. HTTP and “snail mail”

If you’ve ever mailed a postcard to friends or family, you should understand this metaphor.

High-level primer:
message (1a), sender (1b) > recipient (1c)

1.1.1. The postcard has no protection; anyone who handles the postcard can read the message (1a), who sent it (1b) and who received it (1c).

HTTP Vulnerabilities

message (1a), sender (1b) > recipient (1c)

1.2.1. Your ISP always monitors and records (1b) and (1c) metadata, and can easily monitor or record (1a) content.

1.2.2. It is trivial for dragnet surveillance programs to monitor and record (1a), (1b), and (1c).

1.2.3. Nothing stops a network adversary from blocking (2c) access, such as an IP or DNS filter.

1.2.4. Very little can stop a network adversary from censoring or altering (1a), or reroute/MitM the traffic to malicious resources.


2. HTTPS and “snail mail”

If you’ve ever mailed a hand-written or typed letter, you should understand this metaphor.

High-level primer:
message (2a), sender (2b) > recipient (2c)

2.1.1. The letter has one layer of protection, the envelope. Anyone who handles the enclosed letter can read who sent it (2b) and who received it (2c).

2.1.2. The recipient (2c) can read the letter (2a); they know who sent (2b) the letter, so they know who to reply to (2b).

HTTPS Vulnerabilities

message (2a), sender (2b) > recipient (2c)

2.2.1. Your ISP always monitors and records (2b) and (2c) metadata.

2.2.2. It is trivial for dragnet surveillance programs to monitor and record (2b) and (2c) metadata.

2.2.3. Nothing stops a network adversary from blocking (2c) access, such as an IP filter.

2.2.4. If the recipient is 1) not enforcing strong TLS encryption protocols, 2) not using strong TLS cipher suites, or 3) is poorly configured, nothing stops a targeted attacker from capturing the traffic 1) at any intermediary infrastructure between the sender and the recipient or 2) inside the recipient’s compromised infrastructure. Once captured, the adversary can 1) remove the outer envelope (breaking weak SSL/TLS) to read the content, or 2) reroute/MitM the traffic to malicious resources.


3. VPN and “snail mail”

High-level primer:
content (3a), sender (3b) > traffic proxy (3c) > recipient (3d)

Adjusted metaphor:
message (3a), sender (3b) > mail proxy (3c) > recipient (3d)

VPN without HTTPS (postcard)

message (3a), sender (3b) > mail proxy (3c) > recipient (3d)

3.1.1. Take your postcard and write the recipient name and address (3d) along with the name and address (3c) of the company you’ve paid to proxy your postcard.

3.1.2. Enclose the postcard into an envelope. Destination: mail proxy name and address (3c), origination: your name and address (3b).

3.1.3. Now send the enclosed postcard. Your mail proxy will remove the envelope then send the now-naked postcard to the recipient. The mail proxy (3c) can read the message (3a). They know who sent (3b) the postcard and where the it’s going (3d).

3.1.4. The recipient (3d) can read the postcard (3a); they know where the postcard came from (3c), so they know who to reply to (3c).

VPN with HTTPS (letter)

message (3a), sender (3b) > mail proxy (3c) > recipient (3d)

3.2.1. Take your letter and enclose it in an envelope. Put the recipient name and address (3d) on the envelope along with the name and address (3c) of the company you’ve paid to proxy your letter.

3.2.2. Enclose the letter into a second envelope. Destination: mail proxy name and address (3c), origination: your name and address (3b).

3.2.3. Now send the letter. Your mail proxy (3c) will remove the outermost (second) envelope then send the letter to the recipient (3d). The mail proxy (3c) knows who’s sending (3b) the letter and where the letter is going (3d).

3.2.4. The recipient (3d) can read the letter (3a). They know where the letter came from (3c) and who to reply to (3c).

VPN Vulnerabilities

content (3a), sender (3b) > traffic proxy (3c) > recipient (3d)

3.3.1. Your ISP always monitors and records (3b) and (3c) metadata.

3.3.2. With data retention, it is trivial for adversaries to obtain anything your ISP knows.

3.3.3. Global dragnet surveillance programs always monitor and record popular VPN (3c) metadata.

3.3.4. It is probable that dragnet surveillance programs automatically correlate (3b), (3c), and (3d) traffic because of its simplicity.

3.3.5. If your proxy has 1) data retention, 2) has been forced by it’s regional government to have data retention and gagged not to disclose its data retention, 3) uses insecure protocols, 4) insecure cipher suites, or 5) is poorly configured, (3b), (3c), and (3d) metadata become vulnerable. The one-hop proxy knows everyone’s identity, and they probably have your credit card number.

3.3.6. Nothing stops a network adversary from blocking (3c) or (3d) access, such as an IP filter.

3.3.7. If the proxy or recipient is 1) not enforcing strong TLS encryption protocols, 2) not using strong TLS cipher suites, or 3) is poorly configured, nothing stops a targeted attacker from capturing the traffic 1) at the one-hop proxy, 2) at any intermediary infrastructure between the one-hop proxy and the recipient, or 3) inside the recipient’s compromised infrastructure. Once captured, the adversary can 1) remove the outer envelope (breaking weak SSL/TLS) to read the content, or 2) reroute/MitM the traffic to malicious resources.


4. Tor and “snail mail”

There is no Tor equivalent to “snail mail,” so this is what it would look like.

High-level primer:
content (4a), sender (4b) > Tor guard relay (4c) > Tor middle relay (4d) > Tor exit relay (4e) > recipient (4f)

Adjusted metaphor:
message (4a), sender (4b) > first mail proxy (4c) > second mail proxy (4d) > third mail proxy (4e) > recipient (4f)

Tor without HTTPS (postcard)

message (4a), sender (4b) > first mail proxy (4c) > second mail proxy (4d) > third mail proxy (4e) > recipient (4f)

4.1.1. Take your postcard and put the name and address of the recipient (4f) on the front along with the name and address of the third proxy (4e) as the sender.

4.1.2. Enclose the postcard in an envelope. Destination: third mail proxy (4e), origination: name and address of the second mail proxy (4d).

4.1.3. Enclose the postcard in a second envelope. Destination: second mail proxy (4d), origination: name and address of the first mail proxy (4c).

4.1.4. Enclose the postcard in a third envelope. Destination: fist mail proxy (4c), origination: your name and address (4b).

4.1.5. Now send the postcard. The first mail proxy (4c) will remove the outermost (third) envelope and send it to the second mail proxy (4d). The first mail proxy (4c) only knows who sent (4b) the letter and where it’s going (4d).

4.1.6. The second mail proxy (4d) will remove the outermost (second) envelope and send it to the third mail proxy (4e). The second mail proxy (4d) only knows who sent (4c) the letter and where it’s going (4e).

4.1.7. The third mail proxy (4e) will remove the outermost (first) envelope and send the postcard on to the recipient (4f). The third mail proxy (4e) can read the postcard (4a). They know who sent (4d) the postcard and where it’s going (4f).

4.1.8. The recipient (4f) can read the postcard (4a). They know where the postcard came from (4e) and who to reply to (4e).

Tor with HTTPS (letter)

message (4a), sender (4b) > first mail proxy (4c) > second mail proxy (4d) > third mail proxy (4e) > recipient (4f)

4.2.1. Take your letter and enclose it in an envelope. Put the name and address of the recipient (4f) on the front along with the name and address of the third proxy (4e) as the sender.

4.2.2. Enclose the letter in a second envelope. Destination: third mail proxy (4e), origination: name and address of the second mail proxy (4d).

4.2.3. Enclose the letter in a third envelope. Destination: second mail proxy (4d), origination: name and address of the first mail proxy (4c).

4.2.4. Enclose the letter in a fourth envelope. Destination: fist mail proxy (4c), origination: your name and address (4b).

4.2.5. Now send the letter. The first mail proxy (4c) will remove the outermost (fourth) envelope and send it to the second mail proxy (4d). The first mail proxy (4c) only knows who sent (4b) the letter and where it’s going (4d).

4.2.6. The second mail proxy (4d) will remove the outermost (third) envelope and send it to the third mail proxy (4e). The second mail proxy (4d) only knows who sent (4c) the letter and where it’s going (4e).

4.2.7. The third mail proxy (4e) will remove the outermost (second) envelope and send the letter on to the recipient (4f). The third mail proxy (4e) only knows who sent (4d) the letter and where it’s going (4f).

4.2.8. The recipient (4f) can read the letter (4a). They know where the letter came from (4e) and who to reply to (4e).

Tor Vulnerabilities

Keep in mind that Tor circuits are generated randomly, are required to have significant international hops, and are created every time a Tor user starts a new Tor Browser session. Tor user and Tor relay diversity and volume are critical.

content (4a), sender (4b) > Tor guard relay (4c) > Tor middle relay (4d) > Tor exit relay (4e) > recipient (4f)

4.3.1. Your ISP always monitors and records (4b) and (4c) metadata.

4.3.2. With data retention, it is trivial for adversaries to obtain anything your ISP knows.

4.3.3. Global dragnet surveillance programs monitor and record known Tor exit relay (4e) metadata whenever possible.

4.3.4. Presuming that the Tor guard relay is not logging traffic, (4b), (4c), and (4d) metadata are not recoverable from the Tor guard relay.

4.3.5. Presuming that the Tor guard relay is logging traffic, the adversary will know (4b), (4c), and (4d) metadata. They cannot know (4e) or (4f) metadata with this relay alone. Most Tor relays are middle relays, and the guard flag is granted to middle relays and exit relays when it has good reputation (time, stability, no filtering). A Tor circuit cannot have any one relay fulfill two or more circuit roles.

4.3.6. Presuming that the Tor middle relay is logging traffic, the adversary will know (4c) and (4e) metadata, which is meaningless data. They cannot know (4b) or (4f) metadata with this relay alone. Most Tor relays are middle relays, and it takes reputation (time, stability, no filtering) for middle relays to be sent more traffic to process. A Tor circuit cannot have any one relay fulfill two or more circuit roles.

4.3.7. Presuming that the Tor exit relay is logging traffic, the adversary will know (4c) and (4e) metadata. They cannot know (4a) or (4b) metadata with this relay alone. Exit relays are explicitly set by the operator and can begin processing exit relay traffic as soon as it has an error-free connection to the Tor network. However, it takes reputation (time, stability, no filtering) for an exit relay to be sent more traffic to process. A Tor circuit cannot have any one relay fulfill two or more circuit roles.

4.3.8. An Adversary would have to own both the guard relay and the exit relay of any given circuit to conduct a successful network correlation analysis or attack. It is statistically improbable that any one adversary owns the circuit start and end nodes of a targeted user’s session. It is impossible for any one adversary to own any majority of relays, meaning it impossible for both ends of all circuits to be monitored all the time.

4.3.9. If the recipient is 1) not enforcing strong TLS encryption protocols, 2) not using strong TLS cipher suites, or 3) is poorly configured, nothing stops a targeted attacker from capturing the traffic 1) at the Tor exit relay, 2) at any intermediary infrastructure between the Tor exit relay and the recipient, or 3) inside the recipient’s compromised infrastructure. Once captured, the adversary can 1) remove the outer envelope (breaking weak SSL/TLS) to read the content, or 2) reroute/MitM the traffic to malicious resources.

Hardening WordPress

Published: 2015-Oct-23
Updated: 2016-May-11

Applications configured

Ubuntu Server 14.04 – 16.04
Apache 2.4.20
MySQL 5.6.28
PHP 7.0.5
OpenSSL 1.0.2g
WordPress 4.5
Sendmail 8.14.9
OSSEC 2.8.3
apt-transport-tor 0.2.1
Let’s Encrypt

The TLS configuration in this article will get you a Qualys SSL Labs perfect A+ (100/100/100/100).

ssllabs_perfect

Things that should be in this guide but I still haven’t learned well:

— HPKP (key pinning, it still scares me)
— DNSSEC (my registrar doesn’t support it, serious wtf)
— Grsecurity kernel patches
— Torify Sendmail

Regularly test your transport security here: https://www.ssllabs.com/ssltest/analyze.html

Regularly test your security headers here: https://securityheaders.io/

SSH

sudo vim /etc/ssh/sshd_config

Comment out these lines:

#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key

Edit these lines:

ServerKeyBits 4096
LoginGraceTime 30
PermitRootLogin no

Add these lines:

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Done. Then:

sudo service ssh restart

Firewall

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 in one line…

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 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 traffic because the Ubuntu update repositories require HTTP… they’re not HTTPS which is extremely sad. 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.

I allow outbound SMTP traffic because I use Sendmail to send TLS encrypted email notifications.

I do not allow any inbound HTTP traffic, and it is because of HSTS Preload. All major browsers know to connect to my website via HTTPS and not HTTP.

Patch (securely)

Make sure your OS is current then restart:

sudo apt-get update

sudo apt-get dist-upgrade

sudo shutdown -r now

Get updates over Tor instead of HTTP. First install and configure Tor.

sudo vim /etc/apt/sources.list

Add these lines to the bottom:

deb http://deb.torproject.org/torproject.org wily main

Then:

sudo gpg --keyserver keys.gnupg.net --recv 886DDD89

sudo gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -

sudo apt-get install tor deb.torproject.org-keyring apt-transport-tor -V

Backup sources.list:

sudo cp /etc/apt/sources.list /etc/apt/sources.bak

Edit sources.list with tor+http:

sudo vim /etc/apt/sources.list

For example (add “tor+” to all active lines):

deb tor+http://us.archive.ubuntu.com/ubuntu/ wily main restricted

Add these PPAs so that Apache, MySQL and PHP will be up to date:

sudo add-apt-repository ppa:ondrej/apache2

sudo add-apt-repository ppa:ondrej/mysql-5.6

sudo LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/php

Be sure to Torify the new PPAs.

sudo vim /etc/apt/sources.list.d/ondrej-ubuntu-apache2-wily.list
deb tor+http://ppa.launchpad.net/ondrej/apache2/ubuntu wily main

And:

sudo vim /etc/apt/sources.list.d/ondrej-ubuntu-mysql-5_6-wily.list
deb tor+http://ppa.launchpad.net/ondrej/mysql-5.6/ubuntu wily main

And:

sudo vim /etc/apt/sources.list.d/ondrej-ubuntu-php-wily.list
deb tor+http://ppa.launchpad.net/ondrej/php/ubuntu wily main

Done. Then:

sudo apt-get update

All repositories should now read tor+http://… because they are routed through Tor. If any hang, it is likely because a repo was missed (and needs tor+) and is trying to connect using outbound HTTP port 80.

Now install the apps:

sudo apt-get update && sudo apt-get install apache2 libapache2-mod-evasive unzip nghttp2 nghttp2-server mysql-server-5.6 php7.0 sendmail -V

Sendmail config

sudo vim /etc/mail/sendmail.cf

Edit or add these lines:

O CipherList=ECDH+AES256:!3DES:!aNULL:!DES:!DSS:!eNULL:!EXP:!IDEA:!LOW:!MD5:!PSK:!RC4:!SEED
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_NO_TLSv1 +SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS +SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_NO_TLSv1 +SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS +SSL_OP_CIPHER_SERVER_PREFERENCE

This configuration assures that TLS will be used when sending mail to a destination mail server (not STARTTLS!). However, you’d still be using self-signed certs. Regardless, ECDH+AES256 is the only cipher being set because I know my email server receiving my alerts will use it.

sudo service sendmail restart

I can verify the TLS encryption in my received email headers:

Received: from yawnbox.com (mail.yawnbox.com. [38.140.26.46])
(version=TLS1_2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256/256);

After you install Let’s Encrypt certs, you may want to add these lines:

O ServerCertFile=/etc/letsencrypt/live/example.com/fullchain.pem
O ServerKeyFile=/etc/letsencrypt/live/example.com/privkey.pem
O DHParameters=/etc/ssl/private/dhparams_4096.dh.param

This would configure Sendmail to use the same certs that you will use for HTTPS, which is fine since it should be from the same TLD. However, if you have a mail server with valid certs already, you should use those certs instead here (like if your mail server certs are for mail.example.com).

Then:

vim /etc/php/7.0/apache2/php.ini

Uncomment and edit this line:

sendmail_path = /usr/sbin/sendmail -t -i

Then:

sudo service apache2 restart

Apache config

sudo vim /etc/apache2/mods-available/evasive.conf

Uncomment the first 6 lines. Change if needed. Edit the DOSEmailNotify line if you’d like to be alerted when a specific IP address gets blocked. Then:

sudo vim /etc/apache2/apache2.conf

Add these lines:

FileETag None
Header unset ETag
AuthnCacheSOCache shmcb

Edit this line:

Timeout 30

Done. Then:

sudo a2enmod headers http2 ssl socache_shmcb

Done. Then:

sudo vim /etc/apache2/conf-available/security.conf

Uncomment these lines:

Directory /
   AllowOverride None
   Require all denied
/Directory

Add these lines:

Header always set X-XSS-Protection: "1; mode=block"
Header always set X-Permitted-Cross-Domain-Policies: "master-only"
Header always set Cache-Control: "private, no-cache, no-store, must-revalidate"
Header always set Pragma: "no-cache"
Header always set Expires: "-1"
Header always set X-Content-Type-Options: "nosniff"
Header always set X-Frame-Options: "sameorigin"
Header always set Content-Security-Policy: "default-src 'self'"

Edit these lines:

ServerTokens Prod
ServerSignature Off
TraceEnable Off

Done. Then:

sudo service apache2 restart

Apache TLS config

Start by Generating 4096-bit DHparams. This will take a while (5+ minutes) depending on your server’s processing capabilities. These three lines may be something worth scripting to recreate every month via cron:

sudo openssl dhparam -out /etc/ssl/private/dhparams_4096.tmp 4096

sudo mv /etc/ssl/private/dhparams_4096.tmp  /etc/ssl/private/dhparams_4096.pem

sudo cp /etc/ssl/private/dhparams_4096.pem /etc/ssl/private/dhparams_4096.dh.param

Done. Then:

sudo vim /etc/apache2/mods-enabled/ssl.conf

Add these lines:

SSLCompression off
SSLSessionTickets off
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)
SSLOpenSSLConfCmd DHParameters /etc/ssl/private/dhparams_4096.pem
SSLOpenSSLConfCmd Curves secp384r1

Change these lines:

SSLRandomSeed startup file:/dev/urandom 4096
SSLRandomSeed connect file:/dev/urandom 4096

Uncomment and/or edit these lines:

SSLCipherSuite HIGH:!3DES:!aNULL:!DES:!DSS:!eNULL:!EXP:!IDEA:!LOW:!MD5:!PSK:!RC4:!SEED
SSLHonorCipherOrder on
SSLProtocol -all +TLSv1.2

Let’s Encrypt will modify your Apache default-ssl.conf file for you. After installing Let’s Encrypt, I made sure to create 4096-bit keys:

sudo ./letsencrypt-auto --apache -d example.com -d www.example.com --rsa-key-size 4096

Keep an eye on ECDSA key support.

Done. Then:

sudo vim /etc/apache2/sites-available/default-ssl.conf

Add these lines:

SSLEngine on
Header edit Set-Cookie ^(.*)$ $1;Secure;SameSite=Strict
Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'"

Add these lines under “/Directory” but before “/VirtualHost”:

#Protocols h2 http/1.1
H2Direct on
H2MaxSessionStreams 20
H2MaxWorkerIdleSeconds 20
H2MaxWorkers 20
H2MinWorkers 10
H2ModernTLSOnly on
H2SerializeHeaders off
H2SessionExtraFiles 10
H2StreamMaxMemSize 128000
H2TLSCoolDownSecs 0
H2TLSWarmUpSize 0
H2Upgrade on
H2WindowSize 128000

Now that HSTS and HSTS Preload are configured, submit your domain to Google for getting added to the Chrome HSTS Preload list:

https://hstspreload.appspot.com/

Doing so will eventually replicate to all other mainstream browsers. My experieince was that after submitting my domain for Preload, I had to wait a couple of weeks for it to show up in Chrome, and a couple more weeks to show up in Firefox. Tor Browser took the longest. Just be patient.

I keep the “Protocols h2 http/1.1” directive commented out because I can’t achieve a perfect Qualys SSL Labs score and force HTTP2. When I do, Chrome sometimes doesn’t load the website because the HTTP2 specification doesn’t accept some of the cipher suites with this configuration.

Also check out HTTP2 Explained.

Done. Then:

sudo a2ensite default-ssl.conf
sudo a2dissite 000-default.conf
sudo service apache2 restart

Basic MySQL hardening

sudo apt-get install mysqltuner
sudo mysqloptimize -p -u root -A -o
sudo mysqltuner

Make any of the recommended changes (then re-run mysqltuner):

sudo vim /etc/mysql/mysql.conf.d/mysqld.cnf

WordPress

sudo vim /var/www/example.com/wp-config.php

Add these lines:

define('WP_MEMORY_LIMIT', '2G');
define('WP_MAX_MEMORY_LIMIT', '2G');

The WP_MAX_MEMORY_LIMIT specifically addresses the administrative backend, which has a different memory limit from both WordPress and PHP configs.

Then, disable the HTML5 canvas data issue (noticeable in Tor Browser):

CaD_SfmWwAETwiW

(thanks Wilton)

wp-admin > Appearance > Editor > functions.php

Add this to the bottom:

remove_action( 'wp_head', 'print_emoji_detection_script', 7 );

remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );

remove_action( 'wp_print_styles', 'print_emoji_styles' );

remove_action( 'admin_print_styles', 'print_emoji_styles' );

OSSEC and Sucuri

OSSEC is a powerful Host-based Intrusion Detection System (HIDS). Sucuri is a powerful WordPress plugin. This section gets both installed and gets them working together.

wget -U ossec https://bintray.com/artifact/download/ossec/ossec-hids/ossec-hids-2.8.3.tar.gz

tar -zxvf ossec-hids-*.tar.gz

cd ossec-hids-2.8.3/

sudo ./install.sh

During installation:

en
1- local
2- accept default
3- accept all defaults

Then:

sudo /var/ossec/bin/ossec-control start

sudo vim /var/ossec/etc/ossec.conf

Verify/change/add these lines:

email_notification yes /email_notification
email_to email@email.com /email_to
smtp_server localhost /smtp_server
email_from ossecm@email.com /email_from

This configuration should force the use of TLS encrypted emails if Sendmail is installed and configured.

sudo service ossec restart

Then, in the WordPress Dashboard, install and activate the “Sucuri Security” plugin.

Open the Sucuri Security dashboard and generate an API key. It will use your WordPress admin account/email. I had to manually email the provided email to get a key.

Then:

sudo touch /var/log/wordpress.log

sudo chown www-data:www-data /var/log/wordpress.log

In WordPress Dashboard, navigate to Sucuri Security > Settings > Log Exporter

Enter “/var/log/wordpress.log” and save.

Then:

sudo vim /var/ossec/etc/ossec.conf

Under “Files to monitor (localfiles)“, add these lines:

  localfile
    log_format syslog /log_format
    location /var/log/wordpress.log /location
  /localfile
sudo service ossec restart

Be prepared for lots of email notifications, thankfully TLS encrypted. Be careful about what information is copied and stored by your email provider.

WordPress Plugins

— Disable Comments
— Disable Google Fonts
— Disable XML-RPC

Tor Project successes

Related: Users of Tor

2015

2015-Sep | Free Software Foundation: Tor relay reinstated in the Kilton Library: a win for free software-based anonymity

2015-Jun | GlobalVoices: Tor Use in Russia Spiking in Response to Kremlin’s Censorship Efforts

2015-Apr | Committee to Protect Journalists: Journalists overcome obstacles through crowdfunding and determination

2015-Mar | GlobalVoices: Netizen Report: Macedonian Leak Scandal Reveals Mass Surveillance, Corruption

2015-Mar | Motherboard: Iran Is Trying to Block Tor

2014

2014-Nov | Committee to Protect Journalists: How Facebook’s Tor hidden service improves safety for journalists

2014-Sep | Comcast: Setting the Record Straight on Tor

2014-Aug | GlobalVoices: Iran’s Internet Users Outsmart Government in Cat-and-Mouse Censorship Game

2014-Jul | Dailydot: Iran blacklists Tor network, knocking 75 percent of users offline

2014-May | Transition House As domestic abuse goes digital, shelters turn to counter-surveillance with Tor

2014-Apr | Reporters Without Borders: Reporters Without Borders and Torservers.net, partners against online surveillance and censorship

2013

2013-Jul | GlobalVoices: Another Journalist Arrested in Zambia

2012

2012-Jun | Reporters Without Borders: Government steps up control of news and information

2012-Feb | Ars Technica: Tor’s latest project helps Iran get back online despite new Internet censorship regime

2011

2011-Apr | GlobalVoices: Over the Firewall and into the Fire

2011-Apr | Freedom House: Leaping Over the Firewall: A Review of Censorship Circumvention Tools

2011-Jan | GlobalVoices: Iran: Blocking activity, email interception, and renewed pressure on the Green Movement

2011-Jan | Tor Project: New Blocking Activity from Iran

2010

2010-Jan | GlobalVoices: Poland: Discussions of TOR and Internet Filtering

2009

2009-Sep | GlobalVoices: التدوين باسم مجهول مع ووردبرس و تور

2009-Mar | GlobalVoices: Anonymous Blogging with WordPress & Tor Updated!

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/

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

Draft 2

The City of Seattle has an opportunity to become the first city in the world to adopt cutting edge technology that supports personal data privacy, information security, and government transparency. SecureDrop and Tor, both free software solutions, independently designed and independently important, together create an ecosystem for government accountability.

Tor is an encrypted networking protocol used in conjunction with Tor Browser, an application that allows anyone to maintain confidentiality of certain personal data when browsing the Internet. Tor Browser is advocated to many underserved communities, like the Cambridge domestic violence prevention organization Transition House [1]. Similarly, Seattle Public Library discussed how they plan to support Tor Browser in a recent blog post titled, Online Privacy and the Use of the Tor Network in the Library [2].

Another Tor application is called “Hidden Services”. Hidden Services provide end-to-end encryption just like using “HTTPS” when connecting to your bank, but with the benefit of Tor routing that further protects personal data. There are many ethically-centered reasons why the social platform Facebook and the search engine DuckDuckGo provide their users access via Hidden Service, but mainly it is to give their users identity control.

SecureDrop is a secure and anonymous document submission system that employs Hidden Services. It is currently used by law firms like the ACLU of Washington for client intake, in addition to news media organizations like the New Yorker and the Washington Post for protecting journalist sources. SecureDrop would help satisfy the requirements of “internal institutional and external oversight mechanisms” discussed in the recently published United Nations Report of the Special Rapporteur to the General Assembly on the Protection of Sources and Whistleblowers [3].

According to Tor Project, Hidden Services provide a means for Tor users to create sites and services that are accessible exclusively within the Tor network, with privacy and security features that make them useful and appealing for a wide variety of applications. The potential of Hidden Services is huge, and much of it is yet to be explored [4].

To maximize trust building opportunities, the City should exclusively use free software when deploying technologies that interface with the public. Adopting Tor privacy applications would not just set a high bar for data privacy expectations, it would establish trust because anyone can independently review how the software works and how personal data is protected. There are several ways that City government departments could take advantage of these privacy applications. Each would provide real-world benefits that defend the rights of City residents:

1. Tor Browser

Deploying Tor Browser on certain City government computers, or supporting Tor Browser through explicit policy and education, would provide certain assurances about data privacy and demonstrate a commitment to web based data privacy initiatives. The target audience could be City government employees or the general public depending on location and goals.

Additionally, providing educational material to targeted groups of people about how to use Tor Browser effectively from personally owned computers will decrease the apprehension of accessing certain public resources or providing meaningful but anonymous feedback to specific City government organizations.

2. Hidden Services

City government organizations supply many web-based resources, but sometimes accessing these resources carry potential social or legal consequences that turn people away. These resources can be made available via Hidden Service, allowing people to access web-based resources with less stress.

3. SecureDrop

Internal: City government organizations can use SecureDrop to strengthen their commitments to accountability. By sharing a SecureDrop server address internally, organizations can deploy a dependable whistleblowing avenue, or a powerful tool for soliciting anonymous feedback.

External: Having SecureDrop for secure and anonymous document submissions would guarantee certain data privacy and information security protections because of the design of the system. Like Tor and other free and open source software projects, anyone can read about and comprehensively understand both the code and the operations of how the application is supposed to work. Public complaints, public feedback, perceived government abuse, and issues pertaining to the City of Seattle can all be securely and anonymously received with a publicly shared SecureDrop server.


1 http://www.betaboston.com/news/2014/05/07/as-domestic-abuse-goes-digital-shelters-turn-to-counter-surveillance-with-tor/

2 https://shelftalkblog.wordpress.com/2015/09/22/online-privacy-and-the-use-of-the-tor-network-in-the-library/

3 http://www.ohchr.org/EN/Issues/FreedomOpinion/Pages/ProtectionOfSources.aspx

4 https://blog.torproject.org/blog/crowdfunding-future-hidden-services

Supporting SecureDrop with Creative Commons

Dear SecureDrop supporters,

As of writing, there are 17 organizations actively using SecureDrop [1] in order to support secure and anonymous document submission. This number needs to increase for redundancy and diversity purposes. In this post I will describe one important way to enhance SecureDrop adoption.

Administrators of SecureDrop are responsible for creating an HTTPS landing page with the goal of educating its visitors about the technology including the ideal ways to use their SecureDrop server. Organizations employing SecureDrop must write thoughtful and clear instructions for their landing page based on their unique organizational requirements and goals. Freedom of the Press Foundation has written a sample privacy policy [2] that provides a solid foundation for some of this landing page content.

Exceptional SecureDrop landing pages already exist, and The Intercept’s SecureDrop landing page [3] is one example. I believe there is always room for improvement, which I have detailed in a related post, The limitations of SecureDrop and Tor for whistleblowers [4].

Proposal


To best support the use of high-quality information:

  1. Freedom of the Press Foundation should encourage SecureDrop adopters to license the semantic and/or graphics content of their respective landing page as Creative Commons Public Domain (CC0) [5] or Creative Commons Attribution-ShareAlike (CC-BY-SA) [6].
  2. Existing organizations employing SecureDrop should apply a CC0 or CC-BY-SA license to their SecureDrop landing page.

Tor Project already licenses their website’s content as CC-BY-SA [7] which is an important contribution in addition to their existing open source software.

SecureDrop is a complex security environment that depends on Tor. Tor Browser is also a complex security tool despite Tor Project’s usability achievements. Additionally, high quality SecureDrop landing pages explain that Tails Linux should be used instead of Tor Browser when submitting documents in order to mitigate specific security concerns. These are three independently complicated security tools that require clear and thoughtful information pertaining to their use. Of all of the possible users of Tor and SecureDrop, supporting the extreme security-sensitive population, whistleblowers, demands providing high quality information.

An unrestrictive Creative Commons license such as CC0 or CC-BY-SA applied to a SecureDrop landing page allows other organizations the ability to easily adopt high quality information. Applying an open license would help foster a stronger community of organizations working hard to best support possible whistleblowers. Having to reword complex security precautions because of copyright restrictions is a dangerous proposition given the limited amount of open source privacy technologies available.

Thank you!

References

1 https://freedom.press/securedrop/directory

2 https://securedrop.org/sample-privacy-policy

3 https://theintercept.com/securedrop/

4 https://yawnbox.com/?p=3655

5 https://creativecommons.org/publicdomain/zero/1.0/

6 https://creativecommons.org/licenses/by-sa/3.0/us/

7 https://www.torproject.org/docs/trademark-faq.html.en

License

CC0
To the extent possible under law, the person who associated CC0 with Supporting SecureDrop with Creative Commons has waived all copyright and related or neighboring rights to Supporting SecureDrop with Creative Commons. This work is published from the United States.

The limitations of SecureDrop and Tor for whistleblowers

The use of security software for the purpose of maintaining privacy boils down to physical safety. If you decide to take on the responsibility of educating someone about security software, you have an ethical obligation to provide a holistic understanding of the technology while being willfully transparent about your goals.

The Rule: You cannot let anyone’s idealism, including your own, fill in the gaps of what is not known about security software.

Privacy leaders, including organizations that employ or advocate the use of SecureDrop and Tor, must understand that any security technology that they choose to employ will be part of many delicate systems, including (in order):

  1. The user’s actual risks from external actors
  2. The user’s real life decisions concerning what, when, why, and how
  3. The user’s entire software environment
  4. What the software is capable of
  5. What the user wants

If you do not talk about these things in a targeted and meaningful way, you are violating The Rule. Tor, the protocol, is a means of probabilistically disassociating unavoidable network metadata generation from the user. SecureDrop, the environment, compartmentalizes information (cryptographically) and components (physically) to minimize metadata creation and to avoid vulnerabilities inherent with networking. 1, 2, 3, and especially 5 do not change what the respective security software is capable of. If you host SecureDrop and you choose to not inform the users about the security software that you want them to use, you are violating The Rule.

The following is one way that your organization could assist users with their secure document submission planning.


SecureDrop security and privacy advantages

1. Our SecureDrop system is under the physical control of our organization.

2. Connecting to our SecureDrop server is end-to-end encrypted because it is a “Tor hidden service,” a website that is only accessible through the Tor network. Information submitted through SecureDrop is cryptographically authenticated and private.

3. SecureDrop requires the use of encryption keys to maintain the confidentiality and integrity of the information that we receive. We keep our SecureDrop encryption keys on air-gapped computers that never connect to the Internet or our corporate network. Even if our SecureDrop server gets hacked or the physical hardware gets confiscated, the files and messages previously submitted should still be shielded from the attacker.

4. Using the Tor network helps mask your activity from anyone that is monitoring your Internet connection, and it helps mask your identity from anyone monitoring our Internet connection.

5. SecureDrop does not log connections, and your IP address or physical location is not disclosed to our organization because of SecureDrop’s dependency on Tor. Even if a government agency tried to compel our organization to provide logs, we could not do so.

6. It is very difficult or impossible for passive surveillance techniques to determine that you are interacting with SecureDrop. The use of a Tor hidden service prevents network traffic from ever leaving the Tor network thereby supporting anonymity and complicating any broad surveillance of entire networks.

7. Tor Browser is a portable application, so you do not need to install any software to access SecureDrop.

8. SecureDrop is free and open source software that is available to the public. Freedom of the Press Foundation hires an independent auditing company and publicly publishes the results.

9. Tor, the network protocol, and Tor Browser, the Internet browsing application, are both free and open source software that is available to the public. Tor Project uses Coverity and Veracode bug scanning software.

SecureDrop security and privacy warnings

1. If you believe that you or your computer system is under active, targeted surveillance, do not risk your personal safety by sending our organization sensitive material.

2. Presume that computer systems legally or physically owned by anybody but you are compromised and under active surveillance. Most corporate and government owned systems monitor and log activity. If they do not monitor or log activity, they still have legal rights to the hardware, software, and data on the device. Use a personally owned computer system that you trust.

3. An already-compromised computer will likely defeat the privacy protections that SecureDrop and Tor provide, such as keystroke logging, activity logging, or screen grabbing spyware. If you are at all suspicious of malware of any kind, use Tails Linux instead (see additional details below). Using SecureDrop presumes that your computer system is safe to be doing sensitive work from.

4. By default, Tor Browser does not save website history or website cookies. This data is ordinarily not recoverable after you close Tor Browser and fully shut down your computer. However, all mainstream operating systems betray their user’s expectations by saving browsing activity information in various ways. It is your responsibility to accept the risk that your computer may be physically confiscated and analyzed. Disk encryption can help mitigate this risk. Tor Browser is designed for privacy, but it does not mitigate the risk of local metadata generation since the operating system that it runs in is not designed for privacy.

5. Passive network monitoring and data retention are practices performed by all Internet Service Providers (ISP). They deliver Internet to your home, office, and every coffee shop that offers Wi-Fi. ISPs document all kinds of specific metadata, including the facts that someone is using Internet service and when, and that someone is generating Tor traffic and when. Places that offer Wi-Fi often have connection requirements like accepting a Terms of Service. This process dictates that it will be recording hardware identifiers that belong to your computer. Taking advantage of the Tor anonymity network allows you to distance what you are doing from the metadata generation inherent with Internet surfing. Tor Browser may help you mitigate certain data linkability risks, but it does not evade the risks entirely.

6. When using Tor, it is unlikely that passive network monitoring can determine the destination of your Internet use, including connecting to our organization’s SecureDrop server. Access SecureDrop from a public location that you do not regularly visit to help make unavoidable metadata collection by intermediaries or possible attackers less useful for identifying or targeting you.

7. Our organization’s website (presumably) employs mandatory HTTPS to protect all of our website visitors. Using standard web browsers such as Firefox or Chrome to access any of our web pages creates network metadata showing that you are visiting our domain, not this page specifically (presuming we’re NOT using a uniquely identifiable sub-domain). However, advanced network monitoring software can analyze the metadata of encrypted traffic to determine exactly which pages you are reading. Be conscious of who might use this information against you, and choose your Internet access carefully.

8. Using Tor guarantees that SecureDrop does not know who you are or where you are unless you explicitly share identifying information with us. If you are thinking about releasing information to us and doing so would put you in harm’s way, do not share personal details with our organization unless it is critical information pertinent to the disclosure.

Security problems that our technology cannot help with

1. If you plan on checking back for SecureDrop messages that are only accessible with your private codename, be sure to keep your codename private. Treat your codename like you would a bank password. Ideally, keep your codename on an encrypted USB drive that is only accessible by you.

2. If you expect a response from our organization via SecureDrop, do not email, call, or contact us via social media.

3. Do not share, with anyone, that you are sharing material with our organization unless you are advised by explicit legal representation.

4. Before utilizing public Internet access to leak information, consider your data’s linkability, your own risk profile, and your personal goals. Plan carefully. You may want to avoid using electronic payment systems including credit cards, debit cards, reward cards, or mass transit payment cards in proximity to the location where you make the disclosures. You may want to avoid using automobiles that are susceptible to license plate readers or have internal GPS or cellular tracking mechanisms. Leave your cellular devices behind at home. Pay with cash and be nice to everyone you meet, but of course, try to avoid interaction as much as possible.

Tails Linux

While not every person’s risk profile may warrant its use, Tails a free and open source operating system that you burn to a DVD or install onto a USB drive. Tails runs directly from that DVD or USB drive, meaning it does not get installed onto any of your computer’s internal disk drives. Tails is developed exclusively for privacy-minded individuals and forces all Internet connections over Tor. Using Tails to connect to our organization’s SecureDrop server resolves several problems that Tor Browser alone cannot, including:

1. Tails evades most forms of client-side surveillance software and malware. When you start Tails, it does not use or change your computer’s existing operating system, applications, or data. Tails loads into your computer’s temporary memory and allows you to access the Internet over Tor with a Firefox-like browser called Iceweasel. However, if there is a hardware surveillance system installed, or the system has been compromised at a deeper level than the operating system, Tails may not provide any privacy benefits.

2. Tails does not save any data to local disk storage, so all activity performed during its use is lost forever once you shut down the computer. Remember that Tails still creates network metadata when connecting to and using the Internet but with one exception: the hardware ID that wireless access points save is randomly generated and automatically shared when using Tails, not the real hardware ID for your computer.

For more information about Tails Linux, including installation documentation and good practices, please visit https://tails.boum.org/.


Article feedback:

yawnbox AT riseup DOT net, GPG key

Article license:

CC0
To the extent possible under law, the person who associated CC0 with The limitations of SecureDrop and Tor for whistleblowers has waived all copyright and related or neighboring rights to The limitations of SecureDrop and Tor for whistleblowers. This work is published from: United States.