I’ve been arguing with my web hosting company about their use of RC4. Like many enterprise networks they aren’t consistent across all their servers with respect to available ciphers and such. It appears that all customer servers support TLS_RSA_WITH_CAMELLIA_256_CBC_SHA and TLS_RSA_WITH_CAMELLIA_128_CBC_SHA, in addition to TLS_RSA_WITH_RC4_128_SHA (although the latter is preferred over the other two) but their backend controlling web servers only support RC4. This is a problem if you are handling crypto (keys) (and other settings) over a weak encryption path to better secure your web service as you have essentially failed due to using the weak encryption to begin with.
So what’s wrong with RC4?
It’s been known for a while (years!) that RC4 is not a good encryption cipher. It’s broken and there are several attacks that are available. So why is it being used so frequently? In a word: BEAST. RC4 was the only stream cipher available that can combat BEAST and so it became the standard for all TLS connections. It’s not clear which attack vector is worse: BEAST or the weak RC4.
In recent months most Internet browsers have implemented the workaround n/n-1 to fix the BEAST vulnerability. With the fix in place it should, once again, be safe to use block ciphers and, thus, get better encryption ciphers (better protection). There have been many people and organizations talking about the need to get rid of RC4 now since it is a bigger threat to web security. Yesterday Microsoft released a security bulletin discussing the problem and urged all developers to stop using RC4. (Oh yeah, and they also want to stop using SHA-1 as well.) I usually think of Microsoft as trailing in the security field (lets face it, their products aren’t known for being secure ever since that whole network thing happened) so when they say that this mess with RC4 must stop it’s gotten to a point where we should have already done so.
So what are we waiting for?
I think, simply, we’re waiting for TLSv1.1 and TLSv1.2 to become mainstream. It’s not as if these technologies have just popped up on our radar screens, however, (they’ve been out since April 2006 and August 2008, respectfully) but there has been slow adoption of the two flavors of TLS. According to Microsoft, their products are ready for TLSv1.1 and TLSv1.2 (both IIS on and IE 11+). Firefox supports up to TLSv1.2 in 25.0 but you have to manually turn it on (it’s for testing) and OpenSSL (used for Apache) should support TLSv1.2 in its 1.0.1e release. It’s time to start pushing these better encryption mechanisms into operation… now.
Thought I’d pass along this research study, The keys to the kingdom, as I found it to be quite interesting (especially when you scan the entire Internet for your data). If you don’t understand the math explanation at the beginning just continue reading as you don’t need to have a degree in math and science to understand what’s going on.
This morning I was greeted with a blog post from the fine folks over at Qualys on how BEAST isn’t really still a threat (unless you are using an Apple product). BEAST, a vulnerability found in SSL and TLS 1.0, was discovered around this time a couple of years ago and put web users in a precarious position of using a poor cipher choice (RC4) or be vulnerable. Not to worry, however, as developers were able to come up with a solution to the problem (n/n-1).
So I mentioned the Qualys article in my $dayjob IRC channel where my always awake coworker provided information that Fedora is, in fact, still vulnerable to the attack. Thanks to a problem with pidgin-sipe connecting to a Microsoft server, the n/n-1 split was backed out of the NSS software leaving anything that depends on it potentially vulnerable (Chrome, Firefox, and Thunderbird to name a few).
There is a fix, although it’s not fantastic by any stretch of the imagination. By simply adding these two lines to your /usr/bin/firefox file the vulnerability should be fixed:
We added these two lines at line 36 and restarted Firefox. My way-too-awake coworker did a test and confirmed that it was working in his environment. Your mileage may vary.
Hopefully the fix for BEAST can be reapplied to NSS in Fedora soon as leaving users exposed can be dangerous.
Thanks to Hubert Kario for pointing me, and walking me, though this stuff before my morning coffee.
Update: 2013-09-12 @ 14:30 UTC
Apparently this problem will be persistent according to the NSS package maintainer. From the ticket:
I bit of information from the nss side of things. The nss disabling patch is not applied on Rawhide or f20, onlt applied on stable branches. After we branch Rawhide for the next fedora release and we enter in Alpha, I send emails to the fedora development mailing list telling them that NSS_SSL_CBC_RANDOM_IV=1 will be the default as they use updates-testing and ask for feedback on whether it causes problems. Twice they have said it still causes problems. There are still unpatches servers out there. Once we go beta I have to enable the patch again. f20 is entering Alpha soon so I’ll send that email again. I know this bug is for Firefox but I though worth informing you that we monitor this every six months for nss.
Update: 2013-10-10 @ 15:22 UTC
Update: 2013-10-17 @ 10:32 UTC
I believe this problem has been fixed (finally!) for Fedora 19 and beyond.
Much of our daily lives are contained within our smartphones and computers. Email, text messages, and phone calls all contain bits and pieces of information that, in the wrong hands, could harm our privacy. Unfortunately many people either don’t understand how vulnerable their data is when sent across the Internet (or another commercial circuit) or just don’t care. While I don’t have much to say for the crowd in the latter category (can’t fix stupid) I do try to help people in the prior category understand that any network outside of their control is fair game for pilfering and that basic protections need to be taken to protect themselves. While I’m not going to dig into how data can be intercepted (there are plenty of articles out there on the subject) I would like to talk about how one can use tools to protect their data when using an Android smartphone.
Until recently email was the only easily-encrypted mode of communication. Most people didn’t have the means of encrypting their phone conversations and certainly not their SMS messages (unless you happen to be using a SME-PED, but those things are terrible in other ways). Now, Whisper Systems have released two open source programs that allow you to protect your communications. The first is called “RedPhone”. This program encrypts your phone conversations and allows you to converse securely. The second program is called “TextSecure” and encrypts text messages using authenticated, asymmetrical encryption.
I like the way TextSecure manages keys and allows you to verify the user’s key directly so you can establish trust. RedPhone appears to use the trust in the phone number for authentication. RedPhone also provides encryption opportunities when the distant party also has RedPhone on their device which is a nice feature that I wish TextSecure also provided. Both of these programs are very easy to use and need very little configuration.
TextSecure also provides an encrypted container for all your text messages so that your text messages are secure if the attacker has physical access to the device.
And OpenPGP is still a great option for protecting your email communications but that is a topic for later.
Earlier I announced a new PGP key. The decision was made based on my inability to correctly revoke certain uids on my key. I finally figured out my problem and have revoked many of the uids on my key that no longer valid or were no longer being used. So I hope no one wrote off my old key just yet. I’ve had it for a while and I kinda like it. You may want to update it from either my website (see top of the page on this site) or via one of the many keyservers. Sorry for the noise.
I’ve created a new OpenPGP key (0x08CC129D) to replace the one I’ve used for the past few years (0x024BB3D1). Please update your keyrings as necessary.Nope, I’ve decided to keep my old key and just clean it up a bit.
So, if our email providers would provide its users with better ways of authenticating then many of these problems will go away. Multi-factor authentication is an absolute must! Something you know (a password), something you have (a token), and something you are (biometrics) make up multi-factor authentication. When you hear two-factor authentication they are talking about using two of those to authenticate you into the system which makes guessing your password much more difficult.
A good example of a company that gets it would be Paypal. They provide an option to use VeriSign Identity Protection in addition to a username and password. This is an excellent example of two-factor authentication in action. A good example of a company that doesn’t get it would be AOL. They allowed their customers to use RSA SecurID tokens to provide that second authentication factor but recently have decided to stop the use. Apparently they feel that their customers are too stupid to push a button, see a number, and type it into a computer. Bottom line is you should take your business to someone who takes authentication security seriously.
For those who use passwords (and we all do) make sure you use passwords that don’t include words that are in the dictionary, family or friend names, or things that other people could guess. Dictionary attacks against passwords are common because they work! Oh, and your favorite football/baseball/hockey/whatever team’s name is in the dictionary used to crack passwords… trust me. And the longer the password the better. You can exponentially increase the strength of your password by using twelve characters instead of eight, but don’t let that make you stop at twelve characters.
Okay, so we are using strong passwords and we have a token… that’s all I need, right? Not quite. What would you think if I told you that your message can be read at any point along the route to its destination? I’ve always been told that sending an e-mail is like sending a postcard but it’s actually worse. Imagine sending your message on a postcard and then handing it to someone else for delivery. Do you trust that unknown someone who is going to deliver your message? Well, e-mail is exactly the same way. So what can you do? Easy… use encryption!
Oh, I know you don’t think you know anything about encryption and the mathematics that goes along with it but it’s really easy! There are basically two different styles of e-mail encryption: S/MIME and GPG (or PGP). While S/MIME is more hands off, it costs money to get a certificate from a Certificate Authority and then you are basically trusting their trust model taking you out of the trust equation. I’m not impressed. GPG, which is the open source implementation of PGP, is my choice.
I’m not going to get into how to setup GPG because their are lots of instructions already out there. I have helped with documenting how to setup GPG in a number of email programs and even for Gmail, though, and will say it’s in the Fedora wiki.
Anyway, what makes GPG my choice is that not only is it easy to use but it is also completely free. You generate your own keys and can upload your public key to one of the public key servers (like MIT’s key server) which makes your public key available to all. This doesn’t make your encryption vulnerable because this is public-key cryptography and not symmetric cryptography.
So by using GPG (or S/MIME or PGP) you are protecting your message enroute to its destination. So now we have to protect the message now that it has arrived and is being stored on someone else’s server. The great thing is that because you encrypted before transmitting it can only be decrypted by the recipient so it should be left unreadable to anyone cracking into your email account. So if the cracker does get into your mail account then all they will find is scrambled up characters that they won’t be able to understand.
So by using multi-factor authentication and encryption you can remove most risks of using e-mail and keep your information yours. Think you don’t need to protect your information because no one would want to see what you write? Think about the three subjects we started with and remember those are just some of the more recent, public examples. It happens every day.