Understanding TLS

Posted on:May 6, 2016 at 01:30 AM

This is an article I’ve meant to write for last two years. Getting TLS right seems to be a major challenge for many admins. And I do not mean only some random startup company websites, but also large commercial web services and Fortune 500 companies.

The problem is not only poorly configured servers and expired certificates, but in many cases the whole concept of TLS is misunderstood. I try to be here short and clear, and state what TLS is and what TLS is not. Later on, I provide some tips and links to resources that I’ve found useful.

One could write a whole book about TLS and all related stuff around it. I try to make this article clear and easy to understand, still providing the most important points accurately. TLS can be used in many contexts, but in practice we deal with HTTP over TLS (HTTPS) in this article.

Side-note about terms: both abbreviations “TLS” (Transport Layer Security) and “SSL” (Secure Sockets Layer) refer to a protocol family with many different versions. Older (deprecated) versions are called SSL (v1, v2 and v3) while TLS (1.0, 1.1 and 1.2) refers to “next generation” protocol. Term SSL is still common when referring the whole concept.

What TLS provides

Basically TLS provides confidentiality and integrity for data communications between a web server and a web browser. TLS authenticates the server provided that the server has a valid certificate. That is, the browser (and user) should be able to trust that she/he is communicating with a legit service.

This is actually what people assume when they browse the Internet. When accessing a web site, say “google.com”, and the browser displays a seemingly legit page, no one is going to question the legitimacy of the site. No matter if TLS is used or not. Hence, in practice, TLS provides exactly the amount of security and privacy, that 99% of Internet users expect to have by default. That is a good enough reason to provide TLS by default.

What TLS is not

Let’s put this clear and short:

In short, TLS protects the communications, not endpoints. If either an end-user device or a server is compromised, TLS becomes useless.

What could possibly go wrong

Only deploying TLS for web server is not enough to protect the users. There are many things where the administrator or software developer can fail the way that TLS encryption becomes ineffective.

Web server configuration

Poorly configured web applications

Misunderstanding the concept of TLS

Public Key Infrastructure

The security of TLS is based on the public key infrastructure. Basically there are dozens of private companies and organizations around the world that are considered “trusted third parties”. These are called certificate authorities (CAs). [Mozilla CA list]

These CAs have been granted a right to sign any certificate, which makes that particular certificate “trusted” by the browsers. Hence, there are dozens of private companies around the world which are able to generate valid certificates for any website and conduct a man-in-the-middle attack. As a result, if your threat model includes nation-state actors or major tech companies such as Google or Amazon, TLS cannot be considered a solution.

Certificate industry

These private companies with ability to provide TLS certificates, have developed a whole industry around their certificate business. Certificates are charged usually on yearly basis. There are also multiple options available: you may either buy a low-cost certificate with automatic domain validation, or a more expensive alternative (so called “extended validation” certificate), in which case the issuer supposedly makes a manual validation that your company really exists and owns the domain name the certificate was requested and so on.

Usually the certificate providers also mention some technical stuff that their certificate provides. For example, following quote is from Thawte web page:

This domain-only validation SSL Certificate provides up to 256-bit encryption for web-based applications that are not at risk for phishing or fraud.

This is practically marketing bullshit. SSL Certificate itself does not provide encryption - it just verifies the origin. Moreover, all web services are at risk for phishing and fraud. TLS mitigates the risk but does not make any web service immune to it.

Even more bullshit is all the marketing talks about “military-grade encryption” or “bank-level security”. Any web server with a valid HTTPS certificate can provide same “level of encryption” as banks or military. It has nothing to do with the certificate authority, but with the server configuration. Luckily we don’t see “bank-level” jargon so often anymore.

Doman verification

Another thing is, how CAs identify and verify the identity of certificate requests. Typical way is to advice server admin to place some “shared secret” to a certain file available via web server, or by adding some special DNS record with a shared secret. This is considered a “secure enough” way for CAs to confirm that that the certificate request have been sent by a legit source.

The problem is that TLS is exactly as secure, as is the DNS system. If an attacker is able to gain access to victim’s DNS records, or is able to succesfully poison the DNS cache of the relevant server, the attacker is also able to obtain a valid certificate and the corresponding private key for the victim’s service.

Conclusion

I would say that TLS should not be considered safe against highly motivated attacker with virtually unlimited resources. However, if you have been targeted by a nation-state actor, you have already screwed up something. Usually TLS is considered “good enough” against typical online crimininals and hackers. Carefully configured TLS provides level of confidentiality and integrity that banks and major tech companies consider sufficient for their clients.

As of writing this, there is no evidence that any trusted CAs would have systematically violated the rules and signed false certificates. Some cases exist, in which the signing keys of CA had been leaked, allowing criminals to sign valid TLS certificates. However, these signing keys were revoked as soon as the browser vendors learnt about the leak. (TurkTrust, Diginotar)

The crypto is not broken. Math beyond the protocol and (most) algorithms is solid. There have been flaws in protocol design (that’s why we have some many versions of SSL and TLS), as well as in implementation. Upon found, these have been usually fixed promptly.

Tips and resources

Further information (vulns, attacks, weaknesses)