A+ TLS config for ubuntu + nginx

These are my config notes for getting a brand new Xenial + nginx server online.

Install Tor:

sudo apt install tor apt-transport-tor
sudo gpg --keyserver keys.gnupg.net --recv 886DDD89

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

Edit the sources list by removing all the lines and adding these:

sudo vim /etc/apt/sources.list
deb tor+https://deb.torproject.org/torproject.org xenial main
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-security main restricted universe multiverse

Update the repos:

sudo add-apt-repository ppa:nginx/development
sudo add-apt-repository ppa:ondrej/nginx
sudo add-apt-repository ppa:ondrej/php
sudo add-apt-repository ppa:certbot/certbot

Add “tor+” to all of the above sources files in /etc/apt/sources.list.d/*

Update and restart:

sudo apt update && sudo apt upgrade -V && sudo apt autoremove -y && sudo shutdown -r now

Install nginx + certbot:

sudo apt install python-certbot-nginx -V

Add server_name to (replacing “_”):

sudo vim /etc/nginx/sites-available/default
server_name domain.net;

Get Let’s Encrypt cert for nginx:

sudo certbot --nginx -d domain.net --redirect --rsa-key-size 4096

Further harden the TLS config:

sudo vim /etc/letsencrypt/options-ssl-nginx.conf
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:!3DES:!aNULL:!DES:!DSS:!eNULL:!EXP:!IDEA:!LOW:!MD5:!PSK:!RC4:!SEED";

Delete the “SSL” config:

sudo vim /etc/nginx/nginx.conf

Edit the nginx config:

sudo vim /etc/nginx/sites-available/default

replace “domain.net”

server {
        listen 80 default_server;
        listen [::]:80 default_server;

        server_name domain.net www.domain.net;
        return 301 https://$host$request_uri;

        server_tokens off;
        add_header X-Frame-Options SAMEORIGIN;
        add_header X-Content-Type-Options nosniff;
        add_header X-XSS-Protection "1; mode=block";
        add_header Referrer-Policy "no-referrer";
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;

        server_name domain.net www.domain.net;
        root /var/www;
        index index.php index.html index.htm;

        ssl_certificate /etc/letsencrypt/live/domain.net/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/domain.net/privkey.pem;
        include /etc/letsencrypt/options-ssl-nginx.conf;
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

        server_tokens off;
        add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
        add_header X-Frame-Options SAMEORIGIN;
        add_header X-Content-Type-Options nosniff;
        add_header X-XSS-Protection "1; mode=block";
        add_header Referrer-Policy "no-referrer";

        resolver 8.8.8.8 8.8.4.4 valid=300s;

# For WordPress

        location / {
        try_files $uri $uri/ /index.php?$args;
        }

        location ~ \.php$ {
                include snippets/fastcgi-php.conf;
                fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                include fastcgi_params;
        }
}

Validate the nginx config:

sudo nginx -t

Restart nginx:

sudo service nginx restart

Add inbound and outbound firewall rules:

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

Emerald Onion has launched

The Tor network and the dot-Onion infrastructure was built for security and privacy in mind. This is unlike legacy clear-net infrastructure, which over the years needs routine and dramatic security changes just to solve evolving security chalenges. Even worse, modern security for legacy clear-net infrastructure does very little for privacy.

Vulnerable populations were the first to recognize the importance of a technology like “the onion router”. The United States Navy was among the first. The United States Navy, realizing very quickly that an anonymity network that only the Navy would use, means that any of its users is from the United States Navy. To this day, the United States Navy researches and develops Tor.

Once Tor became a public, free, and open source project, journalists and other vulnerable populations with life-and-death threat models started using Tor. These survivors and human-rights defenders were a red flag. By the time Tor became a public project, other departments from the United States Government, such as the United States National Security Agency, had already started conducting global mass surveillance.

The United States Navy knew and continues to know that Tor is a necessity in a world dominated by global mass surveillance and by governments that strive for power and control.

Emerald Onion envisions a world where access and privacy are the defaults. This is necessary to ensure human rights including access to information and freedom of speech. If we do not have human rights online, we will not have them offline, either. We launched, officially, on July 2nd. We are looking at 10 year+ development and sustainability. Please reach out to me if you can think of ways to support our work.

Ubuntu SSH crypto hardening

Fix the security and privacy of your Ubuntu 16.04, 16.10, and 17.04 web server access. Fuck global mass surveillance.

Special thanks to @stribika for writing a very similar guide two years ago.

From “man sshd_config”

allowable ciphers

Run “ssh -Q cipher” for validating usable “Ciphers” on clients and servers

Specifies the ciphers allowed.  Multiple ciphers must be comma-separated.  If the specified value begins with a ‘+’ character, then the specified ciphers will be appended to the default set instead of replacing them.

allowable message authentication code algorithms

Run “ssh -Q mac” for validating usable “MACs” on clients and servers

Specifies the available MAC (message authentication code) algorithms.  The MAC algorithm is used for data integrity protection. Multiple algorithms must be comma-separated.  If the specified value begins with a ‘+’ character, then the specified algorithms will be appended to the default set instead of replacing them. The algorithms that contain "-etm" calculate the MAC after encryption (encrypt-then-mac).  These are considered safer and their use recommended.

allowable key exchange algorithms

Run “ssh -Q kex” for validating usable “KexAlgorithms” on clients and servers

Specifies the available KEX (Key Exchange) algorithms.  Multiple algorithms must be comma-separated.  Alternately if the specified value begins with a ‘+’ character, then the specified methods will be appended to the default set instead of replacing them.

allowable server key algorithms

Run “ssh -Q key” for validating usable “HostKeyAlgorithms” on servers

Specifies the host key algorithms that the server offers.

allowable key authentication types

Run “ssh -Q key” for validating usable “HostbasedAcceptedKeyTypes” on servers

Specifies the key types that will be accepted for hostbased authentication as a comma-separated pattern list.  Alternately if the specified value begins with a ‘+’ character, then the specified key types will be appended to the default set instead of replacing them.

allowable public key authentication types

Run “ssh -Q key” for validating usable “PubkeyAcceptedKeyTypes” on servers

Specifies the key types that will be accepted for public key authentication as a comma-separated pattern list.  Alternately if the specified value begins with a ‘+’ character, then the specified key types will be appended to the default set instead of replacing them.

Fix your server keys

cd /etc/ssh

sudo rm ssh_host_*key*

sudo ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null

Amending sshd

sudo vim /etc/ssh/sshd_config

Only use the ed25519 key (delete the others):

HostKey /etc/ssh/ssh_host_ed25519_key

Add these lines (tailor them down based on what you know your client and server have available (see above for "ssh -Q x" options)):

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-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,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521

HostKeyAlgorithms ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519

HostbasedAcceptedKeyTypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519

PubkeyAcceptedKeyTypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519

Restart sshd:

sudo service ssh restart

ssh over Tor

Fix metadata leaks by using Tor as your second end-to-end encrypted tunnel if you don't mind a mildly delayed CLI due to added latency.

Install Tor by first fixing apt sources and adding Tor's repo:

sudo vim /etc/apt/sources.list

Delete all lines and use these (replace "zesty" if needed):

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

Install Tor's signing key:

sudo gpg --keyserver keys.gnupg.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89

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

Update and install Tor:

sudo apt-get update && sudo apt-get install tor deb.torproject.org-keyring -y

Configure Tor for an onion:

sudo vim /etc/tor/torrc

Delete all lines and add these:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 22 127.0.0.1:22

Restart Tor:

sudo service tor restart

Find your new dot-onion address:

sudo cat /var/lib/tor/hidden_service/hostname

Configure sshd to only listen via Tor (and not exposed on the clear net):

sudo vim /etc/ssh/sshd_config

Add (or change) this line:

ListenAddress 127.0.0.1:22

Restart sshd:

sudo service ssh restart

Firewall everything

Presuming you are only hosting a web server over ports 80 and 443:

sudo ufw allow 80/tcp && sudo ufw allow 443/tcp && sudo ufw allow out 53/udp && sudo ufw allow out 80/tcp && sudo ufw allow out 123/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

80 for http
443 for https
53 out for DNS
123 out for NTP
9050 out for Tor

Deny everything else.

client side for Tor

sudo vim /etc/ssh/ssh_config

Add these lines under "Host *" (tailor the Ciphers, MACs, and Kex down based on what you know your client and server have available (see above for "ssh -Q x" options)):

UseRoaming no

proxyCommand ncat -v --proxy localhost:9050 --proxy-type socks5 %h %p

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-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,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521

Generate client keys:

ssh-keygen -t ed25519 -o -a 100

Restart ssh:

sudo service ssh restart

Send the client public key to the server:

ssh-copy-id yawnbox@2vytis5xf5djnaoo.onion

Connect to the server with debug to verify hardened crypto:

ssh -v yawnbox@2vytis5xf5djnaoo.onion

You will find this info buried:

debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC:  compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC:  compression: none

debug2: key: /home/yawnbox/.ssh/id_rsa ((nil))
debug2: key: /home/yawnbox/.ssh/id_dsa ((nil))
debug2: key: /home/yawnbox/.ssh/id_ecdsa ((nil))
debug2: key: /home/yawnbox/.ssh/id_ed25519 (0x55zg8nba8f20)

Cheers

bonus server config script


#!/bin/bash

sudo apt-get update

sudo apt-get upgrade -y

sudo apt-get dist-upgrade -y

sudo apt-get install tor openssh-server -y

sudo apt-get autoremove -y

sudo apt-get autoclean

cd /etc/ssh

sudo rm ssh_host_*key*

sudo ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null

cd ~

sudo mv /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

sudo touch /etc/ssh/sshd_config

sudo echo "Port 22" >> /etc/ssh/sshd_config

sudo echo "HostKey /etc/ssh/ssh_host_ed25519_key" >> /etc/ssh/sshd_config

sudo echo "SyslogFacility AUTH" >> /etc/ssh/sshd_config

sudo echo "LogLevel INFO" >> /etc/ssh/sshd_config

sudo echo "LoginGraceTime 30" >> /etc/ssh/sshd_config

sudo echo "PermitRootLogin no" >> /etc/ssh/sshd_config

sudo echo "StrictModes yes" >> /etc/ssh/sshd_config

sudo echo "MaxAuthTries 5" >> /etc/ssh/sshd_config

sudo echo "MaxSessions 5" >> /etc/ssh/sshd_config

sudo echo "PasswordAuthentication no" >> /etc/ssh/sshd_config

sudo echo "PermitEmptyPasswords no" >> /etc/ssh/sshd_config

sudo echo "ChallengeResponseAuthentication no" >> /etc/ssh/sshd_config

sudo echo "UsePAM yes" >> /etc/ssh/sshd_config

sudo echo "X11Forwarding no" >> /etc/ssh/sshd_config

sudo echo "PrintMotd no" >> /etc/ssh/sshd_config

sudo echo "AcceptEnv LANG LC_*" >> /etc/ssh/sshd_config

sudo echo "Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr" >> /etc/ssh/sshd_config

sudo echo "MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256" >> /home/cs/test_sshd

sudo echo "KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521" >> /etc/ssh/sshd_config

sudo echo "HostKeyAlgorithms ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519" >> /etc/ssh/sshd_config

sudo echo "HostbasedAcceptedKeyTypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519" >> /etc/ssh/sshd_config

sudo echo "PubkeyAcceptedKeyTypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519" >> /etc/ssh/sshd_config

sudo service ssh restart

sudo mv /etc/apt/sources.list /etc/apt/sources1.bak

sudo touch /etc/apt/sources.list

sudo echo "deb https://mirrors.wikimedia.org/ubuntu/ xenial main restricted universe multiverse" >> /etc/apt/sources.list

sudo echo "deb https://mirrors.wikimedia.org/ubuntu/ xenial-updates main restricted universe multiverse" >> /etc/apt/sources.list

sudo echo "deb https://mirrors.wikimedia.org/ubuntu/ xenial-backports main restricted universe multiverse" >> /etc/apt/sources.list

sudo echo "deb https://mirrors.wikimedia.org/ubuntu/ xenial-security main restricted universe multiverse" >> /etc/apt/sources.list

sudo echo "deb https://deb.torproject.org/torproject.org xenial main" >> /etc/apt/sources.list

sudo torify gpg --keyserver keys.gnupg.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89

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

sudo apt-get update

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

sudo mv /etc/apt/sources.list /etc/apt/sources2.bak

sudo touch /etc/apt/sources.list

sudo echo "deb tor+https://mirrors.wikimedia.org/ubuntu/ xenial main restricted universe multiverse" >> /etc/apt/sources.list

sudo echo "deb tor+https://mirrors.wikimedia.org/ubuntu/ xenial-updates main restricted universe multiverse" >> /etc/apt/sources.list

sudo echo "deb tor+https://mirrors.wikimedia.org/ubuntu/ xenial-backports main restricted universe multiverse" >> /etc/apt/sources.list

sudo echo "deb tor+https://mirrors.wikimedia.org/ubuntu/ xenial-security main restricted universe multiverse" >> /etc/apt/sources.list

sudo echo "deb tor+https://deb.torproject.org/torproject.org xenial main" >> /etc/apt/sources.list

sudo echo "capability dac_read_search," >> /etc/apparmor.d/abstractions/tor

sudo /etc/init.d/apparmor reload

sudo mv /etc/tor/torrc /etc/tor/torrc.bak

sudo touch /etc/tor/torrc

sudo echo "HiddenServiceDir /var/lib/tor/hidden_service/" >> /etc/tor/torrc

sudo echo "HiddenServicePort 22 127.0.0.1:22" >> /etc/tor/torrc

sudo service tor restart

sudo touch ~/onion.txt

sudo cat /var/lib/tor/hidden_service/hostname >> ~/onion.txt

sudo echo "ListenAddress 127.0.0.1:22" >> /etc/ssh/sshd_config

sudo service ssh restart

sudo ufw allow 22/tcp

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

sudo ufw allow out 22/tcp

sudo ufw allow out 53/udp

sudo ufw allow out 80/tcp

sudo ufw allow out 123/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

sudo cat ~/onion.txt

Secure Messenger Scorecard (May 2017)

This is a draft.

I’m starting my own Secure Messenger Scorecard based on the prior work of the Electronic Frontier Foundation.

I’ve created an editable Google Doc for further input and development.

Please scrutinize and contribute by Signaling me, emailing me or tweeting at me.

version one

version two

version three

Tor terminology

When people talk about Tor, they may be talking about one or more of the following Tor technologies:

The Tor protocol: The official system of rules governing the operations of Core Tor, the Tor network, and Onion Services. The Tor protocol is publically accessible and readily criticized and updated.

Core Tor: A software application that uses strong encryption and careful routing designed to hide network identifying information of a computer from other Internet resources. Core Tor is a free software technology that can be built into many Internet products.

The Tor network: The global network of volunteer administrators that make Tor technologies so powerful and successful. Volunteers run “relays” that route Core Tor and Onion Services traffic on the Internet. Each of the 7,000+ volunteer relay administrators can be one of three “hops” that Tor users rely on when using Tor technologies. When Tor technologies are used, traffic moves from relay to relay, each hop preventing network origination information from being shared with the destination. Relay diversity is important because of the need for distributed trust.

Tor Browser: A customized Firefox web browser that has been modified to minimize identity exposure to web sites and advertising networks. One critical feature of Tor Browser is that all traffic from Tor Browser is routed through the Tor network.

Onion Services: The dot-onion (.onion) is a special “top level domain”, similar to dot-com (.com), but is only recognized by Tor technologies. Onion Services are diverse and can be used by many types of Internet tools. For example, in Tor Browser, connecting to a dot-onion web address allows a server to share content anonymously with a user, and allows a user to connect anonymously to a server. Onion Services are also used by instant messaging tools like Ricochet which allows people to anonymously chat with each other.

Pluggable Transports: It is commonplace for governments or corporations to limit, censor, or surveil their Internet users. Pluggable Transports are free software technologies that allow Tor technologies to bypass censorship by changing how the Internet traffic appears to these restrictive organizations.

Draft proposal for Debian

Draft:

Please criticize and contribute to the following:

Objectives:

1. The Debian community must immediately deploy Onion Service repositories for Debian downloads and Debian updates.

2. The Debian community must immediately deploy TLS-only repositories for Debian downloads and Debian updates as a backup to Onion Services.

3. The Debian community must assure anonymity-by-default with the employment of apt-transport-tor by changing existing update mechanics.

4. The Debian community must deploy a critical security update to patch existing update mechanics to use Onion Services.

Summary:

Current and future network adversaries can view and retain which repositories Debian servers connect to (metadata), when (metadata), the updates schedule (information), which updates are being applied (information), and into which operating system (information). This is incredibly valuable information for any adversary wanting to perform minimal attacks against Debian servers. Further, with cheapening data retention, mass-hacking and nation-state dominance is supported by the Debian community’s short-sighted update mechanics.

Edward Snowden has given the world factual evidence describing the capabilities and objectives of global powers and the Debian community has willfully neglected these problems.

Arguments:

Report of the Special Rapporteur on the promotion and protection of the right to freedom of opinion and expression, David Kaye — Presented to the Human Rights Council in May 2015:

(2)(A)(9) “Notably, encryption protects the content of communications but not identifying factors such as the Internet Protocol (IP) address, known as metadata. Third parties may gather significant information concerning an individual’s identity through metadata analysis if the user does not employ anonymity tools. Anonymity is the condition of avoiding identification. A common human desire to protect one’s identity from the crowd, anonymity may liberate a user to explore and impart ideas and opinions more than she would using her actual identity. […] Users seeking to ensure full anonymity or mask their identity (such as hiding the original IP address) against State or criminal intrusion may use tools such as virtual private networks (VPNs), proxy services, anonymizing networks and software, and peer-to-peer networks.1 One well-known anonymity tool, the Tor network, deploys more than 6,000 decentralized computer servers around the world to receive and relay data multiple times so as to hide identifying information about the end points, creating strong anonymity for its users.”

Debian powers more than one-third of the Internet. The default behavior of Debian is to obtain updates via clear-text HTTP which discloses the following to any network adversary:

1. Server location via IP address
2. Update server via IP address and DNS resolution
3. Server update schedule
4. Server version
5. Application version

This information, via network analysis, would allow any passive or active adversary to plan effective attacks against any Debian server.

Not all adversaries are the same because not all servers have the same risk. Like people, data mining and data retention capabilities pose grave risks for infrastructure. HTTPS may resolve some of the above information leakage depending on an adversary’s capabilities, but Tor resolves them to a greater degree. Anonymity provides the strongest security and is the only acceptably secure option given the facts.

XKEYSCORE, a FVEY technology, is one example of a modern threat to Internet infrastructure. Via Wikipedia:

On January 26, 2014, the German broadcaster Norddeutscher Rundfunk asked Edward Snowden in its TV interview: “What could you do if you would [sic] use XKeyscore?” and he answered:

“You could read anyone’s email in the world, anybody you’ve got an email address for. Any website: You can watch traffic to and from it. Any computer that an individual sits at: You can watch it. Any laptop that you’re tracking: you can follow it as it moves from place to place throughout the world. It’s a one-stop-shop for access to the NSA’s information.

You can tag individuals… Let’s say you work at a major German corporation and I want access to that network, I can track your username on a website on a form somewhere, I can track your real name, I can track associations with your friends and I can build what’s called a fingerprint, which is network activity unique to you, which means anywhere you go in the world, anywhere you try to sort of hide your online presence, your identity.”

The question posed to Edward Snowden was rightly focused on people. However, an XKEYSCORE-like system can trivially threaten any node on the Internet. If XKEYSCORE-like systems can be programmed to track nations, servers, or application installations, the Debian community must act.

Scenarios:

1. Debian server > https://update-server.onion

In scenario 1, operating system and application updates are obtained exclusively within the Tor network with an added layer of Certificate Authority validation ability. HTTP-based Certificate Authority, Domain Name System, and Border Gateway Protocol vulnerabilities do not exist.

2. Debian server > http://update-server.onion

In scenario 2, operating system and application updates are obtained exclusively within the Tor network. HTTP-based Certificate Authority, Domain Name System, and Border Gateway Protocol vulnerabilities do not exist.

3. Debian server > tor+https://update-server.org

In scenario 3, operating system and application updates are obtained via Tor but must leave the Tor network to reach its HTTPS destination. All HTTP-based Certificate Authority, Domain Name System, Border Gateway Protocol, and Man-in-the-Middle vulnerabilities exist once the traffic traverses Tor exit relays onto the normal Internet. Debian servers retain anonymity but security risk is increased.

4. Debian server > tor+http://update-server.org

In scenario 4, operating system and application updates are obtained via Tor but must leave the Tor network to reach its HTTP destination. All HTTP-based Domain Name System, Border Gateway Protocol, and Man-in-the-Middle vulnerabilities exist once the traffic traverses Tor exit relays onto the normal Internet. Debian server retain anonymity but security risk is increased.

5. Debian server > https://update-server.org

In scenario 5, operating system and application updates are obtained via normal Internet with minimal transport security. Server location information, update server information, and server update schedule information easily obtainable, and sophisticated attackers can obtain server version information and package version information. All HTTP-based Certificate Authority, Domain Name System, Border Gateway Protocol, and Man-in-the-Middle vulnerabilities exist.

6. Debian server > http://update-server.org

In scenario 6, the current Debian default, operating system and application updates are obtained via normal Internet with zero transport security. Server location information, update server information, server update schedule information, server version information, and package version information are trivially obtainable. All HTTP-based Domain Name System, Border Gateway Protocol, and Man-in-the-Middle vulnerabilities exist.

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

My #TA3M talk on Tor, Onion Services, and why browser plug-ins and VPNs don’t protect your privacy

This presentation was given at the University of Washington on January 18, 2016 and is publicly available on Google Docs. If I get worthwhile feedback, I will update the presentation. Like the rest of my blog, the presentation and images are CC-BY. I will include the images at the end of this article (pending).

01 of 31, title

TA3M Seattle, January 2016 - 01

This quote is from Edward Snowden, from October 2015, via Micah Lee’s interview from The Intercept.

This talk is for everyone. You don’t need to be an activist, journalist or a lawyer to have to need Tor. Even the most boring, uninteresting person in the world should be defending their rights to privacy and freedom of expression by using Tor.

The aim of this ~30 minute talk (plus Q/A) is to help make understanding of Tor and Onion Services easier. It is not a highly technical talk, but it is technical. I expect that users that wish to gain knowledge of how technical systems work, to take advantage of them, must learn technical material.

The talk discusses how the Tor network works to protect your privacy by juxtaposing plain HTTP, HTTPS, and also mainstream VPN technology. I will be discussing why the advertising industry is an even greater threat than even the NSA (to most people) and why VPNs just can’t cut it. Lastly, I will discuss how Onion services is a paradigm shift from standard client-server communications, how it works to protect your privacy, and why Onion services is an important application for service providers concerned about uptime and security.

02 of 31, sources

TA3M Seattle, January 2016 - 02

Most of the content of my talk is sourced from these two blog posts of mine.

https://yawnbox.com/index.php/2016/01/04/use-tor-browser-or-harden-firefox-for-privacy/

https://yawnbox.com/index.php/2015/10/25/comparing-http-https-vpn-and-tor-with-snail-mail-metaphors/

03 of 31, http / postcard

TA3M Seattle, January 2016 - 03

As you probably know, sending a postcard in the mail allows anyone that handles the postcard to view and retain both the metadata (activity records of who, when, and where) and content. Plain HTTP is no different, except digital content is much easier and cheaper to collect and store.

04 of 31, http / postcard

TA3M Seattle, January 2016 - 04

This clear-text content and metadata is represented here in purple. It is completely defenseless in transit. Anyone connecting to, for example, bbc.co.uk allows anyone between you and the BBC service provider to view, retain, and maybe even change the metadata or content in transit.

05 of 31, https / letter

TA3M Seattle, January 2016 - 05

Sending a letter in the mail has one layer of protection, the envelope, and is analogous to HTTPS. The NSA considers HTTPS encrypted traffic “clear text” because metadata is still clear text, and a lot can be learned about the content of HTTPS encrypted traffic through automated analysis.

06 of 31, https / letter

TA3M Seattle, January 2016 - 06

HTTPS protected content is represented here by a red circle protecting the purple content at the center. Connecting to yandex.ru, even though encrypted with (presumably) high-grade HTTPS, still divulges a great deal of information (metadata) to anyone handling your traffic as it traverses the Internet.

07 of 31, virtual private network… 1-hop proxy

TA3M Seattle, January 2016 - 07

VPNs are largely one-hop proxies. It is possible to set up your own multi-hop VPN proxies, just like you can set up your own private Tor network if you have the time, expertise, and money. But mainstream VPN providers, to keep the time it takes to send your traffic back and forth across the Internet, only use one proxy. In other words, VPN providers, to keep most people happy, focus on speed rather than privacy.

Purchasing a private PO BOX or mailbox from a UPS store is analogous to purchasing VPN service from a provider. You are paying someone to “one-hop” proxy your mail so that the destination of your mail cannot know your real home address.

08 of 31, vpn / postcard

TA3M Seattle, January 2016 - 08

In this example, you are using the Ipredator (ipredator.se) VPN service provider in order to connect to amazon.com. Amazon still does not provide transport security and thus privacy for users of their service when searching for products to buy. Your Amazon-bound Internet traffic has one layer of protection, the orange circle, only up until the VPN service provider. Once your Amazon-bound traffic leaves the VPN provider (the one-and-only one-hop proxy), Amazon searches are as naked as postcards.

If network adversaries observing the Amazon searches somewhere between the VPN provider and Amazon may also be able to determine who is doing the searches based on the content of the Internet traffic, because these Amazon searches are just like sending postcards in the mail. Said adversaries can view, record, and change any of the metadata or content.

09 of 31, vpn / letter

TA3M Seattle, January 2016 - 09

In this example, when connecting with HTTPS to Wikipedia.org and using the Ipredator VPN service, the data (purple) is protected by by a layer of HTTPS (red) and also the VPN (orange). Once the Wikipedia-bound Internet traffic is proxied by Ipredator, it loses the VPN-encrypted (orange) layer, and your traffic’s content is still protected by Wikipedia’s HTTPS-encrypted (red) layer.

10 of 31, vpn circuits

TA3M Seattle, January 2016 - 10

As previously discussed, VPNs are one-hop proxies. The “circuit” that is made between you and the VPN service provider is static — the operator and the IP subnet never changes. The “IP subnet” of the VPN provider determines the IP address that your Internet traffic uses and is constrained by the pool of available IP addresses the VPN provider has available.

The one-hop proxy / circuit design is purposeful in order to maintain minimal latency (the time it takes for your traffic to reach the VPN provider), and to maximize bandwidth (how much you can download or upload per second).

11 of 31, the onion router… 3-hop proxy

TA3M Seattle, January 2016 - 11

Tor is more complex and can generally be described as a three-hop proxy. It would be like purchasing PO BOX services from three different, globally diverse mail proxy service providers, and each of those providers automatically works with each other to relay your mail to maximally protect your home address and maybe even your identity.

When sending mail communications, the first mail proxy knows who you are and also knows who the second mail proxy is. The second mail proxy only knows who the first and third mail proxies are. By the time your mail gets to the third and final mail proxy, your home address is not in any of the metadata that is destined for the recipient. And unless you disclosed your identity in the content of your communications, the recipient cannot know your identity, either.

12 of 31, tor / postcard

TA3M Seattle, January 2016 - 12

1. Tor encrypts your Ebay-destined traffic in three layers before leaving your computer.

2. Green circle: the Tor encrypted traffic from your computer to the Tor guard relay. The guard relay removes this first layer of encryption.

3. Yellow circle: the Tor encrypted traffic from the guard relay to the middle relay. The middle relay removes the second layer of encryption.

4. Orange circle: the Tor encrypted traffic from the middle relay to the exit relay. The exit relay removes the last layer of encryption and sends your traffic on to Ebay. Naked.

Connecting to ebay.com over Tor and searching Ebay does not disclose your IP address or your identity unless you log in to Ebay. Logging in to Ebay would disclose your identity to Ebay and thus may disclose the probability of your physical location if you gave Ebay or PayPal your home address as a shipping destination. If you browse Ebay without logging in but search for things that could allow an adversary to identify who is doing the searches, then you may disclose your identity that way, too.

If network adversaries observing the Ebay searches somewhere between the Tor exit relay and Ebay may also be able to determine who is doing the searches based on the content of the Internet traffic, because these Ebay searches are just like sending postcards in the mail. Said adversaries can view, record, and change any of the metadata or content.

13 of 31, tor / letter

TA3M Seattle, January 2016 - 13

1. Tor encrypts your Twitter-destined traffic in three layers before leaving your computer. Then, because Twitter requires that you use HTTPS to connect to Twitter, the first connection to Twitter establishes HTTPS (red), and then all of your Twitter-bound traffic will be encrypted in four layers of encryption.

2. Green circle: the Tor encrypted traffic from your computer to the Tor guard relay. The guard relay removes this first layer of encryption.

3. Yellow circle: the Tor encrypted traffic from the guard relay to the middle relay. The middle relay removes the second layer of encryption.

4. Orange circle: the Tor encrypted traffic from the middle relay to the exit relay. The exit relay removes the last layer of encryption and sends your traffic on to Twitter. Because of HTTPS, the content of your Twitter-bound traffic is still protected.

Connecting to twitter.com over Tor and searching Twitter does not disclose your IP address or your identity unless you log in to Twitter. Logging in to Twitter would disclose your identity to Twitter. If you browse Twitter without logging in but search for things that could allow an adversary to identify who is doing the searches, then you may disclose your identity that way, too.

Network adversaries observing Twitter searches somewhere between the Tor exit relay and Twitter can not determine who is doing the searches, because these searches are like letters in the mail. Said adversaries can still view and record any of the metadata but not the content.

14 of 31, tor circuits

TA3M Seattle, January 2016 - 14

Unlike VPN circuits, Tor circuits are generated randomly by your local Tor client. Tor circuits are required to have significant international hops in order to minimize the threat of surveillance or attack from a potentially malicious volunteer operator operating multiple relays in different IP subnets. In addition to Tor circuit randomness when starting Tor Browser, circuits are automatically and randomly changed every 10 minutes.

The downsides of using Tor is that, due to the required use of three geographically diverse hops, each of which likely has limited bandwidth, both high-latency and low-bandwidth experiences are high probabilities.

This is more of a positive than a negative, especially versus a typical VPN, but a Tor user must trust a random selection of roughly 2,000 guard relay operators and roughly 1,000 exit relay operators per circuit. Further, the Tor specification requires that relays belonging to the same operator cannot be used within the same circuit, presuming any given volunteer operator is not using different IP subnets.

15 of 31, tor circuits

TA3M Seattle, January 2016 - 15

By now, it should be clear that the number of relay operators is critical to the success of Tor and its users. Similarly, because all Tor traffic generally looks the same, it is similarly critical for the success of the Tor network for there to be a high number of users and services (Onion services).

Most purchasable Internet security services are built using a controlled set of infrastructure. This is a form of centralization. Tor is powerful exclusively because of the decentralized nature of the Tor network and the requirements of the Tor protocol. No other centralized security service can come close to having all of the security and privacy properties as Tor.

16 of 31, ads vs. nsa

TA3M Seattle, January 2016 - 16

We know that there are two active and constant threats to the Internet and thus its users: governments with intelligence agencies that are bent on the presumption that mass surveillance is valuable, and advertising agencies that are bent on collecting as much information about people as possible in order to sell them products. It just so happens that intelligence agencies are leveraging the work of advertising agencies because of their already deep integration into the large majority of the public Internet. Thus, the “biggest threat” to any Internet user is being attacked by advertising agencies.

However, we know that the NSA and FVEY (Five Eyes) focuses on traffic analysis leaving the Tor network, so it is highly probable that the same focus occurs for IP subnets associated with VPN service providers.

https://medium.com/message/the-hypocrisy-of-the-internet-journalist-587d33f6279e

https://www.eff.org/deeplinks/2013/12/nsa-turns-cookies-and-more-surveillance-beacons

17 of 31, vpn behavior

TA3M Seattle, January 2016 - 17

18 of 31, vpn behavior

TA3M Seattle, January 2016 - 18

These are examples of two connections to two random Internet services via a one-hop proxy in Sweden. It should be quite obvious how simple this is and how trivial it would be for a global adversary to track low-latency, one-hop proxy connections.

19 of 31, vpn behavior

TA3M Seattle, January 2016 - 19

VPN services might feel safe. Especially when you pull out your credit card, you expect to get what you think you’re buying. But its largely false if your goal is to defend personal privacy. VPNs are still really powerful for getting around censorship, sometimes. VPNs are also still really powerful for file sharing. But both advertising agencies and intelligence agencies are not slowed by technologies that are trivial to undermine with automatic network and data analysis.

Also important to understand is that when you hire one corporate entity to safeguard your privacy, you create one target for an adversary to legally or technically attack. Nobody can assure that VPN services do not maintain connection logs; we know that they are required to maintain payment logs, and we know that some service providers have handed over connection information while also advertising that they do not store connection information.

20 of 31, tor behavior

TA3M Seattle, January 2016 - 20

21 of 31, tor behavior

TA3M Seattle, January 2016 - 21

These examples of two Tor circuits demonstrates why adding complexity to network connections is valuable, especially compared to standard options (HTTP, HTTPS, or VPN).

22 of 31, tor behavior

TA3M Seattle, January 2016 - 22

I included this slide again to further stress the importance of diversity of the Tor network.

23 of 31, onion services

TA3M Seattle, January 2016 - 23

Common client-server connections entails you making a request to a server, to see if that server is available, and to request digital resources if the server is available. This is done by communicating directly with the server. Onion services do not work this way.

Onion services, like the ProPublica Onion site, is like a permanent Tor user that is constantly connected to the Tor network. You, the client, and ProPublica, the server both inform the Tor network of your hidden identities. The only difference is that you, the client, makes an anonymous request to the Tor network to ask if the ProPublica server is available. The Tor network, automatically and anonymously, connects the two of you through a random rendezvous point inside the Tor network. You never actually talk directly to the ProPublica Onion site, and you both have your own three-hops to protect your IP address. Since none of this traffic ever leaves the Tor network, Onion services are not vulnerable to standard forms of passive Internet surveillance.

24 of 31, onion services

TA3M Seattle, January 2016 - 24

In addition to being free from passive Internet surveillance, Onion services have significant security properties.

It is important for user-focused security to be default, such as high-grade HTTPS. It is also important to empower users by offering a diversity of security properties. It is important to remember that it is impossible for any one organization to fully grasp each personalized threat model for every one of their users.

Aside from the obvious user-focused security benefits of providing Onion services, there are obvious organization-focused security benefits. For example, many Fortune 1000, 500, or 100 companies commonly have website outages because of problems with DNS, BGP, or their CA. Providing Onion services helps mitigate losing access to Web resources because of these failure points.

25 of 31, onion services

TA3M Seattle, January 2016 - 25

The quote on slide 24 is from Roger Dingeldine as stated in his 32C3 talk, “Tor Onion Services: More Useful Than You Think”. It is a very informative talk and covers deeper issues, problems, and opportunities for the future of Onion services.

https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_think

Every “State of the Onion” presentation is worth watching and would be an excellent primer into understanding the nature of Tor and the quality of the people behind it.

https://media.ccc.de/v/32c3-7307-state_of_the_onion

26 of 31, onion services behavior

TA3M Seattle, January 2016 - 26

This example of a client accessing an Onion service demonstrates the complexity and importance of Onion services. Because both the client and the server makes independent Tor circuits, both maintain anonymity while also providing end-to-end encryption.

27 of 31, onion services hosting

TA3M Seattle, January 2016 - 27

If you are interested in learning about or advocating for the use of Onion services, these are some useful resources.

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

https://storify.com/AlecMuffett/tor-tips

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

28 of 31, tor browser

TA3M Seattle, January 2016 - 28

If you are brand new to Tor, or generally need assistance with using a personal computer, these step-by-step guides are perfect for Tor Browser installation and basic use.

https://ssd.eff.org/en/module/how-use-tor-windows

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

29 of 31, tor browser

TA3M Seattle, January 2016 - 29

Tor Browser, when juxtaposed to normal Web browsers, has significant advantages when the goal is to minimize identity exposure and the effects of Web tracking. Browser plug-ins cannot accomplish these privacy-focused goals, and many of these problems are identity-divulging browser features that advertising agencies always exploit.

30 of 31, tor applications

TA3M Seattle, January 2016 - 30

This list is a list of Tor related software applications for different platforms. It is not an exhaustive list, and in my talk I briefly described the purpose of each one.

31 of 31, questions?

TA3M Seattle, January 2016 - 31

If you use a version of this presentation, be sure to leave ample time for questions!

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,