I have been doing a lot of thinking about public key cryptography lately. It is a topic that a lot of people don’t understand, even those with a technical bent.
Every time you connect to a secure site a lot of stuff, there is a lot going on in the background.
Myth 1: As long as things are encrypted, I’m secure.
This one is kind of obvious, but I bring it up to help point out a problem I see all the time. People focus on the encryption part of TLS without realizing that public key crypto does more for you besides encryption. The other major thing that you get with public key crypto is authenticity(verification that you are talking to who you think you are taking to). If you are securely communicating with an attacker, you are not communicating securely.
Myth 2: self signed certificates are insecure.
This one is a bit counterintuitive. There is nothing technically wrong with using self signed certificates, but to be secure you need to do the verification another way. If someone can communicate some information about the certificate to you through another secure channel, then you can be assured of the authenticity the self signed certificate, and then you can install it in your certificate store so that it can remain trusted.
Mostly I blame the browser vendors for this. Firefox does it right, in my opinion. When you go to a site in Firefox, it gives you a warning that the certificate is untrusted, but allows you to add the certificate to Firefox’s trust store and you are never bothered by it again. This is Trust on First Use(TOFU) similar to how most people do key management on SSH. When you go to a site in Chrome or IE, you get the warning every time. You have to know how to manually add the self-signed certificate to your certificate store. Is every self-signed certificate worthy of your trust? No. self-signed certificates put the responsibility on the user to know whether or not they should be trusted.
Myth 3: I’m connecting to a site with a valid certificate. I’m secure right?
There are many things that effect your security, but in the context of TLS, the non-obvious ones that risk your security are:
-The protocol used. SSLv2 for example, it was released by Netscape in 1995. It is not secure. Most modern clients and servers can’t even connect over it, but it is still offered by some web servers. In 1999 the IETF released TLS 1.0, followed by TLS 1.1 in 2006 and TLS 1.2 in 2008. 2008 is quite a few years ago in internet time and yet the browsers have only recently adopted them. TLS 1.x is much better than SSLv3. It was developed out in the open, under peer-review. If you have to support ancient clients like XP, use SSLv3. TLS is the future folks!
-The cipher suite used. One of the really interesting things about public-key crypto is how little it actually encrypts. Many people assume that all of the data that is sent over SSL is encrypted using the public key. In fact 0% of the data is encrypted using public-key crypto. The public/private key pairs are only used for signing, verification and key negotiation. During key negotiation the 2 parties involved attempt to agree on what cipher suites they support. When they find one that matches, they generate a symmetric key to actually encrypt the data. What does that all mean? It means you can have an awesome certificate, but it doesn’t mean anything if an ancient cipher is chosen during negotiation. DES or RC4-40 bit are examples of bad ciphers. Even RC4-128 bit is potentially weak if implemented incorrectly. Triple-DES is strong but slow. AES in Cipher Block Chaining mode is good(No XP support), AES in Galois Counter Mode is even better(No XP support). ChaCha20 is a cipher that is potentially an up-and-comer and is good when AES hardware acceleration is not available.
Myth 4: SSL/TLS is bad for performance.
Most of the people who I hear say this are not going to drive enough traffic to notice the difference. If you are starting to have performance issues, you are probably at the scale where you can afford a CDN or at least an appliance to handle SSL termination for you.
Myth 5: I only need SSL/TLS on the admin page of my website.
You could plausibly run a website securely in this fashion, but you couldn’t use session cookies that left the confines of the admin section of your site. And don’t try to download or upload anything that you care about the integrity of through any other part of your site. It is much easier to just make it all TLS.
Photo Credit: Kris Krüg