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:
- TLS does not provide any “extra” security. That is, TLS does not particularly protect the service or the users against malicious attacks other than eavesdropping or man-in-the-middle.
- TLS does not provide protection against application level vulnerabilities, such as Cross-Site Scripting or SQL-injections.
- TLS does not protect the user (browser) against malicious contents injected on compromised server.
- TLS does not (typically) authenticate the user. It could, but that is rarely used on web services.
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
- Invalid certificates (expired or not-trusted). This makes the web server vulnerable to man-in-the-middle attack, since the browser cannot verify the identity of the web server.
- HTTPS is not enforced. The web service may happily accept plain-HTTP connections, although HTTPS was enabled. Most users just type “www.example.com” to the address bar instead of “https://” at the beginning.
- Unpatched server software. There are known vulnerabilities in common TLS implementations. For example Heartbleed (in OpenSSL).
- Poorly configured servers may allow insecure cipher suites or deprecated SSL/TLS versions. All cipher suites and TLS protocols do not provide sufficient security.
Poorly configured web applications
- Connecting to plain-HTTP API
- Cacheable HTTPS responses
- Session cookies without Secure-flag
- Mixed content (HTTP / HTTPS), loading resources via plain HTTP
Misunderstanding the concept of TLS
- Certificates must be signed by a trusted third-party
- Private keys must be kept private
- HTTPS only verifies origin (domain name), it does not magically make phishing sites legit. Service www.microsoft.foo.com is not a legit Microsoft page, although there could be a valid TLS certificate.
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
- Obtain a valid TLS certificate (Let’s Encrypt provides for free)
- Configure your web server correctly, one good resource for this is Mozilla’s SSL Configuration Generator.
- Implement Strict-Transport-Security and Public-Key Pinning. OWASP
- Consult the Qualys SSL Labs to verify your configuration.
- Keep your software up-to-date or backported. Internet is full of resources providing assistance.
- Implement an automatic status check, that alerts you when the certificate is going to expire, or your configuration is deprecated.
Further information (vulns, attacks, weaknesses)
- DROWN attack: https://drownattack.com/
- Logjam attack: https://weakdh.org/
- FREAK attack: https://freakattack.com/
- RC4 cipher suite deprecated: http://www.rc4nomore.com/
- POODLE vulnearbility: https://www.openssl.org/~bodo/ssl-poodle.pdf
- Heartbleed vulnerability: http://heartbleed.com/
- NSA backdoor in Dual EC: http://blog.cryptographyengineering.com/2013/09/the-many-flaws-of-dualecdrbg.html
- BadSSL - example pages with flawed configuration: https://badssl.com