ssl is mostly for the feels

I was discussing the state of the industry the other day with a colleague, and TLS/SSL came up. We both shared the same opinion that the primary function of TLS is to make us feel better about the confidentiality of what we send over the wire. In many ways, TLS is solid and I certainly always recommend using it in network connections; however, it is not the end-all, be-all indication of a “secure” communication.

Essentially, I think of TLS as being PGP for data in transit; the level of confidentiality and assurance is pretty good, but not fail-proof. Here’s why:

false sense of security

Users have been conditioned to look for the green padlock in a URL bar, and have associated this with a “secure” website. While for the majority of everyday users this is still good advice, it lulls users into a false sense of security. Simply because a website uses TLS has litte bearing on how “secure” the site is.

the ca model is broken

TLS relies on trust. At some point in the chain, a user is placing trust in some other entity, and most of the time those entities are companies that most people have never heard of. Here is a quick screenshot from a Windows machine showing all of the root certificate authorities (CA) that the machine trusts:

Do you know who QuoVadis is and do you trust them? Your browser trusts them. What about the Equifax Secure CA? Do you trust them? Has Equifax shown us that they can be trusted with securing their infrastructure? :thinking_face:

If the CA is compromised or goes rogue, all of the downstream certs could also be affected. This is a broken model.

he/she who controls the private key controls the communication

The security practices of many organizations are often called into question. Infrastructures are being infiltrated and data stolen at near breakneck pace. So why would we assume that the security practices protecting the private keys on a server are any better? If the TLS private key is compromised it becomes much easier to MITM a TLS handshake and read all of the Tx/Rx in the clear.

what about the data on the server

TLS protects data in transit. Once you send data to a server, you have no control over how that data is stored, protected, or managed. Just because you sent the data via an encrypted channel doesn’t mean that the receiving party is actually storing it encrypted or protecting it with sound information security practices.

no protection against phishing or bad passwords

Just because comms may use TLS does not absolve one from using strong passwords or being vigilant to social engineering and phshing attempts. If one’s credentials to a particular site are compromised, it makes no difference if the site has a green padlock in the URL bar.

This is a good opportunity to make a recommendation: enable two-factor authentication (2FA) wherever possible.

there’s value in metadata

Typical network communications generate a substantial amount of metadata that is not encrypted in application-layer protocols such as TLS. “What kind of metadata”, you ask? IP addresses, MAC addresses, system information, and more are often transmitted over the network in the clear (ie. not encrypted). By harvesting large amounts of metadata, entities are able to piece together meaningful information about a particular user; just ask the NSA.

This is another reason why it can be beneficial to implement multiple layers of encryption such as a VPN.