An Interview with SSL Expert and SSL Labs Founder Ivan Ristić
Even though SSL/TLS is criti cal for the privacy, integrity, and security of internet communications, the protocol is implemented in an optimal way in only a small percentage of web servers, meaning that most websites and web apps aren’t as secure as they could be.
It doesn’t have to be that way, which is why Ivan Ristić, a security researcher, engineer, and author known for his expertise on various aspects of InfoSec, has spent years contributing to the field of SSL/TLS.
He launched SSLLabs.com in 2009 to provide SSL/TLS tools, research and documentation, brought it with him when he joined Qualys in 2010, and ran it until mid-2016, when he became an advisor. Under his leadership, SSLLabs.com became a de-facto standard for secure server assessment and the go-to site for organizations looking for help improving their SSL/TLS configurations.
Ristić also wrote an entire book about the topic titled “Bulletproof SSL and TLS: Understanding and Deploying SSL/TLS and PKI to Secure Servers and Web Applications.” We recently had a chance to catch up with Ivan and pick his brain about SSL/TLS challenges, best practices and trends. Here’s what he told us.
In the intro to your “SSL/TLS Deployment Best Practices” document, you describe SSL/TLS as a “deceptively simple technology” that nonetheless “is not easy to deploy correctly.” What are the main reasons for that?
It’s because it seems easy on the surface, but what you see is usually just the tip of the iceberg. There’s often layers of complexity below, but without any indication that it exists.
Through your efforts over the years, you’ve tried to help fill the gap for SSL/TLS tools and documentation, but are more still needed? If so, what impact does this have on server security in general?
No, we don’t need more documentation. There’s a couple of issues there. First, there is a lot of documentation freely available that’s wrong, incomplete or both. So most people probably won’t find the correct documentation in the sea of documents available online.
Some people may come across my book “Bulletproof SSL and TLS,” which is comprehensive, but — at 550 pages — probably too long. Most people don’t have enough time to spend reading my book so that they are able to deploy secure servers properly.
What we need is to simplify the deployment of SSL/TLS so that things are secure out of the box and that much less knowledge is needed to do the right things.
Some of this is already happening with TLS 1.3, which removes a lot of cruft that accumulated over the years, but there’s still a lot of complexity outside the protocol that we need to address.
But that’s all in the future. Today, reading good documentation and having a complete understanding of your threat model is the only real way to be secure.
We’ve seen recently a great push to embed encryption in the infrastructure and that’s absolutely a good way forward. Today, we have millions of people who host their content elsewhere. Getting their providers to implement encryption properly is much easier than trying to educate everybody. The free certificates from Let’s Encrypt are having an impact by making sure everybody seamlessly gets a valid public certificate.
For someone new to this topic, what would you tell them are the key elements of a strong SSL/TLS implementation?
To an average person, I would say not to worry too much. There’s a few things to get right, and if they do, chances are they will be sufficiently secure even if not everything is perfect. The two key elements to have on every website are a valid certificate and HSTS. Of course, higher-value sites need to do more, but they will also have more time to spend on their security.
Why is it key to also understand PKI and specific aspects of it like its standards, governance, ecosystem weaknesses and potential future improvements?
Internet PKI works for what I call consumer security. There are ways to make it more secure, but, before you do, you need to understand its weaknesses. Once you do and if you realize that you need more security, you can deploy advanced technologies such as public key pinning.
Additionally, one thing we haven’t quite gotten right is certificate revocation. Most enterprises need to understand the dangers lurking behind that.
In your book, you tried to address the questions, concerns and needs of three main audiences: system admins, developers and managers. Why should each of those groups care about SSL/TLS? What are the main challenges each one faces with regards to SSL/TLS, and what responsibilities do they bear?
I think the main challenge is communicating with the other groups! That’s why SSL/TLS is difficult to get right: Each of the groups must do the right things so that the entire whole is secure.
You devote a significant part of the book to HTTP. Why does HTTP merit more attention than other protocols when discussing SSL/TLS?
There are two reasons for that. One is that HTTP is such a rich and powerful protocol. SSL/TLS are protocols designed to protect a single TCP client-server connection, but HTTP and browsers add layers of complexity, with cookies, multiple resources per page, and so on. Wherever there is complexity there is opportunity for security problems.
The second reason is that HTTP is such a popular protocol, which means that there is a huge attack surface. Everyone needs a website these days!
Why do you consider a server’s private key and certificate the fundamental building blocks of a good SSL/TLS implementation?
A secure private key and a publicly trusted certificate are needed today for any website to be able to communicate securely. That’s because encrypted communication begins with authentication. If someone else poses as you, you’ll just spill your secrets to them.
Can you share some best practices for users who want to ensure their SSL/TLS implementation doesn’t affect their website’s or web app’s performance?
If you care about performance — with or without TLS — deploy on a CDN. That will ensure that network latency is minimized. If you pick a good CDN, they will probably get the rest of the optimization right so there won’t be anything left for you to worry about.
If I can single one thing out, it would be keeping HTTP connections open for as long as possible. Servicing many HTTP requests over the same connections means not having to perform new TLS handshakes. That greatly improves the performance.
What is the importance of the SSL/TLS Forward Secrecy feature?
SSL and TLS protocols before TLS 1.3 allow key exchanges that don’t support forward secrecy. Unless proper care is taken when a server is configured, it’s possible to create a bond between the server’s private key and every single connection made to the server.
A powerful adversary who can record encrypted traffic and later recover the key from the server (e.g., by breaking into the server) can decrypt everything. Clearly, that defeats the purpose of encryption.
The good news is that forward secrecy is not very expensive and that (in most cases) only simple server reconfiguration is needed to enable it.
In a recent blog post about an update to SSL Labs’ grading criteria, you attached great importance to the use of AEAD suites and of HSTS, saying both will be required for sites to earn an A+ rating. Why do you consider these features so critical to a solid SSL/TLS implementation?
Of the two, HSTS is the important one. In fact, enabling HSTS on all your properties is the single best thing you can do for your encryption security. That’s because HSTS disables certificate warnings, which are very easy to exploit with a high success rate. Everybody should be using HSTS.
Emphasis on AEAD suites is an incremental improvement that makes sure that we leave behind inherently dangerous CBC suites. We’re fortunate that most TLS libraries have mitigations for the weaknesses, but we still need to migrate to AEAD now before further problems are discovered.