Must-read for anyone working with one of the Internet’s most important protocols.
I was reading Ivan Ristić’s book
Bulletproof SSL and TLS
when rumours started to appear about an attack against SSL 3.0, which would soon become commonly known as the ‘
POODLE
‘ attack. Thanks to the book, I was quickly able to read up on the differences between SSL 3.0 and its successor, TLS 1.0, which wasn’t vulnerable to the attack. Elsewhere in the book, a few pages are dedicated to protocol downgrade attacks, which were instrumental in a successful POODLE attack.
A few weeks later, when a researcher demonstrated a surprisingly simple hash collision attack on MD5 that showed similarities to the rogue certificate used by
Flame
, I was able to refresh my memory by reading the detailed description of how the Flame authors had been able to generate the certificate.
It’s that kind of book.
SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are designed to provide a secure communication channel over the Internet. They are among the most important Internet protocols, especially in an age when passive and active global adversaries appear to be ubiquitous. But now that, thanks to the recent vulnerability in
Microsoft
‘s Schannel library, all widely used SSL/TLS stacks have suffered from a major vulnerability this year, it is fair to say that SSL/TLS is difficult.
The basic idea behind SSL/TLS is rather simple: client and server exchange a few messages to agree on an encryption protocol and corresponding secret key to use; from then on, all communication between them is encrypted and cannot be read by anyone listening in on the connection.
In practice, as always, things are a bit more complicated. To start with, cryptography is hard. And while you don’t have to know how S-boxes in AES work or what elliptic curve cryptography really is, some basic understanding of cryptography is essential to work with SSL/TLS, and Ristić (whose day job is that of Director of Application Security Research at
Qualys
) is right to start his book with a quick but thorough primer on the subject.
The book then dedicates a mere 40 pages to describing how the SSL/TLS protocol really works – and that includes all the obscure extensions, such as ‘Heartbeat’, about which Ristić writes “it is not clear if Heartbeat is used in practice”. He may well be right, yet hundreds of thousands of servers ran an OpenSSL version that implemented the extension and were thus vulnerable to
Heartbleed
.
Heartbleed aside, things get really interesting in the chapter about public-key infrastructure (PKI): how SSL/TLS deals with the problem that it’s all very well for Anna to communicate securely with Bob, but how does she know she is
really
talking to Bob, and not to Eve, who’s sitting in the middle of their connection, or to Mallory, who has managed to convince Anna that she is, in fact, Bob?
PKI generally works well, except when it doesn’t, and these cases tend to make big headlines and make for interesting reading. A full chapter is dedicated to attacks against PKI: from Sotoriv, Stevens
et al.
using MD5 collision to obtain a rogue
RapidSSL
certificate, to the breaches at
Comodo
and
Diginotar
and the aforementioned Flame malware.
SSL/TLS can be used to secure any TCP-based protocol, but probably its most common use is in HTTPS: secure HTTP connections. Again, the difference between the theory of obtaining a valid certificate and adding it to a web server, and the practice of making sure there is no way a skilled attacker can still read some or all traffic, is huge. Ristić describes a large number of issues faced by both those building browsers and those writing websites, not all of which are trivial to solve.
Did I mention that cryptography is hard? Perhaps it is unsurprising, then, that SSL/TLS implementations have been found to make so many mistakes: from failing to verify certificates to using weak random numbers. In the chapter on implementation issues, Ristić also explains how in 2009, Moxie Marlinspike used inconsistency in how strings are stored to generate a certificate that let him perform a man-in-the-middle attack on any connection.
Chapter 7 deals with protocol attacks, showing that POODLE is only the latest in a long line of attacks that also include ones with more sinister names such as BEAST and CRIME. And of course, there is the fact that many SSL/TLS connections still use RC4, the stream cipher which everyone knows it is broken (the book provides ample of evidence for that), yet no one knows how to break it. It is an important chapter, but I can’t help thinking that if these protocol attacks are your biggest concern, your SSL/TLS implementation is already exceptionally good.
Only after this chapter — and halfway through the book — does Ristić gives advice on how to deploy SSL/TLS: what keys to use, how to select a certificate, what versions of the protocol to support, etcetera. I think this order is the correct choice: making incorrect decisions when implementing SSL/TLS can easily undo most of the benefits gained; hence doing so should always be done with all the possible issues in mind, rather than by checking against a few common issues afterwards.
One often cited reason not to implement SSL/TLS is performance. This may have been valid once, but
Google
— which enabled encryption for
Gmail
by default in 2010 — has said that SSL/TLS is no longer computationally expensive. Of course,
Google
has some of the cleverest engineers in the world and data centres all over the globe, but in a chapter on performance optimization, Ristić gives plenty of useful advice on how one can get performance pretty close to
Google
‘s impressive numbers.
Apart from performing better, there are also ways one can make a website that uses HTTPS more secure for those using it. Use of HSTS and CSP are two such methods that are practical today and the book explains how to set them up, and what things to look out for. Interestingly, it mentions that NTP man-in-the-middle can be used to bypass HSTS — something that I recently saw
presented
at
Black Hat Europe
. Perhaps less practical today, but certainly interesting for the not too distant future, is the pinning of certificates.
The remaining six chapters of the book deal with using SSL/TLS in practice and cover
OpenSSL
,
Apache
,
Java
,
Tomcat
,
Microsoft Windows
,
IIS
and
Nginx
. The book explains how to set up SSL/TLS correctly, of course often referring to the first part of the book, and also how to use the powerful
OpenSSL
suite to test implementations.
I am very excited about this book and I think it is a must-read for anyone using SSL/TLS today, even if they are only using it to make
Apache
serve their website’s checkout system over a secure connection.
The fact that Ristić, while not shying away from technical details, has a pleasant writing style and provides many anecdotes relating to issues and attacks that have occurred in the past, makes it an excellent read for policy makers as well. It will, for instance, help them make an informed decision on whether it’s worth keeping a website available for 0.2% of customers while making the other 99.8% less secure.
The historical anecdotes make it a great reference guide for security journalists and bloggers too, especially since the digital version of the book will be updated regularly to cover significant developments. (The latest version already makes several mentions of POODLE, despite the fat that the attack became public after the initial publication of the book.)
One issue surrounding SSL/TLS may now been solved for good: thanks to POODLE, the only SSL version still actively used (3.0) is quickly being killed off so that we can now unambiguously speak of TLS rather than somewhat clumsily referring to SSL/TLS. To understand all other issues and make sure you implement the protocol correctly, I strongly suggest you read this book.
Bulletproof SSL and TLS is published by
Feisty Duck
and is available as a paperback and in various DRM-free digital formats.
Posted on 17 November 2014 by
Martijn Grooten
Leave a Reply