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.
Like it or not, the basis of trust for much of the Internet is based on Certificate Authorities (CA). Companies like Verisign, GoDaddy, and GeoTrust are in the trust business. They will sell you cryptographic proof of your Internet assets (namely your domain name) that others can use to verify that when they visit your website that they are actually visiting your website and not some lookalike website. This is important as you don’t want to give your login credentials to your bank account to a lookalike web page that really isn’t your bank.
The trouble is, how do you know the CAs are doing their due diligence and not just issuing certificates to people who just claim to own a particular domain name? Well, I’m not sure we do know, as users. Mozilla, like other web browsers, has a policy for including CAs in their browser product but a quick look at the list of CAs that are already in Firefox shows that we as users probably can’t go behind and verify them all.
If I were a conspiracy theorist I would be looking real hard at what the Electronic Freedom Foundation (EFF) recently released about the NSA spying program. According to their research (and that of the Guardian and others) the NSA is actively performing man-in-the-middle attacks (MITM) to get malware into computers. This malware allows the NSA (and anyone else capable of accessing these infected computers) to circumvent protections put in place to keep information passed over the Internet secure. To do these MITM attacks one would need to provide users with a valid SSL certificate if they happen to be visiting a site that is supposed to be secured. The only way of doing this is to either obtain the SSL certificates from the real sites or to create their own and have them trusted by a trusted CA. With that in mind, I wonder which option is more probable?
It’s good to note that these types of attacks are not solely done by the NSA. Gaining access to computers is a very profitable business and one that people other than governments can do. It’s important to protect yourself against these attacks and be smart when surfing the Internet. The end of the EFF story contains information on how to protect your computer (and yourself) and is a good read for everyone.
Not that this is really news but if you hand your message to a third-party for delivery you have no expectation of privacy. Agree with it or not that’s the way it is inside the United States. This is why it is important for people to use end-to-end encryption (like GnuPG) to protect the contents of messages being sent through any email provider. The same goes for using any instant messenger service, SMS, or telephone that uses a third-party provider.
This isn’t anything new, really. Ever since the telegraph was invented people have encrypted messages before handing them to a third-party for delivery. The Engima machine was actually developed as a business tool that was later used by the German military during World War II. Businesses needed to protect their communications during transit across a third-party. Today there isn’t a person sending your message to a distant point but rather a computer system that can not only efficiently and accurately send your message across distant lands but can also make a copy of that message and share it with whomever they wish.
While it has become easier for companies to share your messages with governments and third parties it has also become easier to protect your messages with encryption. The question now is how to make this technology easier for people to use and, perhaps more importantly, make people care about securing their messages. This last part is probably most important.
We’ve been kicking the ball down the field for a while. When Google implemented TLS encryption for its Gmail service people raved about the security measure. Sure, what they did was important as it prevented anyone watching the network traffic between the user and Google from seeing what was happening. But that left Google having open access to the contents of the messages being sent. This is the case for all email providers that use TLS encryption to secure the communications between users and their servers. Now is the time to fill that gap. How to do that easily is still up for debate.
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.
An excellent description of how Tor and HTTPS can help protect your online privacy and secure your web communications.
I’m happy to read the Washington Post story discussing the House committee’s hearing on the NSA’s domestic spying programs. It’s encouraging that both parties aren’t happy with the programs and that “…there are not enough votes in the House now to renew Section 215 [of the Patriot Act] when the law is revisited.”
Of course the wrong arguments were being made by Stewart Baker, the former NSA general council. Using fear mongering techniques, Baker talked about the failures of the NSA prior to September 11th (which was an investigation failure and not an intelligence failure) and how the “hyped and distorted press reports orchestrated by Edward Snowden” was out to harm the intelligence agencies. Baker should have been addressing the civil liberties that are being put at risk and the risks to the First and Fourth Amendments.
Needless to say, I’ll be following these hearings closely.
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.