Blog: Ivan Ristić2024-03-19T07:30:03+00:00http://blog.ivanristic.com/Ivan Ristićhttp://blog.ivanristic.com/2022/02/bulletproof-tls-and-pki-is-outBulletproof TLS and PKI, Second Edition is out2022-02-16T00:00:00+00:002022-02-16T00:00:00+00:00Ivan Ristić<a href="https://www.feistyduck.com/books/bulletproof-tls-and-pki/"><img
src="/images/bulletproof2-cover-w1125.jpg" width="300" align="right"
style="border: 1px solid grey; margin-left: 20px"></a>
<p>It took a couple of years, but I am happy to report that my book <a
href="https://www.feistyduck.com/books/bulletproof-tls-and-pki/">Bulletproof TLS and PKI is now out</a> and available in both digital and print. Although the title is slightly different this time, the new release is the second edition of my earlier work—Bulletproof SSL and TLS—which came out in 2014. The second edition has less SSL and more TLS, as it should be.</p>
<p>When I started writing this book in 2010, I not only wanted to produce a comprehensive and practical resource for anyone looking to successfully use TLS and PKI in production, but also aimed to keep the material up to date over the years. I’ve now spent more than a decade either writing or updating my book, and I am happy that I’ve achieved my dream of continuous writing and publishing.</p>
<p>It took a lot of work. First, there’s the writing. Updating the manuscript continuously takes more time, because you have to constantly write and then rewrite and rewrite again. This is especially challenging in the security space, where things change fairly quickly. Then, there’s the publishing. With no publishers out there interested in pursuing continuous publishing, we also had to take book production onto ourselves. That consisted of doing the traditional parts of the process, but also the continuous automated workflow, which was necessary to support frequent updates.</p>
<p>Although I am very happy with the result, some parts of the journey were quite challenging. Once we had the automation in place, making changes became easy. To release a new version all I needed to do was make the changes to the manuscript. With printing on demand, we didn’t have to worry about inventory, which enabled us to update the book “in place” (updated the print PDFs without making a new edition) several times, including one comprehensive revision in 2017.</p>
<p>The release of TLS 1.3 in 2018 made it impossible to continue to update the book incrementally. First, there was a new standard to cover. Then, we had to wait for the ecosystem to catch up and new versions of libraries and software to be released. Then they needed to mature. A completely new edition was needed. That edition should have come out in 2020, but my commitments at Hardenize slowed things down and added about a year to the schedule.</p>
<p>My favourite part of writing a release blog post is showing exactly what changed since the previous version. We can do this because our manuscript is based on DocBook XML. That enables us to compare one XML version from the past with the most recent XML document and highlight the differences. For this we use a tool called <a href="https://www.deltaxml.com/products/compare/docbook-compare/">DocBook Compare</a>, from a company called <a href="https://www.deltaxml.com">DeltaXML</a>.</p>
<p>The end result is an HTML version of the book, which we actually make available to all our readers. The table of contents shows the book chapters, with a special diff bar under each name. We use grey to indicate no changes, green for new content, and red for deleted content. Inside each chapter we show the exact changes. For our readers, this is not only interesting, but useful. If you’re coming from the first edition, you can now see exactly what changed in the second release.</p>
<image src="/images/20220216-b2ed-diff-chapters.png" style="border: 1px solid grey" width="600px">
<p>I wrote about our tooling when the 2017 revision came out and it’s perhaps interesting to compare that diff to the current one. The first obvious difference is that there are two new chapters, represented with an all-green diff bar. There are also three largely stable changes, whose diff bar is mostly grey. The remaining seven chapters are mostly a combination of green and red, which indicates heavy rewriting.</p>
<image src="/images/20220216-b2ed-diff-content.png" style="border: 1px solid grey" width="600px">
<p>I hope you've found this story about what happens behind the scenes interesting. Until next time.</p>
http://blog.ivanristic.com/2021/02/openssl-cookbook-3ed-now-availableOpenSSL Cookbook 3rd Edition now available2021-02-01T00:00:00+00:002021-02-01T00:00:00+00:00Ivan Ristić<a href="https://www.feistyduck.com/books/openssl-cookbook/"><img
src="https://www.feistyduck.com/library/openssl-cookbook/assets/image-main-view.png" width="250" xheight="250" align="right"
style="border: 1px solid grey; margin-left: 20px"></a>
<p>Another year, another book to update. The third edition of <a href="https://www.feistyduck.com/books/openssl-cookbook/">OpenSSL Cookbook</a>, my free book that covers command-line usage of OpenSSL, is now available for your pleasure. Although the structure of the book remains the same, it’s been significantly updated with the help of Matt Caswell, a member of the OpenSSL development team. The largest change, of course, is that the material is now fully up to date with TLS 1.3.</p>
<p>There are two chapters in the book. The first chapter covers installation and configuration, key and certificate management. It also provides instructions and templates for how to build your own private CA. The second chapter, on the other hand, focuses on testing configuration of TLS servers.</p>
<p>Enjoy!</p>
http://blog.ivanristic.com/2020/11/bulletproof-ssl-and-tls-second-edition-previewSecond edition of Bulletproof SSL and TLS now in preview2020-11-01T00:00:00+00:002020-11-01T00:00:00+00:00Ivan Ristić<a href="https://www.feistyduck.com/books/bulletproof-ssl-and-tls/"><img
src="/images/bulletproof2-cover-w1125.jpg" width="300" xheight="250" align="right"
style="border: 1px solid grey; margin-left: 20px"></a>
<p>I am happy to announce that <a href="https://www.feistyduck.com/books/bulletproof-ssl-and-tls/">the second edition of Bulletproof SSL and TLS is now available in preview</a>. As I write this, it’s November 2020 and roughly six years since we released the first edition. I am happy to say that things have worked out approximately how I thought they would. The first edition came out in 2014, but immediately in 2015 we released another version to keep up with the developments, and then a full revision followed in 2017. In 2018, the long-awaited TLS 1.3 protocol came out, making a big impact on the ecosystem. As a result, I started to plan the second edition, which needed to be a major rewrite. The trick was to begin writing when the support for this new protocol is stable across a range of technologies, so that the book is not obsolete the moment it comes out. And here we are.</p>
<p>At this point, the key parts of the book have been written or rewritten. There is obviously one entirely new chapter to cover TLS 1.3. The two OpenSSL chapters have seen so many changes that little text remains unchanged. (This is largely because Matt Caswell, a member of the core OpenSSL team, joined me as technical reviewer. His insights have
spurred me to write more than planned.) I have also replaced the deployment chapter from the first edition with a brand new configuration chapter that is better structured and touches on everything you need to know to setup everything just right.</p>
<p>Some things have been removed. The chapters dealing with the Apache web server, Java, Microsoft technologies, and Nginx are now gone. When I originally started to write this book, I thought I would write about 250 pages, but the end result was closer to 600. On the one hand, there are so many details to convey, but, on the other, no one wants to read a big book. The new edition had to increase the amount of pages further, but I took a decision to remove some parts that I felt were not fully connected to the main body of content.</p>
<p>Although there still remain several chapters to go through, I feel that the remaining changes will fall in the supporting category. The bulk of the material is already here and ready for you to enjoy. I continue with the remaining work and will publish the second edition when it’s ready.</p>
http://blog.ivanristic.com/2017/07/announcing-bulletproof-ssl-and-tls-2017-revisionAnnouncing Bulletproof SSL and TLS, the 2017 revision2017-07-11T00:00:00+01:002017-07-11T00:00:00+01:00Ivan Ristić<p>I am very happy to announce <a href="https://www.feistyduck.com/books/bulletproof-ssl-and-tls/">Bulletproof SSL and TLS, the 2017 revision</a>. 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 wait, or in August if you can.</p>
<p>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.</p>
<p>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 <a href="https://feistyduck.myshopify.com/products/bulletproof-ssl-and-tls-digital-upgrade">send us your receipt</a>.)</p>
<p>If you’re interested in my personal perspective on continuous writing and publishing, I published <a href="/2017/07/bulletproof-ssl-and-tls-three-years-later.html">a blog post about it just the other day</a>; go ahead and read it.</p>
<p>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.</p>
<p>When you access this output format 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%.</p>
<image src="/bulletproof-diff-homepage.png" style="border: 1px solid grey" width="600px">
<p>It gets more interesting inside the book. For example, this what the beginning of Chapter 10 looks like:</p>
<image src="/bulletproof_diff_sample_ch10.png" style="border: 1px solid grey" width="600px">
<p>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.</p>
<p>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 was enough improvement to warrant a new edition, we didn’t feel that we could release one now when TLS 1.3 is so close to completion. Of course, it's another problem that TLS 1.3 has been "almost done" for a long time now!</p>
http://blog.ivanristic.com/2017/07/bulletproof-ssl-and-tls-three-years-laterBulletproof SSL and TLS, three years later2017-07-04T00:00:00+01:002017-07-04T00:00:00+01:00Ivan Ristić<p>The <a href="/2015/08/bulletproof-maintenance.html">last time I wrote about my book</a> <i>Bulleproof SSL and TLS</i> 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.</p>
<p><i>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.</i> 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)!<p>
<p>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.</p>
<p>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. (<i>In fact, as I write this, I am in the middle of launching my startup, <a href="https://www.hardenize.com">Hardenize</a>.</i>) Although I managed, it was a constant struggle.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
http://blog.ivanristic.com/2017/06/ssl-labs-grading-redesign-preview-1SSL Labs Grading Redesign (Preview 1)2017-06-30T00:00:00+01:002017-06-30T00:00:00+01:00Ivan Ristić<p>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.</p>
<p><span id="more-23939"></span></p>
<h3>Grading Redesign Goals</h3>
<p>Before I show you the new version of the grading, I’d like to explain what we’re set out to achieve:</p>
<ul>
<li><b>Cleanup.</b> 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.</li>
<li><b>Simplification and assessment decoupling.</b> 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.</li>
<li><b>Meaningful grades.</b> 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.</li>
<li><b>Even better security.</b> 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.</li>
</ul>
<h3>Preview 1 Reveal</h3>
<p>Without further ado, we’re releasing Preview 1 as a public Google Document with commenting enabled:</p>
<ul>
<li><strong><a href="https://docs.google.com/document/d/13o_iRZ5-Lv8VTDULUmpUu0XgHWCXDUbYia1vPagMBKE/edit?usp=sharing">SSL Labs Grading: Version Two Preview 1</a></strong></li>
</ul>
<p>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.</p>
<p>If it’s the criteria only that you’re interested in, please refer to my <a href="https://blog.qualys.com/ssllabs/2016/11/16/announcing-ssl-labs-grading-changes-for-2017">earlier blog post on this topic</a>.</p>
http://blog.ivanristic.com/2017/04/ssl-labs-distrusts-wosign-and-startcom-certificatesSSL Labs Distrusts WoSign and StartCom certificates2017-04-05T00:00:00+01:002017-04-05T00:00:00+01:00Ivan Ristić<p>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.</p>
<p><span id="more-23722"></span></p>
<p>To fully understand what happened requires a lot of digging for background information. Luckily, the <a href="https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates">blog posts from Mozilla</a> and <a href="https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html">Google</a> 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.</p>
<p>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.</p>
<p>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.</p>
<p>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. <strong>From 8 May 2017 such certificates will be graded with a T (no trust).</strong> 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.</p>
http://blog.ivanristic.com/2017/03/caa-mandated-by-cab-forumCAA Mandated by CA/Browser Forum2017-03-13T00:00:00+00:002017-03-13T00:00:00+00:00Ivan Ristić<p>Certification Authority Authorization (CAA), specified in <a href="https://tools.ietf.org/html/rfc6844">RFC 6844</a> 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 <a href="https://cabforum.org/pipermail/public/2017-March/009988.html">voted to mandate CAA support</a> as part of its certificate issuance standard <a href="https://cabforum.org/baseline-requirements-documents/">Baseline Requirements</a>. The <a href="https://cabforum.org/pipermail/public/2017-March/009917.html">changes will become effective in September 2017</a>.</p>
<p><span id="more-23648"></span><br />
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.</p>
<p>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):</p>
<pre>example.org. CAA 128 issue "letsencrypt.org"</pre>
<p>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.)</p>
<p>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.</p>
<p>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.</p>
<p>In case you’re wondering, SSL Labs already supports checking for CAA. You can see it in the <a href="https://www.ssllabs.com/ssltest/analyze.html?d=google.com">report for google.com</a>, for example. (It’s in the top section, along with the information on the key and first certificate.)</p>
http://blog.ivanristic.com/2017/02/ticketbleed-detection-added-to-ssl-labsTicketbleed detection added to SSL Labs2017-02-23T00:00:00+00:002017-02-23T00:00:00+00:00Ivan Ristić<p>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.</p>
<p><span id="more-23593"></span></p>
<p><b>Update (7 April 2017):</b> Ticketbleed detection is now available on <a href="https://www.ssllabs.com">SSL Labs production servers</a>.</p>
<p>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.</p>
<p>More technical information about Ticketbleed is available from the <a href="https://blog.filippo.io/finding-ticketbleed/">web</a> <a href="https://filippo.io/Ticketbleed/">pages</a> published Filippo Valsorda, who discovered the problem, reported it to F5, and coordinated the disclosure.</p>
<p>SSL Labs will add Ticketbleed detection in the next release, scheduled to be deployed <s>tomorrow</s> soon. We will update this blog post afterwards. Because this is a vulnerability, we will fail servers that are discovered with the problem.</p>
http://blog.ivanristic.com/2017/01/new-in-ssl-labs-1.26.5What’s new in SSL Labs 1.26.52017-01-13T00:00:00+00:002017-01-13T00:00:00+00:00Ivan Ristić<p>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 <a href="https://community.qualys.com/docs/DOC-5737">change log</a>.</p>
<p><span id="more-23483"></span></p>
<h3>Improved cipher suite testing: faster and better!</h3>
<p>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 <a href="https://blog.qualys.com/ssllabs/2016/08/31/improved-suite-detection-in-the-next-ssl-labs-update">this blog post</a>. 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.</p>
<h3>Detection of CAA policies</h3>
<p>Certification Authority Authorization (CAA), defined in <a href="https://tools.ietf.org/html/rfc6844">RFC 6844</a>, 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.</p>
<h3>Detection of ECDHE server parameter reuse</h3>
<p>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.</p>
<p>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 <em><a href="http://dl.acm.org/citation.cfm?id=2987480">Measuring the Security Harm of TLS Crypto Shortcuts</a></em> 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.</p>
<h3>Detection of supported named curves and preferences</h3>
<p>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 <a href="https://tools.ietf.org/html/rfc7748">RFC 7748</a> 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.</p>
<h3>Continued improvements to the next-gen API (v3)</h3>
<p>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 <a href="https://github.com/ssllabs/ssllabs-scan/blob/master/ssllabs-api-docs-v3.md">complete API v3 documentation</a>.</p>
<h3>Client Test added support for GREASE suites</h3>
<p>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.</p>
<p>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 <a href="https://blog.qualys.com/ssllabs/2016/08/02/tls-version-intolerance-in-ssl-pulse">GREASE</a>, 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.</p>
<h3>Client Test added support for TLS 1.3 suites</h3>
<p>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.</p>