My friend Hubert has started compiling statistics of Alexa’s top 1 million websites. Specifically, he’s looking at their SSL/TLS settings and attempting to show trends in the world that is port 443. He recently released his May numbers showing a slow but mostly improving security environment. I’m hoping he’ll be able to chart these trends in a way to make it easier for people to consume the data and be able to dynamically look for data that they are interested in. I guess we’ll have to wait and see what come about. Until then I believe he’ll continue to post his monthly numbers on the Fedora Security List.
Okay, I don’t really mean to advocate this as a privacy solution because it is and it isn’t. If you truly want privacy of your email you must use end-to-end encryption like PGP/GnuPG or S/MIME. That said, I think it’s good to encrypt things, even ciphertext, over the network. So STARTTLS for SMTP is a good start.
What, exactly, is STARTTLS? Well, it’s an opportunistic protocol that goes out and asks a server in which I want to talk with if it supports encryption. If it does then we negotiate the terms (ciphers, keys, certs) and then we establish a circuit and exchange the information. If it doesn’t support encryption I just skip the setup of the encrypted circuit and transmit the data in the clear. Yeah, not a great solution and I really hate the thought of STARTTLS as it isn’t a guarantee that the data transferred will be encrypted (unlike, say, HTTPS).
Earlier today Kurt pointed me at a study done by Facebook. Yeah, everyone knows I hate FB but really they are in a great position to do such a study. According to their study, “Facebook sends several billion emails to several million domains every day”. Okay, that’s a lot of email. And with that amount of exposure to the worlds’ SMTP servers I’m guessing they’ve hit most of the servers out there. Turns out 76% of those servers support STARTTLS and most actually use a good cipher suite and PFS. Unfortunately it appears that most mail is routed to providers that aren’t supporting good crypto suites. The report doesn’t name them so I figured I’d go out and see if I could find some of the deficient setups.
The obvious first choice was Google’s Gmail. As long as the incoming server connects to port
465 587* they should get an encrypted circuit supporting TLSv1.2 protocol with a cipher of ECDHE-RSA-AES128-GCM-SHA256. Great, I have no complaints here. Hmmm, so who is next? I guess Hotmail is still a biggie and Microsoft does have all those B2B services as well. It seems TLSv1.2 with a cipher of ECDHE-RSA-AES256-SHA384 is being used on at least some of their SMTP servers. What’s next? Ahh, yes, Yahoo! is still in business (although I seriously don’t know how). Yahoo! just implemented encrypted connections for their webmail users so clearly they should have fixed their backend connections as well, correct? Well, they are the first to make my bad list by using the TLSv1 protocol with the cipher of RC4-SHA. Come on guys, get it together! Let me see what my provider, Bluehost, is doing here. It appears that, like Google, they support TLSv1.2 and are using the cipher of DHE-RSA-AES256-GCM-SHA384. Again, a great choice (although the AES256 is a bit much but that’s a different post all together).
I might, one day, setup a scanner to more thoroughly collect this data and make it available in more real-time but for now I think the Facebook data is awesome and quite timely.
*As was pointed out in the comments port 587 is a user port and is used for authenticated SMTP access from clients. Once the SMTP server has the message to be delivered the server will connect over to the distant SMTP server over port 25 unauthenticated. Port 25 can be just plaintext or can use STARTTLS. As an aside, why port 25 outbound (and inbound?) is blocked for many residential customers is because it is unauthenticated and a present a good entry point for spam.
If you’ve done any reading of 20th century European history then this story will seem familiar. Back then there were places where you had to be careful about what you said to whom. It could really be anything you said to any number of people including close friends, family members, and business associates. Conversations, even out of context comments, could be used against you for any reason. Trumped up charges or a violation of some old, obscure law could get you detained by the police or worse.
Here in the United States we had our constitution and, more importantly, the Bill of Rights to protect people from an over-reaching government. We didn’t see first-hand what many Europeans did. We felt protected based on a few words written down on paper. We became complacent.
An article was shared with me earlier today. The Guardian retells the story of police coming to someone’s home and interrogating the resident based on their Google searches and what they have viewed on the Internet.
Some might say “but after <fill in the event here> we have to do something so it won’t happen again”. Sure, there are things that need to happen to help prevent such future activities but “doing something” isn’t a real solution.
Fear drives power and if there is power up for grabs then the scariest thing wins. Detonate a bomb and you get fear. Unfortunately talking about detonating a bomb usually generates more fear. Many people will give up nearly everything just to have someone tell them that they are safe. Right now privacy is what’s taking most of the hits and it’s easy to understand why. It’s easy to control people, make a lot of money, and generally be able to “terrorize” anyone you don’t like when you have the keys to their thoughts. Having access to people’s thoughts is even easier today than it was fifty years ago. Today people talk via email, IM, and other digital means that generally go through a few centralized servers. Get to the servers and you’ve got access to the thoughts and feelings of millions of people. You now have leverage over almost anyone you wish.
Unless we want history to repeat itself we need to stand up to these types of actions. It is not okay to go sifting through my Internet searches. It is not okay to read my email. It is not okay to come to my home and interrogate me and my family. It’s time for this to stop.
Why Privacy Matters Even if You Have ‘Nothing to Hide’ by The Chronicle Review
Using Metadata to Find Paul Revere by Kieran Healy
We Should All Have Something To Hide by Moxie Marlinspike
Someone recently asked what my GPG.conf file looks like since he hadn’t updated his in… years. Okay, let’s take a look and I’ll try to explain what each setting is and why I feel it is important. I’m not guaranteeing this as being complete and I welcome input from others.
This says that if a program needs a public key but it’s not in my keyring that it should automatically reach out to the keyserver (see below) and download it.
This says to use the GPG agent. I cannot remember, right now, why this was a good idea. Perhaps it isn’t?
auto-key-locate cert pka ldap hkps://hkps.pool.sks-keyservers.net keyserver hkps://hkps.pool.sks-keyservers.net keyserver-options ca-cert-file=/etc/ssl/certs/sks-keyservers.netCA.pem keyserver-options no-honor-keyserver-url keyserver-options auto-key-retrieve
Almost the fun stuff there. This is just setting up the keyserver that I wish to use (note the use of hkps instead of hkp).
default-preference-list AES AES192 AES256 TWOFISH SHA1 SHA224 SHA256 SHA384 SHA512 Uncompressed ZIP ZLIB BZIP2 personal-cipher-preferences AES256 TWOFISH AES192 AES personal-digest-preferences SHA512 SHA384 SHA256 SHA224 personal-compress-preferences BZIP2 ZLIB ZIP
Okay, the fun stuff. These are all the algorithms that I wish to use. If you setup your GPG key to advertise these then it will make it easier for others to use the most secure algorithms since they will already know what you can do. The first line just lists all the preferences. The second, third, and fourth lines actually provide the preferences in order of them being used. If you’ll note my preferred cipher is AES with a 256-bit key and my preferred hash (digest) is SHA with a 512-bit key. There are other options available and a quick
should provide what options are available to you. For instance, my current installation says that its supported algorithms are:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
I’ve omitted 3DES, MD5, and SHA1 from my preferences due to their weaknesses but I could still use them according to my GnuPG software.
Again, this wasn’t meant to be a strict “thou must do this to be secure” but rather a “this is what I’m doing” sort of thing. I’d appreciate feedback!
I was recently introduced to a privacy issue when refreshing your OpenPGP keys using GnuPG. When refreshing your public key ring using a public key server GnuPG will generally use the OpenPGP HTTP Key Protocol (HKP) to synchronize keys. The problem is that when you do refresh your keys using HKP everyone that you maintain in your public key ring is sent across the Internet unencrypted. This can allow anyone monitoring your network traffic to receive a complete list of contacts in which you may hope to use OpenPGP.
The fix is quite simple: in your gpg.conf file make sure that your keyserver entries include hkps:// instead of hkp://. This will force GnuPG to wrap HKP in SSL to keep the key exchange private.