This is work in progress.
Category Archives: Information Privacy
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.
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.
Moved from Apache to Caddy and RSA to EC TLS for WordPress
^ Qualys SSL Labs test for yawnbox.com
^ Security Headers (dot-IO) test for yawnbox.com
With very special thanks to this guide, Running WordPress with Caddy. I was also able to remove several unnecessary PHP applications that Apache needed.
Here’s my Caddyfile:
www.yawnbox.com {
redir https://yawnbox.com{uri}
}
yawnbox.com {
root /var/www/
log stdout
errors stderr
header / {
Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'"
Referrer-Policy "strict-origin, strict-origin-when-cross-origin"
Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "DENY"
}
fastcgi / /var/run/php/php7.1-fpm.sock {
ext .php
split .php
index index.php
}
rewrite / {
to {path} {path}/ /index.php?{query}
}
tls / {
protocols tls1.2
curves p384
key_type p384
}
}
House Bill 1909: Automatic License Plate Reader Systems
My testimony to the State of Washington House Transportation Committee:
Chair Clibborn and members of the committee, my name is Christopher Sheats, Chair of the Privacy Committee for Seattle’s Community Technology Advisory Board, and Chair of the Seattle Privacy Coalition. I want to make clear that any form of Automatic License Plate Reader (ALPR), regardless of its security or policy controls, is fundamentally a mass-surveillance system for the simple fact that it indiscriminately collects data about everyone.
ALPR mass-surveillance systems collect an incredible amount of personal information.
Where are you and where are you not?
Where are you heading?
What time were you there and not anywhere else?
Who else was traveling or not traveling around that time?All of these personal facts can facilitate identifying our interests, affiliations, activities, and beliefs. Data collection, and any amount of data retention, allows for the copying and sharing of said data. According to the U.S. Department of Transportation Bureau of Transportation Statistics, an “overwhelming majority of person trips—for all purposes—are taken in personal vehicles.” When mass-surveillance data of our vehicles is collected, granularly surveilling a state, a city, a community, or an individual becomes trivial.
Where do they live?
Who lives around them?
Where do they go to church?
Who else goes to their church?
Where do they work?
When do they visit their friends and family?
When do they drop their children off at school or childcare?
When do they leave the house to go grocery shopping?
When do they visit their doctor and how often?Answering these questions go above and beyond “personal information,” yet these questions become answerable when data collected by an ALRP mass-surveillance system is gathered by an abusive government or hacker, domestic or foreign.
If the State is to condone APRL mass-surveillance systems, whereby we have precluded we will not protect human rights by not collecting personal data in the first place, the only other rational alternative is to not retain collected data for any period longer than absolutely needed.
Thank you for your time.
Concerns of mine that I did not include in my testimony because of the delicate nature of politics:
Regarding House Bill 1909, I have several concerns:
1. How is House Bill 1909 going to impact RCW 40.24 — Address Confidentiality for Victims of Domestic Violence, Sexual Assault, and Stalking? Particularly, how is House Bill 1909 going to protect vulnerable people from law enforcement abuses?
2. Is any part of the ALPR mass-surveillance system, including data retention, managed or operated by unregulated third party providers?
3. Why are third parties not explicitly barred from owning and operating ALRP mass-surveillance systems?
4. What specific controls and audit safeguards will be put in place to prevent system operators from performing unapproved searches of people or vehicles?
5. Once data is collected by mass-surveillance systems, it can be copied, used, copied again, and re-used for unimaginable purposes. What specific controls and audit safeguards will be put in place to prevent data copying by federal agency data systems such as regional Fusion Centers?
6. The “Second War Powers Act of 1942” removed Census privacy protections of Japanese-Americans, allowing federal agents to know exactly where go and whom to arrest. How is Washington State going to defend us from unconstitutional policy changes brought on by an illegitimate U.S. President?
Surprise props from the City
From January CTAB Minutes:
One last thing, because I’m trying keep within my five minutes, I really want to say thank you to Christopher Sheats for the ongoing support as chair of CTAB Privacy Committee. I find it very invigorating to go to the CTAB Privacy Committee meetings, and look forward to their continued work and the guidance of that committee. I’m very thankful for the initial feedback. We have a little more baking to do on our side, and then we’ll be back in front of this group and Privacy to think about controls and how we consider deployment of that technology. I imagine that Christopher will have more to share about how the ACLU has been working with Councilmember Gonzalez on a rewrite of the City’s surveillance ordinance, which we agree that the current ordinance is not very effective, just in the way that it’s structured. It lacks accountability. It lacks clear definition. As a result, I don’t think the community or the City is getting the value of that legislation. One thing I’ve encouraged this group to think about is what role you would like to have in providing input to the rewrite of the surveillance ordinance. Be think about how you might want to engage the councilmember in making that desire to [unintelligible]. Christopher, I hope I’m not impeding on your update. But I put that out there to make sure that it’s on your wavelength. If there’s anything I or we can do to in the way of support, please let us know.
New Democracy Now! Onion site
Updated onion address: 2017-March-12
Previous work here. The rest of this post is for technical individuals.
I recently moved to a new DN! host mainly because my first one ran out of storage. I apologize to those who have not been able to access the last few episodes due to the old host filling up. This post goes into detail how I set up the new Onion site, then how I transfered all ~30GB of existing DN! files from the old host to the new host exclusively over Onion service via rsync.
Some major improvements include Democracy Now’s third-party services all support TLS now, meaning that I’m finally pulling the media via authenticated and confidential (exluding metadata) transport. My updated shell script is below, too.
Please note that not all traffic is torified on the new host, the DN! files are still getting pulled via port 443, outbound DNS via port 53, and outbound NTP via port 123.
New Ubuntu 16.04 Xenial host setup
Enable the firewall disabling all inbound traffic:
sudo ufw enable
Edit sources list to remove the default HTTP repositories with Wikimedia’s HTTPS repositories for transport authentication and confidentiality, and add Tor Project’s HTTP repository:
sudo vim /etc/apt/sources.list
deb https://ubuntu.wikimedia.org/ubuntu/ xenial main restricted universe multiverse
deb https://ubuntu.wikimedia.org/ubuntu/ xenial-updates main restricted universe multiverse
deb https://ubuntu.wikimedia.org/ubuntu/ xenial-backports main restricted universe multiverse
deb https://ubuntu.wikimedia.org/ubuntu/ xenial-security main restricted universe multiverse
deb http://deb.torproject.org/torproject.org xenial main
Add the Tor Project’s signing key:
gpg --keyserver keys.gnupg.net --recv 886DDD89 gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -
Update, upgrade, then install the necessary Tor apps:
sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get install tor apt-transport-tor deb.torproject.org-keyring -y
Edit torrc to create the new Onion site address:
sudo vim /etc/tor/torrc
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 22 127.0.0.1:22
HiddenServicePort 80 127.0.0.1:80
Restart the Tor service:
sudo service tor restart
View the new Onion site address:
sudo cat /var/lib/tor/hidden_service/hostname
gnt3qwmxads3yytg.onion
Edit sources list again so that the repositories will only be accessed via Onion service:
sudo vim /etc/apt/sources.list
deb tor+https://ubuntu.wikimedia.org/ubuntu/ xenial main restricted universe multiverse
deb tor+https://ubuntu.wikimedia.org/ubuntu/ xenial-updates main restricted universe multiverse
deb tor+https://ubuntu.wikimedia.org/ubuntu/ xenial-backports main restricted universe multiverse
deb tor+https://ubuntu.wikimedia.org/ubuntu/ xenial-security main restricted universe multiverse
deb tor+http://deb.torproject.org/torproject.org xenial main
Update and upgrade again, and install Open-SSH, all via Onion service:
sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get install openssh-server
Configure the SSH server to only accept connections via Onion service. Also harden the security a little bit:
sudo vim /etc/ssh/sshd_config
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
AllowUsers user
Port 22
ListenAddress 127.0.0.1:22
Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 30
ServerKeyBits 4096
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 30
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
Install Apache via Onion service, disable status, and enable headers:
sudo apt-get install apache2 -y && sudo a2dismod status && sudo a2enmod headers
Configure the index view of the Apache landing page:
sudo vim /etc/apache2/mods-available/autoindex.conf
IndexOptions FancyIndexing VersionSort HTMLTable NameWidth=* DescriptionWidth=* Charset=UTF-8 SuppressDescription SuppressIcon SuppressLastModified SuppressRules
IndexOrderDefault Descending Name
Harden Apache’s security configuration:
sudo vim /etc/apache2/conf-available/security.conf
Directory /
AllowOverride None
Require all denied
/Directory
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'"
ServerTokens Prod
ServerSignature Off
TraceEnable Off
Configure Apache to only work via Onion service:
sudo vim /etc/apache2/sites-available/000-default.conf
VirtualHost 127.0.0.1:80
ServerName gnt3qwmxads3yytg.onion
ServerAdmin gnt3qwmxads3yytg@yawnbox.com
DocumentRoot /var/www/html/dn/
LogLevel info
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
/VirtualHost
Restart Apache:
sudo service apache2 restart
Make the DN! directory:
sudo mkdir /var/www/html/dn/
Create the shell script to download the various DN! files:
sudo vim dn-now.sh
#!/bin/bash
cd /var/www/html/dn/
daystamp=$(date +%Y-%m%d)
wget -m -p -E -k -K -np -nd -e robots=off -H -r https://publish.dvlabs.com/democracynow/360/dn$daystamp.mp4
wget -m -p -E -k -K -np -nd -e robots=off -H -r https://traffic.libsyn.com/democracynow/dn$daystamp-1.mp3
wget -m -p -E -k -K -np -nd -e robots=off -H -r https://ewheel.democracynow.org/dn$daystamp.mp4.torrent
chown -R www-data:www-data /var/www/html/dn/*
Edit cron to check for new files every 15 minutes:
sudo crontab -e
*/15 * * * * bash /home/user/dn-now.sh
Old Host
Configure SSH client to be torified:
sudo vim /etc/ssh/ssh_config
Host *
ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p
CheckHostIP no
Rsync all files from the old host (ssh client) to the new host (ssh server):
sudo rsync -v /var/www/html/dn/* user@gnt3qwmxads3yytg.onion:/var/www/html/dn/
Cheers!
iPhone opsec guide
Note: Be aware that these operational security guidelines are generally not applicable if you’re attempting to evade your own government’s surveillance. Not only do all new iPhone registrations (software and hardware identifiers) go through NSA-surveilled datacenters, the only way to avoid passive or active cellular tracking is to not use a cell phone. Further, everything listed here depends on your threat model.
Physical security
- Assure that your iPhone is generation 6 or greater (A7, A8, A9) to benefit from Secure Enclave.
- Only use a randomly-generated (stored offline and/or memorized) 12+ digit alphanumeric passphrase.
- Enroll in TouchID to minimize shoulder-surfing passphrase disclosure, but be aware of where you leave your fingerprints.
- Register your iPhone on someone else’s account so not to attach SSN to IMEI/IMSI/SIM.
- Register a new, random phone number.
- Do not pay for your iPhone with your credit or debit card.
- Never pay service charges with your credit or debit card.
- Never share the iPhone’s real phone number with anybody.
- Use only VoIP phone numbers for app registration (Signal).
- Never connect your iPhone to PCs in order to minimize infection and to minimize security certificate sharing.
- Only charge your iPhone directly from power or using a power-only USB cable.
- Always keep Wi-Fi disabled. Wi-Fi networks track hardware MAC addresses that get reported to centralized databases (Cisco Meraki, etc) for tracking and/or advertising purposes, and you do not want to disclose your physical location any more finitely to third party services via IP address.
- Always keep Bluetooth disabled.
- Always turn your iPhone off at night.
- Always turn your iPhone off when you are going to be away from the device.
- Always turn your iPhone off when passing through security screenings.
- Store your iPhone in a locked safe when leaving unattended.
- Do not bring your iPhone to events that have moderate-to-high risk of being confiscated, or at least keep your iPhone off at these events.
- Do not let others use your iPhone.
- Remove the microphone from your iPhone.
- Remove all cameras from your iPhone or keep the cameras covered with tape or stickers.
- When needing to carry the device but minimize surveillance, power off your iPhone and store it in a Faraday cage.
- Be aware that the NSA CO-TRAVELER program keeps track of your iPhones location and which devices your iPhone is ever in close proximity to.
Software security
- Never use your iPhone for Web browsing.
- Sign out of iCloud.
- Do not enable Siri.
- Use parental controls to disable Safari.
- Only install trusted apps (Signal) to minimize exposure to remote infection.
- Never sign into any cloud-based email-, calendar-, or contact-syncing accounts.
- Manually input contacts and keep contacts stored locally.
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.
Focus Determines Reality 
