Archiv autora: Ivan Ristić

Announcing Bulletproof SSL and TLS, the 2017 revision

I am very happy to announce Bulletproof SSL and TLS, the 2017 revision. The manuscript is complete and it’s now undergoing copyediting. We expect that the revision will be fully done by the end of July. Get your updates now if you can’t want, or in August if you can.

As with all full revisions, this means that we went through the entire book and updated everything that needed updating. My ongoing maintenance is usually focused on specific changes and how they impact the book. For example, when a new research is published I make note of it in the manuscript. Full revisions are different; I reread the entire book to ensure that it still makes sense, as if I were writing the book today.

The bottom line is that, three years on, we again have a fully up-to-date book. Our digital readers have had continuous access to the updates. (As an aside, we have a generous upgrade policy and will give a free digital copy of the book to anyone who purchased a paperback elsewhere; just send us your receipt.)

If you’re interested in my personal perspective on continuous writing and publishing, I published a blog post about it just the other day; go ahead and read it.

With the 2017 revision we’re introducing a new and unique feature, a special online book format that shows all book changes from the first edition until now. We can do this because our manuscript is machine readable (DocBook/XML). As a result, we can compare two manuscript versions to determine the exact differences. We hope that this feature will help you see exactly what changed so that you don’t have to reread the book again.

When you access this output format (you'll need to add the book to your account first) you'll see the table of contents modified to indicate the extent of changes on per chapter basis. The colours under the chapter names indicate the amounts and you can hover over them to see the backing numbers. What I found surprising was that there are many deletions, in some cases as many as the additions! Perhaps more interestingly, several key chapters have seen a turnover between 20% and 33%.

It gets more interesting inside the book. For example, this what the beginning of Chapter 10 looks like:

We hope that you'll be enjoying the updates! From here on we don't expect that we'll be updating the first edition any more. With TLS 1.3 around the corner, the next version of Bulletproof SSL and TLS will include more new content and as deeper changes throughout. So this is a good time to take a break, regroup, and start afresh.

In truth, Bulletproof SSL and TLS would have probably had its second edition already had it not been for TLS 1.3. But, even though we felt that there have been enough improvement, we didn’t feel that we could release another edition now when TLS 1.3 is so close to completion.

Bulletproof SSL and TLS, three years later

The last time I wrote about my book Bulleproof SSL and TLS was two years ago, just after publishing the first full revision. Although two years is a long time to go without a blog post, throughout this period I continued to work on the book, keeping it nearly-always up to date. Today, three years after the first edition had been published, the second formal full revision is complete. At the same time, I am announcing that the first edition won't see any further updates—all future work will go toward the second edition. I will talk more about that in a future blog post.

Please note that updating the printed book without a new edition potentially takes a long time. Online stores have their own inventories and multiple fulfillment centres, all of which may take a long time to clear. Thus, please don't expect that you'll get a printed 2017 revision when you buy the printed book now. In the worst case, you can read the 2015 revision and get the digital 2017 revision (we'll give it to you for free if you send us a receipt)!

Now, I could talk about the changes I made since the last revision, like SLOTH, DROWN, and Sweet32, but you can read about all those things in the book itself. What I want to celebrate is the fact that, three years on, my book is still up to date. This is something I originally set out to do, something I couldn't achieve with traditional publishing, and I am very happy that it's worked. But it hasn't been exactly easy.

When I first start working on a book, I allocate time for it and focus on it completely. Six months is a good amount of time, assuming enough research had been done previously. But not all books are equal. Working on the first edition of Bulletproof, I spent roughly five years on research and two years writing. After the first edition is released, you naturally go on to do other things. So a big challenge for me was to slow down with my other projects and find enough time to properly maintain the book. (In fact, as I write this, I am in the middle of launching my startup, Hardenize.) Although I managed, it was a constant struggle.

Another problem is that, when you're making many small changes over long periods of time, it's difficult to update every single place that needs it. You have to read and reread entire chapters to find all the missed places and fix them. That not only takes time, it's also quite boring.

There are other problems, too, for example the fact that you don't feel as enthusiastic about your work several years later, combined with the fact that the sales are not what they were during the first year.

As an aside, we didn't have any problems with the actual process. Since the beginning we had a fully automated workflow that continuously publishes the manuscript into all necessary formats. Thus, there was nothing to do to put the updates out there. We even have a solution for the proofreading and copyediting parts; our copyeditor, Melinda Ranking, was able to work on the changed parts only.

Back to the challenges, I think that they can all be solved by finding a sustainable business model for producing high-quality technical material. With Bulletproof SSL and TLS we had some good runs that lasted for a while, but they're slowing down. We have some ideas how we can improve the business side of our small publishing company and, generally, the hope is to align our interests with that of our readers. Now that the first edition is at the end of its life, we'll start work on the second edition.

Bulletproof SSL and TLS, three years later

The last time I wrote about my book Bulleproof SSL and TLS was two years ago, just after publishing the first full revision. Although two years is a long time to go without a blog post, throughout this period I continued to work on the book, keeping it nearly-always up to date. Today, three years after the first edition had been published, the second formal full revision is complete. At the same time, I am announcing that the first edition won't see any further updates—all future work will go toward the second edition. I will talk more about that in a future blog post.

Now, I could talk about the changes I made since the last revision, like SLOTH, DROWN, and Sweet32, but you can read about all those things in the book itself. What I want to celebrate is the fact that, three years on, my book is still up to date. This is something I originally set out to do, something I couldn't achieve with traditional publishing, and I am very happy that it's worked. But it hasn't been exactly easy.

When I first start working on a book, I allocate time for it and focus on it completely. Six months is a good amount of time, assuming enough research had been done previously. But not all books are equal. Working on the first edition of Bulletproof, I spent roughly five years on research and two years writing. After the first edition is released, you naturally go on to do other things. So a big challenge for me was to slow down with my other projects and find enough time to properly maintain the book. (In fact, as I write this, I am in the middle of launching my startup, Hardenize.) Although I managed, it was a constant struggle.

Another problem is that, when you're making many small changes over long periods of time, it's difficult to update very single place that needs it. You have to read and reread entire chapters to find all the missed places and fix them. That not only takes time, it's also quite boring.

There are other problems, too, for example the fact that you don't feel as enthusiastic about your work several years later, combined with the fact that the sales are not what they were during the first year.

As an aside, we didn't have any problems with the actual process. Since the beginning we had a fully automated workflow that continuously publishes the manuscript into all necessary formats. Thus, there was nothing to do to put the updates out there. We even have a solution for the proofreading and copyediting parts; our copyeditor, Melinda Ranking, was able to work on the changed parts only.

Back to the challenges, I think all they can all be solved by finding a sustainable business model for producing high-quality technical material. With Bulletproof SSL and TLS we had some good runs that lasted for a while, but they're slowing down. We have some ideas how we can improve the business side of our small publishing company and, generally, the hope is to align our interests with that of our readers. Now that the first edition is at the end of its life, we'll start afresh with the second edition.

SSL Labs Grading Redesign (Preview 1)

We’re excited to share with you the first preview of our next-generation grading. This is something that’s long overdue but, due to lack of available time, we managed to keep up patching the first-generation grading to keep up with the times. Now, finally, we’re taking the next necessary steps to modernise how we grade servers based on our assessments.

Grading Redesign Goals

Before I show you the new version of the grading, I’d like to explain what we’re set out to achieve:

  • Cleanup. SSL Labs grading was initially designed around numerical scores in various categories. That approached worked for a period of time, back in the day when most cryptographic elements appeared to be relatively secure. This system is still employed at the core, but it’s now largely obsolete and complicates the work.
  • Simplification and assessment decoupling. Our new goal is make it easier to understand how grading is done and, perhaps more importantly, enable others to replicate our results. In other words, we wish to decouple the grading logic from our assessment implementation.
  • Meaningful grades. Although the A-F grading we have in place works great, we’re not making full use of the entire grade range. Additionally, the grades don’t have defined meanings, making it more difficult to keep the grading approach consistent over a period of time.
  • Even better security. Finally, we wish the next major update to further push security forward by requiring better security. This is something we’ve been doing regularly over the years, and this time is not going to be an exception.

Preview 1 Reveal

Without further ado, we’re releasing Preview 1 as a public Google Document with commenting enabled:

The focus on this release is on the grading algorithm concept (i.e., the way how rules are defined, specified, and processed). Although the rules themselves resemble what will actually be the next-generation criteria, they haven’t been fully tuned. In fact, our next step will be to specify the grading storage formats and build a proof-of-concept tool to compare the current grades and the future version. We intend to use this tool to refine the grades over the following months.

If it’s the criteria only that you’re interested in, please refer to my earlier blog post on this topic.

Introducing Hardenize dashboards

Today we’re introducing a great new Hardenize feature—public dashboards. They are a great way to apply Hardenize’s complete assessment capabilities to a group of hosts and get a good understanding (quickly!) of what their security is like. We provide a summary page that shows the most important data points, but we also include the complete results for each of the participating sites individually.

We’re launching with two dashboards. The first—Global Top Sites—is maintained by us and is designed to reflect the security of the most important hosts globally. We will draw from several sources that rank web sites to build our own list of about one thousand most popular names.

The other dashboard—Sweden’s Top Sites—is far more interesting because it’s official; it’s maintained by Sweden’s domain name registry, The Internet Foundation in Sweden (iiS). We are very happy to be working with the iiS and Anne-Marie Eklund Löwinder, their CISO, to maintain this dashboard.

We like security dashboards for several reasons, the main one being that they’re easy to understand and you don’t even have to be a security professional. In other words, they visualise security and make it accessible to everyone. The other aspect of the same coin is that the transparency helps us all do better. Let’s face it, the security of an important web site is not only their problem, it’s also a problem for their users, and very often for an entire country or even the world as a whole.

To that end, we’re thrilled to announce that we will make our public dashboards free to selected organisations that are working to make Internet a safer place, for example domain name registries and government agencies in charge of security of national web sites. If you represent one of these, please get in touch. We’d love to hear from you!

Finally, please be aware that, like Hardenize itself, our dashboards are a work in progress. Over the following months we will further polish them, clarify and document our criteria, and add some additional features.

SSL Labs Distrusts WoSign and StartCom certificates

In the second half of 2016, a series of events unfolded that culminated with something many didn’t think was possible (or at least thought very unlikely): a public CA was distrusted. The CA in question was WoSign, a Chinese CA who made some waves by offering free certificates back in the day, before Let’s Encrypt came onto the scene. To make the case even more remarkable, another CA—StartCom—was distrusted at the same time. These were CAs with substantial installed user bases, largely because both had offered free certificates.

To fully understand what happened requires a lot of digging for background information. Luckily, the blog posts from Mozilla and Google not only give their reasons, but provide helpful links where you can obtain further information if you desire. Apple also joined in the ban; Microsoft did not yet make any announcements.

In short, the root cause for the bans was the fact that the browser vendors have lost trust in WoSign’s “technical and management capabilities”. In addition, WoSign has been accused of dishonesty and continued and persistent deception. To a large extent, StartCom didn’t feature in the story as a significant role, but their fate was sealed because they had been acquired by WoSign and later became part of the same management and technical hierarchy. They now seem to effectively be two brands within the same organisation.

The decisions to ban WoSign and StartCom were made largely in October 2016, but the actual trust changes started to take place in January 2017. Browser vendors generally attempted to keep all existing certificates alive, which is potentially challenges given that one of the accusations leveled at WoSign was certificate backdating. (In absence of a widespread deployment of a public log mechanism for certificates, for example Certificate Transparency, there is no way to verify a certificates’ not-before and not-after dates.) However, this is not something that can be done reliably, which is why many web sites with WoSign’s and StartCom’s certificates started to experience disruption. Furthermore, all vendors are committed to taking whatever actions in the future they feel necessary, including completely revoking trust in the doomed CAs. Mozilla said that they could do that as early as April 2017.

In the nutshell, if you have a WoSign and StartCom certificate in production today, there is no guarantee that it will work for your users. In the future, it will get only worse, and it will not get better until you replace your certificate and use another CA. To that end, SSL Labs will actively distrust WoSign and StartCom certificates in the near future. Within the next couple of days our development and production systems will start showing a warning when WoSign or StartCom certificates are encountered. From 8 May 2017 such certificates will be graded with a T (no trust). Web sites that continue to use them will receive a T grade. We hope that we can raise further awareness with this action and help site operations transition as smoothly as possible.

CAA Mandated by CA/Browser Forum

Certification Authority Authorization (CAA), specified in RFC 6844 in 2013, is a proposal to improve the strength of the PKI ecosystem with a new control to restrict which CAs can issue certificates for a particular domain name. Although CAA had been in the proposed-standard state for more than 4 years, there was little obvious happening until very recently, with only a hundred or two hundred sites adopting it. But that’s going to change, because the CA/Browser Forum recently voted to mandate CAA support as part of its certificate issuance standard Baseline Requirements. The changes will become effective in September 2017.


The fact that any CA can issue a certificate for any domain name is commonly cited as the weakest aspect of the PKI ecosystem. Although CAs want to do the right thing, there are no technical controls that prevent them from doing whatever they chose to do. That’s why we say that the PKI ecosystem is a weak as the weakest link. With hundreds of CAs, there are potentially many weak links.

CAA creates a DNS mechanism that enables domain name owners to whitelist CAs that are allowed to issue certificates for their hostnames. It operates via a new DNS resource record (RR) called CAA (type 257). Owners can restrict certificate issuance by specifying zero or more CAs; if a CA is allowed to issue a certificate, their own hostname will be in the DNS record. For example, this is what someone’s CAA configuration could be (in the zone file):

example.org. CAA 128 issue "letsencrypt.org"

And that’s all there is to it. Before issuing a certificate, CAs are expected to check the DNS record and refuse issuance unless they find themselves on the whitelist. In addition to the “issue” directive from the example, two other directives are supported: “issuewild” that restricts issuance of wildcard certificates, and “iodef”, which provides support for notification in the cases something goes wrong. (In case you’re wondering, the number “128” is a flags byte with its highest bit set, meaning the directive use is considered critical and must be followed.)

At a high level, CAA has similar purpose to public key pinning (HPKP), but the implementation is entirely different. First, CAA prevents certificate issuance whereas HPKP is a run-time client-side control that prevents already-issued certificates from being seen as valid. In other words, CAA is for CAs, HPKP is for browsers. HPKP, which works by whitelisting public keys, is a strong technical control; in contrast CAA is largely an administrative control. While it’s expected that CAs will automatically check CAA before issuing certificates, what happens next is somewhat vague—they switch to manual processing and may end up issuing the certificate if they believe that the request is genuine. The main weakness of CAA compared to HPKP is that there are many CAs and that they all need to implement the checks correctly, as well as resist social engineering attacks when CAA is violated.

But this is not to say that CAA is useless, or inferior to HPKP. That’s because of the advantages, the main being that, unlike HPKP, which is potentially very dangerous, it’s not possible to abuse CAA and bring down a web property. Whereas HPKP can kill your business if you mess up, CAA will merely annoy you. In the end, one way to look at CAA is “public key pinning for normal web properties”, who would find HPKP to complicated and scary to use.

In case you’re wondering, SSL Labs already supports checking for CAA. You can see it in the report for google.com, for example. (It’s in the top section, along with the information on the key and first certificate.)

Ticketbleed detection added to SSL Labs

Ticketbleed is a recently disclosed vulnerability in some F5 load balancers. This problems allows attackers to retrieve up to 31 bytes of process memory, which could potentially include sensitive data (for example private keys). It is similar in nature to Heartbleed (a vulnerability in OpenSSL from 2014), but less severe because much less data can be extracted.

Update (7 April 2017): Ticketbleed detection is now available on SSL Labs production servers.

At the core, the vulnerability is simple. When session tickets are used, clients are expected to submit a session ID to the server when they present their ticket. In this particular use cases, clients decide on the session ID and are allowed to submit an arbitrary string containing from one to 32 bytes. At the same time, F5 devices had a software bug that always responded with 32 bytes of data, even if fewer bytes were submitted by the client. Thus, if a client submits only one byte as the session ticket ID, it will get back 31 bytes of uninitialised memory from the server.

More technical information about Ticketbleed is available from the web pages published Filippo Valsorda, who discovered the problem, reported it to F5, and coordinated the disclosure.

SSL Labs will add Ticketbleed detection in the next release, scheduled to be deployed tomorrow soon. We will update this blog post afterwards. Because this is a vulnerability, we will fail servers that are discovered with the problem.

What’s new in SSL Labs 1.26.5

Today saw another SSL Labs release, which brings several new features and includes one fix. In this blog post I will discuss what the new features are and why they’re interesting. As always, you’ll find the (recent) history of SSL Labs releases in the change log.

Improved cipher suite testing: faster and better!

The cipher suite testing has been optimised to produce better results faster—the best of both world. We’ve written about this before so you can find the details in this blog post. In a nutshell, cipher suites are now reported on per-protocol basis, and even with SNI disabled. This thorough approach gives a complete view of server’s configuration.

Detection of CAA policies

Certification Authority Authorization (CAA), defined in RFC 6844, is a new standard that allows domain name owners to control which CAs are allowed to issue certificates for their properties. SSL Labs now detects when CAA is defined on a hostname.

Detection of ECDHE server parameter reuse

During the ephemeral Diffie-Hellman key exchange—both the standard (DHE) and elliptic curve (ECDHE) variants— client and server are expected to both generate one-time (hence the word ephemeral) secrets that are used in the process. Because secret generation takes some time, some servers reuse secrets. In the worst case, the reuse is indefinite (in practice until process restart); in some cases, there’s a time limit.

This type of flaw first came into the spotlight with Logjam because it made attacks much easier (and, in fact, possible). Further, a recent paper titled Measuring the Security Harm of TLS Crypto Shortcuts indicates a widespread reuse of DHE and ECDHE parameters. Reuse of ECDHE server parameters is not as dangerous (or immediately exploitable), but it’s still a problem. SSL Labs has long had detection for reused DHE server parameters; this version adds the same test for ECDHE.

Detection of supported named curves and preferences

Until recently, most servers supported a limited set of named curves for the ECDHE key exchange, because only secp256r1 and secp384r1 were useful in practice; browsers didn’t support much else. Since RFC 7748 added support for two new modern curves, x25519 and x448, we are seeing more and more servers adding support for them. Thus, it makes sense to have a separate test that inspects all supported named curves and the order in which they are negotiated.

Continued improvements to the next-gen API (v3)

As SSL Labs continues to evolve, we continue to extend the API. The approach we’re taking is to keep version 2 of the API stable, but to improve (wit breaking changes) version 3. In this SSL Labs release, API v3 simulation fields have been extended to carry additional information about the negotiated key exchange and the server’s certificate. (Earlier changes were adding support for multiple certificates as well as a full dump of all observed HTTP transactions.) You can find the complete API v3 documentation.

Client Test added support for GREASE suites

TLS, one of the most widely encryption protocols and certainly the most diverse one, has had a long-standing problem with intolerance problems of one sort or another. The basic issue is that servers are written to expect a certain type of traffic and panic if they see anything they consider to be unusual.

In the end, the community decided that intolerance problems can’t be prevented, but they need to be dealt with early on. The key to doing that is detection. To that end, David Benjamin proposed GREASE, that a standard way for TLS clients to continuously offer unusual protocol elements, effectively forcing the broken serves to be fixed. The SSL Labs Client Test now detects GREASE elements for what they are.

Client Test added support for TLS 1.3 suites

TLS 1.3, which is almost around the corner, introduces new cipher suites. Don’t worry, the number of suites is not going to continue to increase. TLS 1.3 deprecated all earlier cipher suites, and introduces only 5 new ones. The SSL Labs Client Test now detects the TLS 1.3 suites correctly.

Per-protocol cipher suite detection in SSL Labs

Just a couple of days ago SSL Labs started showing multiple certificates when they are configured for the same host, and we now have another useful feature lined up—per protocol cipher suite testing. When I started working on SSL Labs in 2009, everyone had the same cipher suite configuration, no matter what protocol version was used. In the years that followed we had various security issues in earlier protocol versions, and the ability to configure per-protocol cipher suites slowly started to find its way into libraries. Today, different suites for different protocols is still not very common, but not rare any more.

Now, it seems like a small thing to test supported cipher suites for each protocol separately, but it actually required a lot of work. The first problem was that cipher suite testing was the slowest part of the assessment. That’s because SSL Labs used to use one connection to test support for one suite. If you suddenly multiply that by two or three, the assessment time explodes. There’s a good historical method why this approach was used, by the way. Back in the day, there were lots of F5 devices that wouldn’t tolerate TLS handshakes with a large number of suites. So, to avoid interoperability problems, the easiest solution was to check one suite at the time.

When the time came to switch to per-protocol suite testing, we decided to completely overhaul cipher suite detection to speed it up. Luckily, in the meantime one of the F5 engineers provided a workaround for their interoperability problem; we even have RFC 7685 for it. To cut the long story short, the new testing method in SSL Labs is both faster and provides better suite detection. Refactoring at its best.

Our work is not yet done, however. There is another aspect of cipher suite testing, and that’s support for Server Name Indication (SNI). SNI is a special feature of TLS that allows multiple secure sites to exist on the same IP address. Another thing that has become common is that sites configure cipher suite support on per-site (not server) basis. In this case, clients that don’t support SNI and thus can’t specify the desired site name (e.g., Windows XP and some very old Android devices), get server suites not site suites.

The new cipher suite detection implementation is now running on the SSL Labs staging server. Once ready, we’ll migrate it to production.