A simple thought experiment exposes how unimaginably dumb a proposal to demand traveler/visitor social media usernames and passwords is: imagine if a country demanded President Trump's Twitter password as a condition of his crossing their border. It's ludicrous... there are few things more invasive then demanding control of another's identity.
This is completely outrageous, I didn't believe it when a reporter brought it to my attention, it's such a boneheaded idea; it will significantly undermine the safety and security of all social media users. Social media and tech companies would be apoplectic. Asking people that cross the border for their social media identifiers is one thing, and it's plenty invasive enough (CDT and many others argue this threatens privacy and free speech.)
Asking for passwords and other credentials is beyond the pale, akin to asking for a traveler's most intimate thoughts as a condition of travel (or they can opt not to use these services, which is increasingly not an option, especially for business employees who may maintain social media accounts that are not personal accounts).
With that kind of access, they can not only see what you've publicly posted, but things you haven't posted yet, private messages, private lists, they can impersonate you, even do these things on accident. This kind of access is profoundly invasive. We increasingly use social media identities for so much more than just sharing our thoughts; using federated authentication ("log in with your Facebook account!"), people may use their social media account to log into a health care portal, a financial or tax prep account, and many other services.
Moreover, most major social media services offer non-password methods of logging in, for example "two-factor authentication" where they send you a text message that you have to enter in addition to a password to login. What if you don't have access to that particular phone while traveling? If you do, do they get to search your phone to?
This is absolutely ridiculous... There's not even a 1:1 mapping of people to accounts! Many of us have quite a few accounts on the same service... Do I have to disclose them all? Just one? Which one?
There is no way this can stand.
I'm a big fan of my friends and colleagues at Let's Encrypt, an effort to make it easier to encrypt the web by offering web encryption certificates for free, for ever.
At first, free Let's Encrypt (LE) certificates were not so easy to obtain... you had to be essentially a coder and administer your own server to get it all to work. Not so, anymore! Now the number of ACME clients (the underlying protocol that Let's Encrypt uses) has exploded.
So, while I am only a bit of a coder, I wanted to see if it could be possible for someone with minimal system administration skills to actually get an LE cert and install it. The answer is yes, it is relatively easy to do!
My task: I wanted to see if a non-root (non-adminstrative) owner of a website using the cPanel hosting software could get an LE cert. To follow this, you need to be reasonably familiar with the command-line, but not much else.
You'll need to be able to login to the command line of your domain's server. Then, you'll want to make sure both openssl and python are installed (likely yes):
% which openssl /usr/bin/openssl % openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 % which python /usr/bin/python % python --version Python 2.6.6
(Pay attention to that Python version as it throws a wrinkle into this later.)
We'll be using the acme-tiny python script from Daniel Roesler. You can follow those instructions, but I'll repeat them here. You'll need a private account key to identify yourself with LE (this generates a 4096-bit RSA key pair,
account.key, that contains both the private and public keys). You'll also want a keypair for your domain (
openssl genrsa 4096 > account.key openssl genrsa 4096 > domain.key
Be very careful with these files as they contain the private keys to the kindgom! You can extract the public key from the key pair by:
openssl rsa -in account.key -pubout > account.pub
While you can generate the keys on another system (like your laptop), you'll need to copy them over to your server and then run the rest of these commands on that server.
You'll now need to create a certificate signing request (CSR) that asks LE to sign your public key.
#for a single domain openssl req -new -sha256 -key domain.key -subj "/CN=yoursite.com" > domain.csr #for multiple domains (use this one if you want both www.yoursite.com and yoursite.com) openssl req -new -sha256 \ -key domain.key \ -subj "/" \ -reqexts SAN \ -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:yoursite.com,DNS:www.yoursite.com")) \ > domain.csr
(sorry, this gets cut off so copy and paste it into a text editor before doing anything with it.)
And note that the line that reads
cat /etc/ssl/openssl.cnfis specific to Debian flavors of linux. You'll need to change to something like the following depending on the system you're running:
#change "/etc/ssl/openssl.cnf" as needed: # Debian: /etc/ssl/openssl.cnf # RHEL and CentOS: /etc/pki/tls/openssl.cnf # Mac OSX: /System/Library/OpenSSL/openssl.cnf
Now, you need to make a directory that your user account on the server can write to in a very specific place that ACME/LE expects it to be:
mkdir -p /foo/www/.well-known/acme-challenge/
/foo/www/is the path on your server to your root web directory.
Here's where the magic happens. You'll now want to use acme-tiny to send the CSR under your LE account key to the LE to do the challenge (prove that you're on the domain that you claim):
#run the script on your server python acme_tiny.py --account-key ./account.key \ --csr ./domain.csr \ --acme-dir /foo/www/.well-known/acme-challenge/ \ > ./signed.crt
This will result in a file called
signed.crtthat is the LE-signed certificate for your domain!
Note: if you are running Python earlier than 2.7 you don't have the
argparsemodule. In that case, you'll want to add the directory you're in to the
PYTHONPATHvariable and then install argparse inside your account with:
easy_install --install-dir=. argparse
If you are running the nginx webserver, you'll need to add an intermediate certificate to your cert before you install it... but it doesn't hurt to just add the intermediate anyway:
#NOTE: For nginx, you need to append the Let's Encrypt intermediate cert to your cert wget -O - https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem > intermediate.pem cat signed.crt intermediate.pem > chained.pem
Cool! The file
chained.pemis the certificate you'll want to install in cPanel.
Now you have an LE cert and a private key and you'll want to add both of these in cPanel and then install the certificate itself. To do this, log in to cPanel and navigate to the "Security" section and click "SSL/TLS". Click on "Private Keys" and then in "Upload a New Private Key" select the
domain.keyfile you generated above and submit it. Return to SSL/TLS Manager.
Now, click on "Certificates" and in the "Upload a New Certificate" section, select the
chained.pemfile you created above and submit it. Return to SSL/TLS manager.
Finally, click on "Install and Manage SSL for your site (HTTPS)" and click "browse certificates" and install the one you just submitted above.
You should be able to navigate to
https://yoursite.comand click on the lock to verify that you are encrypted against an LE cert!
So what if you don't want the NSA to see a particular file or email? If they're really wiretapping the whole goddamn internet, how can you keep secrets?
Well, you have to encrypt them. And the standard for strong encryption is PGP -- Pretty Good Privacy. PGP will lock up files and emails so that others cannot break into them.
I've heard people say recently that PGP is very hard to install, understand, and use ("Guardian reporter delayed e-mailing NSA source because crypto is a pain"). PGP -- or the open source equivalent GnuPG (Gnu Privacy Guard) -- is an encryption program, essentially like a mathematical lockbox for data and files... you can use it to encrypt files and emails in such a way that no one can get access to that information without compromising your laptop or desktop.
After hearing it was hard and having a bit of experience with it myself, I asked myself, "Just what does it take to install a working version of PGP from scratch and send email? How hard could it be?". I decided to try and see what the install process looks like installing from scratch.
(Now, of course, I'm on a Mac and will want to install a mac-specific version of it and I'll want it to work with Mac email programs like Mail.app or Mozilla Thunderbird. (Sorry, Windows and Linux folks!))
It turns out it's pretty damn hard, in general... that is, if you want to do it right, in my opinion.
There are two options: a somewhat less difficult way and a hard way:
- The more difficult way -- I describe below -- has the added benefit of being likely maintained indefinitely and being built (compiled) directly from the canonical (standard) source code for GPG.
- The easier way uses -- what appears to be -- a very snazzy piece of software maintained by a small number of volunteers, GPG Tools. (I don't have anything against GPG Tools -- I use it myself for a number of things -- but I'm wary in crypto of using boutique tools not everyone else is using and relying on implementations that could disappear. I also prefer for this kind of security tool to build it from the source code that is being actively maintained and that everyone else is using.)
If you don't share my concerns with the uniqueness and dependence of GPG Tools, I very much recommend you simply install it and follow their getting started guide. GPG Tools is open source and easily uninstalled, and I bet even PGP/GPG vets will find something to love with it's keychain manager and Services integration... and it even installs non-destructively over existing MacPorts and Fink GPG installs (more about what those are next).
If you go this route, you'll still want to, at least, read the material I highlight in step 6 below; even with working encryption software, you will still need to know a bit about what encryption is and how to properly use it. Be sure to install it from the official location (check the SSL lock!) and check the SHA1 signature of the file (something like:
shasum GPGTools-2013.5.20.dmgfrom the command-line).
Ok, with that... if you want your own built-from-source version of GPG that can also be used to encrypt or sign email), here's how.
First, I'm sorry to say but you'll need to become familiar with the basics of the Mac command-line used in Terminal.app. This may sound onerous but it will only pay dividends in the future as you'll probably want to tinker more. Here is a good place to start: "An Intro to Mac OS X's Command Line Interface". Why do you need this familiarity? Because the open source, freely and generally available version of PGP -- GPG -- is best available to your system as a working command-line program, instead of the alternative of a more traditional Mac-like package (the approach of GPG Tools, discussed above).
You'll need to install Xcode and the command line tools from Apple (The Command Line Tools can be downloaded from inside Xcode's Preferences or in a separate package). These tools provide all the computer programming tools a Mac developer needs to turn human-readable source code into executable computer programs.
You should install a package manager like MacPorts or Fink. Both of these programs are sort of like "app stores" for uber-geeky programs: they allow you to download software -- such as GPG -- that you can install directly (or indirectly by compiling/building from source code). You interact with them via the command-line or via a GUI like Pallet (for MacPorts) or FinkCommander (for Fink). Most people I talk to seem to prefer MacPorts as it seems to be less complex but Fink is very well maintained and stable.
After getting MacPorts or Fink installed and up and running, you should install gnupg. On MacPorts, you'd type the following at the command-line as an admin user:
sudo port install gnupg
with fink this is:
sudo fink install gnupg
It will do a bunch of downloading and then will either compile the software from source code or it will install a binary version of the software that someone else has already compiled.
You now need to understand a bit of how encryption works. I'm not saying you'll need to understand the math, but you need to have a basic understanding of what a key is, what different types of keys are (symmetric/asymmetric), what signing is, how to verify a signature, how to share your key, how to protect your private key, and how to encrypt/decrypt files. I'd suggest you read, in this order, sections 1, 3, 4, and 5 of the GnuPG Mini-HOWTO manual.
Now, you should be able to encrypt and decrypt files and text. To get encryption in your email program, get GPGMail for Mail.app (it's installed with GPG Tools, so you may already have it!) or the Enigmail extension for the Mozilla Thunderbird mail client.
Send me an encrypted, signed email: https://josephhall.org/gpg-key.
I have to apologize to China, although if you're Chinese proper, I doubt you'll see this apology unless you're on vacation somewhere else or using a proxy.
I've noticed a steady uptick in traffic to this site, notably this blog, over the past few months:
After some sleuthing, it seems I'm pushing 15-20 GB of traffic to China alone each month! With something like 564 million Chinese on the internet (42% penetration), I guess this shouldn't be surprising. And, yes, it was all legitimate HTTP/HTTPS traffic, mostly to this blog.
As I can't afford to pay for extra bandwith, my only option was to throttle traffic to China (e.g., using this very handy .htaccess method -- for Apache webservers -- and list of Chinese IP addresses).
That seems to have worked:
I feel bad that I have to use such a blunt tool as this blocking maneuver, but I'm not sure what else to do. Please let me know if, for some reason, this impacts you (I cannot imagine how it would).
This past week I was at the kick-off meeting of the LA County Voting System Assessment Project's (VSAP) Technical Advisory Committee. The VSAP is Registrar/Clerk Dean Logan's intense and groundbreaking effort to design, develop, procure and implement a publicly owned voting system. I am honored to be asked to serve on such an important body.
LA County is the largest election jurisdiction in the US, with 5 million registered voters, 10 languages, 5,000 precincts and a very large physical area. The county currently uses the InkaVote Plus voting system (with Audio Ballot Booth for accessibility), which is essentially an overhaul of former punchcard equipment to use inked styluses for marking and to provide in-precint checks for the voter in case they make mistakes.
Here is the InkaVote Plus system and the Microcomputer Tally System (MTS) that is used to rapidly count (>1,200 ballots per minute!) ballots after they're returned to the Registrar's Norwalk, CA headquarters:
My fellow committee members include:
- Henry Balta (Senior Assoc. CIO, LA County)
- Mike Byrne (Professor of Psychology and Computer Science, Rice)
- Josh Franklin (IT Specialist, NIST)
- Diane Goldin (Policy Coordinator, AATAP)
- Joseph Lorenzo Hall (Senior Staff Technologist, CDT)
- Brian Hancock (Director, Testing and Certification, EAC)
- Jared Marcotte (Technology Manager, Pew)
- Noel Runyan (Principal, Personal Data Systems)
- Rich Sánchez (CIO, LA County)
- Pam Smith (President, VVF)
- Charles Stewart III, (Professor of Political Science, MIT)
- David Wagner (Professor of Computer Science, UC Berkeley)
The mission of the TAC is to provide technical advice to LA County through a design and development process to meet a variety of goals and principles that LA County has determined its voting system must meet.
While we'll have an official web page and other materials soon for public perusal, I was able to take a number of photos and videos during a tour of the tabulation and storage facilities that we had during the end of the day. Find them at this Flickr photo set.
I'll leave you with the following video, that shows just how fast their card reader tabulation system, the MTS, can count ballots -- a blazing 600 ballot cards in 28 seconds! This is just one example of a metric that will be difficult to match in a new system!