Blog: Ivan Ristić / SSL

Bulletproof TLS and PKI, Second Edition is out

2022-02-16T00:00:00+00:00

It took a couple of years, but I am happy to report that my book Bulletproof TLS and PKI is now out 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.

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.

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.

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.

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.

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 DocBook Compare, from a company called DeltaXML.

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.

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.

I hope you've found this story about what happens behind the scenes interesting. Until next time.

OpenSSL Cookbook 3rd Edition now available

2021-02-01T00:00:00+00:00

Another year, another book to update. The third edition of OpenSSL Cookbook, 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.

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.

Enjoy!

Second edition of Bulletproof SSL and TLS now in preview

2020-11-01T00:00:00+00:00

I am happy to announce that the second edition of Bulletproof SSL and TLS is now available in preview. 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.

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.

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.

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.

Announcing Bulletproof SSL and TLS, the 2017 revision

2017-07-11T00:00:00+01:00

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 wait, 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 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 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!

Bulletproof SSL and TLS, three years later

2017-07-04T00:00:00+01:00

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.

SSL Labs Grading Redesign (Preview 1)

2017-06-30T00:00:00+01:00

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:

SSL Labs Grading: Version Two Preview 1

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.

SSL Labs Distrusts WoSign and StartCom certificates

2017-04-05T00:00:00+01:00

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

2017-03-13T00:00:00+00:00

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

2017-02-23T00:00:00+00:00

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

2017-01-13T00:00:00+00:00

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

2016-11-29T00:00:00+00:00

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.

SSL Labs now showing multiple certificate chains

2016-11-22T00:00:00+00:00

When we designed the SSL Labs report originally, we allowed room for only one certificate per server. Even though it was technically possible to support multiple certificates for a single host, only a small number of web servers supported it and nobody was actually doing it. Why would they… RSA worked well and cryptography wasn’t as important as it is today.

But, over the years, people started deploying RSA and ECDSA certificates in parallel. These days, many web servers support this option and it’s not at all uncommon to find such web sites. Now, SSL Labs has always been collecting all observed certificates, but they were not shown in the report. When we started to work on the v3 API, we made changes to expose all the certificates. Now, finally (as of 1.25.2), they appear in the main report as well.

To accommodate the additional certificates we made to make some changes to the page design. SSL Labs report was very long even before this change and adding more certificates would mean much more data. So, in an attempt to show less, we’ve taken a decision to hide certificate trust paths by default. We think this is information that most people won’t look for anyway, and those who do can still find it.

This change marks another milestone; for the first time, SSL Labs requires JavaScript for its full functionality. I know, it’s not really relevant, but still. For a really long time I liked the idea of providing a useful service without having to use any “bells and whistles”. But we move on!

Announcing SSL Labs grading changes for 2017

2016-11-16T00:00:00+00:00

At SSL Labs, we have a major review of our grading criteria about once a year. As the security of the ecosystem matures, our goal is to push forward and make the requirements [for a good grade] stricter. In many ways, this process of continuous improvement is what really matters to us.

According to our measurement in SSL Pulse, over 40% of the monitored sites have configuration that can be considered good. However, only about 3% of those get an A+, which is what everyone should be aiming for. So our goal with the design of the grading criteria is to push the number of A+ sites up.

In this blog post we will announce our short-term changes as well as outline some further changes that we will be making in 2017 and beyond. From the list below, the 3DES grading change will happen first. Other changes will follow. The main purpose of this blog post is to outline our grading directions so that organisations can start to plan their improvements.

Update (28 March 2017): The first batch of changes has been further documented in this follow-up blog post.

Penalty for using 3DES with modern protocols (C)

In late August, security researchers demonstrated an attack against ciphers that use 64-bit encryption blocks. The attack is not practical because it requires a very large amount of traffic, but it’s a good reminder that older and weaker ciphers need be retired as a matter of routine. In TLS, that means avoiding 3DES. Now, for sites that need to support an old user base completely retiring 3DES might not be possible (hint: Windows XP), but there’s no reason to use this cipher with modern browsers. To that end, we’ll be modifying our grading criteria to penalise sites that negotiate 3DES with TLS 1.1 and newer protocols. Such sites will have their scores capped at C. Sites that continue to support 3DES and keep it at the end of their ordered list of suites will not be affected.

Penalty for not using forward secrecy (B)

Forward security is a property of secure communication in which a compromise of a long term private key doesn’t affect any past encrypted conversations. In TLS, each deployment has to decide whether to provide forward secrecy. The very popular RSA key exchange, for example, doesn’t provide it. Because forward secrecy is one of the more important things to get right and we want to more emphasis on it; for that reason we will soon be requiring forward secrecy for the A grade.

We expect this to affect roughly 7% of the sites currently getting an A (currently at about 43%). If possible, we will not penalise sites that use suites without forward secrecy provided they are never negotiated with clients that can do better.

AEAD suites required for A+

Ever since the Lucky 13 attacks, the consensus in the security community has been that authenticated encryption is superior to CBC suites (as implemented in TLS). TLS 1.3 supports only AEAD suites. SSL Labs doesn’t currently reward the use of AEAD suites and we wish to correct this. In the next grading criteria update we will start requiring AEAD suites for A+. At some point in the future, AEAD suites will be required for A.

As with forward secrecy, we will not penalise sites if they continue to use non-AEAD suites provided AEAD suites are negotiated with clients that support them.

Protocol downgrade defenses

In April 2015, RFC 7507 introduced a new defense against voluntary protocol downgrade attacks; the full name of the standard is “TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks”. Because this defense closes a serious security loophole, SSL Labs requires that servers support the signalling value (TLS_FALLBACK_SCSV) to get an A+. The uptake was pretty good; according to the SSL Pulse results in August, 66% of all servers support this feature.

When we introduced this grading change, our intention was to eventually make SCSV support a requirement for A. In the meantime, POODLE came out, eventually leading to modern browsers generally removing voluntary protocol downgrade behaviour. At the moment, TLS_FALLBACK_SCSV doesn’t have a strong security value because the clients who support it won’t downgrade anyway. At the same time, the IIS doesn’t support RFC 7507, which means that anyone running their site on it can’t get an A+.

Given that the recent change to TLS 1.3 means that future protocol downgrades will be avoided, we will consider removing the requirement for TLS_FALLBACK_SCSV for A+.

Penalty for version intolerant servers

Initially, our intention was to introduce a penalty for servers intolerant to future TLS protocol versions. However, a change to the TLS 1.3 in the area of protocol version negotiation means that intolerant servers will no longer impede deployment of this protocol version. In that light, we are currently not planning to introduce a penalty for this problem.

Cipher grading adjustments

Our current algorithm for grading ciphers is not producing desired results, so we intend to introduce one or two explicit rules. First, all ciphers weaker than 128 (excluding 3DES) bits will result in an F grade. Additionally, servers that continue to support RC4—even if it’s not used with modern browsers—will be capped at C.

SHA1 deprecation

As you’re probably already aware, SHA1 has been deprecated for certificate signatures. In 2017, browsers will stop trusting web sites that continue to use this weak hash function for signatures. In line with the industry, we too will distrust such sites.

Further afield

The changes listed in the previous section will take place in the first half of 2017. We would like to take this opportunity to provide a rough outline of the future changes to SSL Labs grading criteria. The changes listed in this section will happen at some point in the future, when the time is right, but very likely not before Q3 2017. We will assess each change individually. We hope that this early notification will give organisations more time to plan ahead.

HSTS preloading required for A+
AEAD suites required for A
HSTS required for A
Sites with 3DES capped at B or C
Harsher penalty for sites that continue to support RC4
TLS 1.3 required for A+ (and for A, later, when the time is right)
OCSP stapling (and, possibly, must-staple at some point) required for A+

Is HTTP Public Key Pinning dead?

2016-09-06T00:00:00+01:00

I have a confession to make: I fear that HTTP Public Key Pinning (HPKP, RFC 7469)—a standard that was intended to bring public key pinning to the masses—might be dead. As a proponent of a fully encrypted and secure Internet I have every desire for HPKP to succeed, but I worry that it’s too difficult and too dangerous to use, and that it won’t go anywhere unless we fix it.

What is public key pinning?

Before I go on, let’s briefly discuss why we need public key pinning in the first place. The problem is with the way we manage trust: we have hundreds of CAs and each of them is able to issue a certificate for any web site in the world. Technically, owner permission is not necessary. Now, I think this system actually works rather well, which is evident from the fact that the rate of incidents is very low. But fraudulent certificates can be created in one way or another, and that’s not good enough for high-profile web sites. Further, technical people have trouble relying on a system that’s not foolproof.

Enter public key pinning, which is a technique that enables site owners to have a say in which certificates are valid for their sites. For example, in one of the possible deployment options, you choose two or more CAs to trust; after that, any certificate issued by anyone else is ignored. What’s not to like?

Public key pinning started at Google, and they first implemented in Chrome, pinning their own web sites. Their approach is an example of static pinning; the pins are not easy to change because they’re embedded in the browser. Chrome’s pinning has served us well over the years, uncovering many cases of fraudulent certificates that would otherwise perhaps fly under the radar. Google also allowed (and still does) that other organisations embed their pins in Chrome. These days, Firefox also supports static pinning, drawing from the same pins maintained by Google.

Whereas static pinning works well, it has a problem because maintaining pins is a slow manual process that doesn’t scale. For that reason Google also sparked the IETF work that lead to RFC 7469, officially known as “Public Key Pinning Extension for HTTP”, but which everybody calls just HPKP. HPKP is an example of dynamic pinning; web site owners can set the pins at will.

What is the problem with HPKP then?

The main problem with HPKP, and with pinning in general, is that it can brick web sites. The culprit is the memory effect: pins, once set, remain valid for a period of time. Each pin is associated with a unique cryptographic identity that the web site must possess to continue operation. If you lose control of these identities, you effectively also lose your web site.

Clearly, pinning introduces a paradigm shift. Without it, TLS is quite forgiving—if you lose your keys you can always create a new set and get a fresh certificate for them. With pinning, your keys become precious.

There is some relief in the fact that a valid HPKP configuration must include at least one backup key. The idea is that, if you something goes seriously wrong, you fetch your securely-stored backup key and resume normal operation.

Even if you don’t lose your pinning keys, you have to be careful how and when you’re changing them. Your configuration must, at any time, be offering at least one pin that matches the configuration you offered to all your previous users. If you rotate the keys too quickly you risk not having a pin for some of your older visitors.

To sum up, HPKP is not for the faint of heart; you essentially need to know what you’re doing and be careful about it.

Talking about knowing what you’re doing, HPKP is also too flexible about what you can do with it. With it you can pin any public key in the certificate chain, choosing from your own keys (the leaf certificate), the intermediate certificates, or the root. Each decision comes with its advantages and disadvantages, but you need to understand PKI very well to appreciate them. This flexibility is a point of great confusion that in practice often leads to paralysis (“What to do?”). Some sites will inevitably make the wrong choice and suffer for it.

Thus, a successful pinning strategy requires that you:

Build a threat model to determine if there is a real threat out there that pinning can address at an acceptable cost
Understand PKI and HPKP and choose the right place to pin
Avoid losing your pinning keys
Keep backup keys in a separate location in case of server compromise
Have a robust plan for the key rotation and execute it smoothly

The above steps aren’t terribly difficult to carry out, but the stakes are pretty high. A serious mistake with pinning can lead to the business shutting down. The deployment numbers reflect this; in August 2016 Scott Helme found only 375 sites with HPKP deployed, along with 76 sites with HPKP running in report-only mode. Contrast these numbers with about 30,000 instances of HSTS in the same data set.

Abusing HPKP

A potentially bigger problem with HPKP is that it can be abused by malicious actors. Let’s say, for example, that someone breaks into your server (a very common occurrence) and thus gains control of your web site. They can then silently activate HPKP and serve pinning instructions to a large chunk of your user base. It’s very unlikely that you will detect this. After a long-enough period, they remove the pinning keys from the server and brick your web site just for the fun of it. Or, if you’re lucky, they seek ransom, giving you a chance to get the backup pinning key from them and keep your business.

The HPKP working group had been aware of this problem (one early example here), but didn’t include a mitigation mechanism in the standard. Early HPKP drafts had specified a ramp-up period; pinning had to be observed over a period of time to become fully operational. That feature eventually got removed, probably because it wasn’t quite clear how to effectively assess continuity. In the end, the RFC specified that one active pin and one inactive (backup) pin are sufficient to activate pinning for essentially any duration. The “Hostile Pinning” section of the RFC mentions this problem almost in passing, noting that sites should be able to recover after the maximum policy duration expires. The RFC leaves to browsers to decide on their maximum max-age and has a very soft recommendation to cap it at 60 days.

We are not yet seeing attacks just yet because HPKP is relatively new, but the word is starting to get out. Just this month there was a talk at DEFCON about what they called RansomPKP. If you’re interested in this topic, you should also read this follow-up from Scott Helme, who provided more details.

So why do I say that HPKP is dead?

I think that, ultimately, HPKP requires too much effort and that only a small number of sites will ever deploy it. At the same time, it can be—in the current form—used as a powerful weapon against everybody.

The irony of HPKP is that it’s not going to be used by many sites (because it’s too taxing), but that it can be used against the long tail of millions of small sites who are not even aware that HPKP exists. For the small number of sites who are using pinning, it’s just as likely that static pinning would work well, with less fuss and no danger for the rest of the Web.

Can HPKP be fixed?

To fix HPKP we need to 1) make it easier and less dangerous to deploy and 2) have a way to deal with potential malicious use.

For the latter, one possibility is to “dull” HPKP so that it remains useful but that the really dangerous aspects of it are addressed. There’s a variety of ways in which this could be done. For example, we could reintroduce the ramp-up mechanism. Another solution might be to restrict pinning to those who can demonstrate a level of security knowledge and operational proficiency, for example those who are already preloading HSTS. And perhaps browsers can build an undo mechanism that could be used to override broken pins.

Making HPKP easier to use probably means allowing sites to deploy safer pinning, for example pinning to CAs, not their roots. In fact, that’s largely how static pinning is done right now. It goes like this: you choose 2-3 CAs and require that only they can issue valid certificates for your site. This approach is not as secure as pinning to the leafs (your own keys), but it vastly reduces the attack surface and with much less effort. (This idea had also been discussed during the development of HPKP, but it was rejected because it wasn’t a pure-technical solution and required collaboration of many organisations.)

Technically, pinning to CAs is possible today provided you have a very good understanding of PKI. The key issue is understanding how different root stores include different root keys, how root keys change, and so on. I have some hope that with more public information about these topics and with help with interested CAs we can make this safer style of pinning possible, even without any changes to HPKP.

What can you do today?

Leaving all the possibilities of the future aside, let’s try to figure out what we can do today. Here are some ideas you can consider to make yourself safer:

First, you could have a monitoring system in place to audit your configuration and detect unwanted pinning. For large enterprises this could be a good idea anyway, because pinning (and other security technologies) could be deployed by an eager developer, without organisation-wide coordination. (As an example, both HPKP and HSTS have a memory effect and also support the includeSubDomains directive, that could make a configuration spread to an entire domain name, even to servers controlled by other teams.)
You could front your sites with a reverse proxy and make sure that the HPKP response header is never sent to your users. This defence measure won’t address all the possible attack vectors (e.g., if someone redirects the web site to other servers and abuses a misissued certificate), but it would prevent escalation from server take-over.
If you don’t mind your hand being forced, the pinning itself can be an effective defence against malicious pinning. All the attack vectors that include DNS hijacking and fraudulent certificates can be detected if you’re already using pinning. Sadly, an attacker who takes control over your pins (by compromising your servers) can rotate the pins to those they control. (But the previous control, the reverse proxy, helps in that case.)

Thanks to Ryan Sleevi and Scott Helme for reading early drafts of this post.

SSL Labs: Improved suite detection

2016-08-31T00:00:00+01:00

In one of the future SSL Labs releases we will change how we detect supported protocol suites. Even though there will be no change to the grading algorithm because of this, our detection of obsolete and insecure suites will improve slightly, and that will worsen the grade of a small number of sites. We will publish this new version on October 1st or later.

When it comes to cipher suite detection, SSL Labs does something unusual: it tests for one cipher suite at a time. This is unusual because the obvious thing to do is to submit all suites you support, then see what comes back. The latter approach is faster, but the problem is that it doesn’t always work in practice; many servers break if you submit too many suites or if the ClientHello message is too long. (In one extreme case, a special TLS extension was designed to make sure the record sizes are just right.) In that light, the one-suite-at-a-time approach was the simplest way to get the job done. Sure, this approach is also slow, but SSL Labs does a lot anyway, so our tests are never going to be super-quick.

Slow testing we could live with, but we also noticed that many servers started to take protocol version into account when deciding which cipher suites to support. This change was in response to many issues discovered in the SSL and TLS protocols, contrasted against the need to support older clients. Because SSL Labs tests cipher suites only with the highest-supported protocol version, we started to miss some suites. We added some workarounds for the common cases, but this issue has not been resolved properly.

When you combine our slow cipher suite testing with testing separately for each supported protocol, the testing time rises significantly and we had no choice but to optimise. The good news is that this change improves the cipher suite detection and also works about 30% faster on average (than now).

TLS version intolerance in SSL Pulse

2016-08-02T00:00:00+01:00

You often hear that TLS is the most important security protocol. Usually, the reasoning is that it’s very widely deployed and also that it works for many higher-level protocols. That’s certainly true, but for those who work more closely with these protocols there is another important aspect: we can learn so much about protocol design by carefully examining the evolution of TLS.

Update (13 January 2017): Since this post was originally published, the TLS 1.3 specification was amended to change how future protocol versions are negotiated. The new approach bypasses the intolerance problem described below. Thus deployment of TLS 1.3 will proceed largely without fear of breaking compatibility.

Protocol Version Intolerance

One important lesson we learned is never to use explicit protocol version numbers. In TLS, they have been a continuous source of trouble, leading to waste of time and security issues. The root cause is the fact that there are many servers that freak out when a client offers to negotiate a TLS version number they don’t understand. According to the protocol specification, they’re supposed to respectfully decline to use an unknown version and fall back to the best protocol they can offer.

Despite this being a server-side problem (and, at a deeper level, a library problem), in practice browsers get all the blame if they can’t communicate with a particular web site. This leads to a behaviour sometimes called voluntary protocol downgrade: after trying their best protocol version and failing, browsers try their second best, then third best, and so on, until hopefully they manage to establish an encrypted channel with the server.

Although this browser behaviour helps with interoperability, it slows down communication and also enables active network attackers to downgrade secure communication to the worst protocol version supported by both the client and server.

After many years of struggle, major browsers vendors eventually managed to disable the fallbacks. The fallback to SSL v3 was the first to go, prompted by the discovery of the POODLE attack. Other fallbacks were removed later, as you can see on this timeline of events in the SSL/TLS ecosystem.

TLS 1.3

The version intolerance problems will persist for as long as we continue to publish new protocol versions. Protocol fallbacks are relevant again because TLS 1.3 is close to being finished and we now have to face the harsh reality of many intolerant servers out there.

Testing for version intolerance in SSL Labs

Protocol version intolerance testing has been implemented in SSL Labs for a very long time. If you’re unfortunate to run into a server that’s intolerant to some of TLS 1.0, 1.1, or 1.2, you get a big warning. But such servers are getting increasingly rare; after all, most browsers implemented TLS 1.2 by the end of 2013, which means that system owners have had a few years to resolve the intolerance problems.

We also test for intolerance of TLS 1.3 and some other absurdly large version numbers. The TLS 1.3 results are now of immediate interest; the other tests possibly more of interest to protocol developers.

Given that the release of TLS 1.3 is imminent, we’re planning to make the intolerance warnings more prominent, as well as take it into account when grading servers. There will soon be a separate post about that.

Version intolerance tracking in SSL Pulse

Our SSL Pulse project, which monitors SSL/TLS configuration on about 150,000 most popular web sites, provides version intolerance information from the first ever scan we did in April 2012. You can see what that looks like in the following chart.

You can see that, in our most recent scan (July 2016), 3.2% servers from our data set don’t like TLS 1.3. A further 3.6% servers don’t like TLS 2.152. This doesn’t sound like much, but it’s a huge problem for browsers because it translates to thousands of sites, some very popular.

You will also notice a huge drop in the number of intolerant servers in May 2015, which warrants an explanation. When we first started measuring version intolerance, the problem was genuinely much bigger; at peak, with about 12% servers intolerant to TLS 1.3 and over 60% servers intolerant to TLS 2. With such numbers, there was little chance of introducing a new protocol version smoothly. But then someone realised that the problem could be reduced with only a slight tweak to the TLS 1.3 protocol.

If you look under the hood of any SSL or TLS protocol version, you will see that they all use two different version numbers. There’s one version used for the main protocol (TLS 1.0, 1.1, and so on), but there is also the record layer version. You can think about the record layer as a subprotocol. With two version numbers, there’s always been a confusion about what exactly to send in each field. Some clients would only use the main protocol version (e.g., TLS 1.2), but keep the record layer version at SSL 3 or TLS 1.0, to indicate that, at that layer, nothing changed. However, some clients would use the bigger protocol versions for both fields. Naturally, in our tests we simulated the worst case.

Anyway, it transpired that most problems arise from record layer intolerance. Given that no one actually needs two version numbers, the TLS 1.3 specification was subsequently changed to deprecate the record layer version number and fix it at TLS 1.0 (0x0301). Then, some time later, in May 2015, we started testing for version number intolerance under the new rules, which caused the big drop.

New release of SSL/TLS Deployment Best Practices

2016-06-27T00:00:00+01:00

This month I released an updated version of SSL/TLS Deployment Best practices—my favourite SSL Labs publication—bringing the document up to date again. Given that the previous release was a long time ago (December 2014!), this version has quite a few changes and improvements.

Now, despite the numerous changes, the advice didn’t change that much. The updated version puts more emphasis on using authenticated cipher suites. In practice, we’re not seeing attacks against CBC, but it’s prudent to improve the margin of safety.

There’s been several interesting attacks since the previous version, for example FREAK, Logjam, and DROWN. However, those who followed the earlier versions of the guide wouldn’t have been vulnerable to any of these problems. Still, these attacks are now mentioned in the document. I am also spending more time discussing why it’s important to deploy with strong key exchange.

I’ve also made the guide more practical by giving a recommended list of cipher suites, something I didn’t do before. That one paragraph alone should save the readers a lot of time trying to figure that out on their own. In addition, I added HSTS and CSP examples to help improve site security and get rid of mixed content. Subresource integrity is also mentioned as a way to deal with third-party trust.

There’s also a large number of smaller updates, as well as tips and tricks. The best thing is that the document is now hosted in the SSL Labs’ wiki on GitHub; decoupled from the software development cycle of the main web site, it can now be updated whenever it’s necessary.

I am very happy to continue to maintain SSL/TLS Deployment Best Practices; given the amount of stale documentation that’s out there, having a concise and comprehensive guide to secure server configuration is very important.

Available now: The Best TLS Training in the World

2016-06-15T00:00:00+01:00

I am pleased to reveal the next step in my quest to help the world make better use of encryption; starting with this September, I will teach a practical one-day practical SSL/TLS and PKI training course in London. The idea is to cover everything developers and system administrators need to know in their daily work. You'll find the complete course outline and other details on the course homepage.

I named the course “The Best TLS Training in the World”, in part because I wanted to show that it’s not going to be boring, but mostly because the training will be everything I know about the topic, distilled into a practical hands-on experience. (And, after years spent researching and writing, I know a lot.) There’s a lot of fluff around TLS, but things can be quite straightforward if you know where not to look.

I am not new to training; I used to teach Apache Security a lot back some 10 years ago, and I started teaching TLS occasionally after Bulletproof SSL and TLS came out; it was just one client, with the idea to experiment and refine the approach until it’s just right. That training turned out to be a huge success, so I eventually decided to make it available to a wider audience. The first training is at CodeNode on September 15th. The price is currently £595 (it includes a £100 early-bird discount available until July 15th), but—to celebrate—I am giving away 5 seats at a special price of £445. Use the coupon TLSJUNE at the checkout. The offer is available on first-come, first-served basis, so hurry up!

The Best TLS Training in the World

SSL Labs in 2016 and beyond

2016-05-16T00:00:00+01:00

In early 2009, SSL Labs was just this idea I had, born out of frustration with having to deal with a very complex subject without good documentation and tools. I wanted something that worked for me, and didn’t really anticipate that it could become as popular as it is today. The first version launched in the summer of that same year.

I joined Qualys in 2010, not knowing that I’d stay for 6 happy and productive years. In that time, SSL Labs went from a lovely but little known site, to the popular SSL/TLS destination it is today. It’s now a de-facto standard for secure server assessment. More important, it became a place that helps you deploy your systems securely. Over the years I watched with quiet joy tens of thousands of sites improve their configuration, a process that accelerated with the rise of popularity of SSL Labs. The last time I looked at the statistics, hundreds of thousands of people were on the site monthly, usually several times.

Qualys have been fantastically supportive of my work. Even though I didn’t originally join to work on SSL Labs, the site became my primary job at the point when that was most needed. To their credit, the web site remained free and there was never any attempt or even idea to compromise on the service in any way. In fact, almost the only mention of Qualys is the logo at the top of the web site. It’s so rare to give unreservedly, without asking for anything in return.

My journey was long, but exciting. Over the years, in a quest to understand it all, I immersed myself in the ecosystem. Somewhere along the line I couldn’t resist the temptation to write another book, and Bulletproof SSL and TLS was born.

After 7 years with SSL Labs, it’s time for me to move on and pursue other projects, but my journey doesn’t end here. In fact, even though I left Qualys as an employee, I am staying on as an advisor to help SSL Labs continue to improve. After all, SSL Labs is a big part of me and I can’t leave it behind just like that.

Looking from outside, there probably won’t be many changes. I will be less active on the forums and mailing lists, but I’ll still be there. Qualys are committed as ever to continue making SSL Labs better. In fact, over the last two months I’ve been helping my colleagues Yash and Bhushan take over the development; we’re now planning the next steps together.

Qualys, thank you for a wonderful opportunity to work on what I love. It was a pleasure working with you all. Also thanks to everyone who used SSL Labs over the years and especially those who wrote in, reported problems, and asked for improvements. You helped shape SSL Labs into what it is today.

Now onto the new adventures that await in the future! I’ll see you on the net.

SSL Labs DROWN test implementation details

2016-03-04T00:00:00+00:00

Two days ago the DROWN vulnerability came to light, showing new ways to attack TLS. SSL Labs deployed tests for DROWN in the staging environment yesterday, and we’ll be pushing it to production shortly. Because DROWN is a tricky problem, the aim of this blog post is to provide an explanation of what we test for and how exactly.

First of all, we have known SSL v2 to be insecure for a very long time—over 20 years. As a result, even before DROWN SSL Labs used to give Fs to servers that supported this ancient version of the SSL protocol. DROWN actually makes things worse, because it abuses SSL v2 to attack all other protocols, but we don’t have a worse grade, so F will have to do.

Further, DROWN introduces two additional attack vectors:

A server that has SSL v2 enabled can be used to attack any other servers that reuse the same RSA key; even those servers that don’t themselves support SSL v2. This attack is generic (CVE-2016-0800) and affects any protocol implementation.
A server that has SSL v2 enabled and is also running a special vulnerable version of OpenSSL (CVE-2016-0703) can be used to attack all other hostnames appear in its certificate.

For the above reasons, the security of a server can’t be determined only by looking at its configuration. For DROWN, we have to look for the presence of the server’s RSA keys and/or certificate hostnames elsewhere. As you can imagine, this can be tricky. However, this is where the DROWN authors and Censys come in: they have exposed an API that SSL Labs now uses to find vulnerable servers in their data set.

Because the data we’re getting from Censys can be potentially stale, in SSL Labs we perform real-time checks for any of the above conditions. If we can find one matching server elsewhere, we consider the server being tested to be vulnerable and give it an F. Please note that the first 4 columns of the results (IP Address, Port, Export and Special) come from the search engine and could be outdated. The last column (Status) comes from SSL Labs; it reflects the current situation.

One final thing: if you’re manually checking the SSL Labs results, please don’t get confused if you’re unable to connect to a host using SSL v2. If SSL Labs is still showing the host as vulnerable, chances are it’s using a version of OpenSSL that can complete a handshake even when no cipher suites are configured (CVE-2015-3197). SSL Labs checks for this variant as part of its testing.

DROWN grading update

2016-03-04T00:00:00+00:00

We are releasing an update to the grading criteria, version 2009l, to respond to the discovery of the DROWN attack. If a server is found to be vulnerable to DROWN it will be given an F, even though it might not support SSL v2 itself. (The nature of the DROWN vulnerability is such that servers that support SSL v2 can affect other servers, irrespective of supported protocol versions). You’ll find more information about our DROWN test here. Additionally, servers that support SSL v2 but don’t have any cipher suites configured are treated as if they had SSL v2 fully enabled.

This update also contains two fixes to our grading code, which we don’t consider to be changes to our grading criteria:

Servers that have invalid HPKP information are not awarded A+.
Servers that have an RSA key with exponent 1 are given an F.

DROWN abuses SSL v2 to attack TLS

2016-03-01T00:00:00+00:00

A fascinating new research called DROWN has uncovered a previously-unknown vulnerability in SSL v2, the first ever version of SSL that was released in 1995 and declared dead less than a year later. Even though this old version of SSL is not used much these days, it continues to be supported by many servers. The especially bad aspect of this attack is that it can be used to exploit TLS, even in cases when client devices don’t support SSL v2, and sometimes even in cases when the servers don’t support SSL v2 (but use the same RSA key as some other server that does). The researchers estimate that up to 22% of servers could be impacted by this problem.

Disable SSL v2 everywhere now

The attack is not trivial, but can be done cheaply against high-value targets. Before you go on to learn more about it, I recommend that you first ensure your systems are not vulnerable. Fortunately, remediation is straightforward: disable SSL v2 on all servers you have. It’s as simple as that…. but I really do mean all servers. If you’ve been reusing private RSA keys (even with different certificates), disabling SSL v2 on one server is not going to help if there’s some other server (possibly using a different hostname, port, or even a protocol) that continues to support this old and crazy-vulnerable protocol version.

Impact of the generic attack

The attack is an extension of the 1998 Bleichenbacher attack that can be used to decrypt a ciphertext when a padding oracle exists. For more information, I suggest that you read the original DROWN research, which is very interesting indeed. However, the bottom line is that one out of every 1,000 full TLS handshakes can be decrypted, leading to the compromise of the entire TLS session (potentially many connections of data). The cost is modest—only $440 and 8 hours. (The attack can be sped up if you want to spend more money on it. There is also a much better attack against some OpenSSL versions; I describe it later in this text.) The generic attack is entirely passive, but requires that 1) RSA key exchange is used and 2) that there is an SSL v2 server configured with the same private RSA key.

The worst case is when an automated service is attacked, anything that might be carrying connection credentials. Even though you need 1,000 full TLS handshakes, you’ll get those in a matter of hours, and the credentials will be yours to do as you’re pleased.

Attacking browser sessions is going to be more difficult, because HTTPS servers typically rely on TLS session caching as a way of improving handshake performance. A bigger problem is that user sessions rarely carry credentials; in most cases you can compromise session cookies and perform account hijacking. But that’s not bad at all!

Speeding-up the generic attack

I developed a slight improvement to the attack, for the cases when you don’t want to wait a lot of time to collect those 1,000 handshakes and don’t mind carrying out an active attack. It’s possible to speed things up by injecting some JavaScript into the victim’s browser (a-la-BEAST). You’re still up against TLS session caching, though. But TLS has an interesting property, in that it requires TLS sessions to be invalidated whenever an error occurs (e.g., client receives an invalid TLS record). Thus, as a MITM, all you need to do is force an error on established TLS sessions, causing a new full handshake on the subsequent connection. This way you can obtain the required 1,000 TLS handshakes very quickly.

Best attack variant is against vulnerable OpenSSL servers

The best attack variant is against servers that use a vulnerable version of OpenSSL. The recent versions of OpenSSL are not vulnerable because the exploited flaw had been patched (without knowing) in March 2015. But, if the conditions are right, the same SSL v2 flaw can be used for real-time MITM attacks and even against servers that don’t support the RSA key exchange at all.

Obsolete crypto is dangerous

Once again, we realise that obsolete crypto is dangerous. For many years the argument for not disabling SSL v2 was that there was no harm because no browsers used it anyway. We heard the same thing before learning about Logjam, and also before FREAK. This approach is obviously not working. Instead, in the future we must ensure that all obsolete crypto is aggressively removed from all systems. If it’s not, it’s going to come back to bite us, sooner or later.

How Bulletproof SSL and TLS is a living book

2015-08-31T00:00:00+01:00

I often say that Bulletproof SSL and TLS is a living book, but what does that mean exactly? It's now been one full year since the initial release, so what better time to look back to understand the process. It turns out there is a lot of work producing a living book that covers a turbulent field such as SSL/TLS and PKI. I've broken down the process into five steps:

Ongoing maintenance; I make small updates all the time as I learn new facts that are of potential interest to my readers. For example: new RFCs being released or updated, new software releases that other features or change behaviour. As an illustration, a recent JDK update disabled RC4 by default; when it came out, I updated my Java chapter to add a reference to the update.

There are other small changes that fall into this category, for example fixing typos and errors, and rewriting small parts of the text in response to reader questions. The book should be clear enough so that questions are not necessary.
New content; I add larger chunks of text as necessary. This usually happens when there is a significant new discovery, for example a new protocol vulnerability. For example, POODLE and POODLE TLS, FREAK and Logjam all happened in the year after the first edition, and they’re now all covered in the book.

I don’t write about events immediately after they happen, for two reasons. First, because discoveries usually lead to other discoveries. That’s how collaborative security research works; an army of researchers starts to look at a problem and contributes to the body of knowledge. The second reason is that I prefer to analyse a situation with a clear head and after the dust settles. Immediately after a discovery, things sometimes seem more exciting than they really are.

My process usually begins with a blog post. To write about something clearly requires that you understand it very well; writing a blog post therefore forces me to research the problem in depth. I will then mention the news in the Bulletproof TLS newsletter, my periodic notification service. For urgent matters, an email goes out straight away. Finally, within a month or two, I will have added complete coverage of the discovery to the book.
Quarterly updates; My quarterly updates add structure to the maintenance process. This is where I review the events of the last quarter to make sure that everything that should be covered is covered. Sometimes, new discoveries require not only new content, but book-wide changes. The quarterly update is an opportunity to make the advice in the book consistent.

At the end of each quarter, my copyeditor, Melinda Rankin, goes through the new content and improves the language. Because all changes are made with change-tracking enabled, she knows exactly where the changes are, making it possible to do copyediting incrementally.
Revisions; After a certain time, I will revise the entire book. What this means is that I read every single page and ensure that the text is fresh enough for a fresh printing. This process catches a lot of small things that slipped through, and generally rejuvenates the book. Then we follow with another copyediting phase, and then an additional proofreading cycle.

At the end of a revision, the book is brand new. Because we use print on demand, we release new files to our printer, after which they start to print what is essentially a new edition. We don’t make much noise about this because, even with print on demand, book sellers have a stock that they need to go through. In other words, we don’t know when exactly they will start selling the new version of the book.

We released our first full revision of Bulletproof SSL and TLS this month, which is exactly one year after the first edition came out in August 2014. The updated version has about 30 more pages, and countless small improvements throughout.
Editions; Depending on the amount of new content, at some point we will publish a formal new edition, with a new cover, ISBN number and everything else. With a living book, determining when a proper new edition should be made is tricky. You’re adding content all the time, at what point do you call it a new edition? Having a fresh release date would surely help with sales. On the other hand, we don’t want those who already have the book to buy the new edition if there isn’t enough new content in it.

Given that TLS 1.3 is currently being worked on, the likely outcome for Bulletproof SSL and TLS is that we will publish the second edition after TLS 1.3 is ready and can be used in practice. In the meantime, we’ll just keep updating the first edition.

Introducing TLS Maturity Model

2015-06-08T00:00:00+01:00

As part of my job working on SSL Labs, I spend a lot of time helping others improve their TLS security, both directly and indirectly–by developing tools and writing documentation. Over time, I started to notice that deploying TLS securely is getting more complicated, rather than less. One possibility is that, with so much attention on TLS and many potential issues to consider, we're losing sight of what's really important.

That's why I would like to introduce a TLS Maturity Model, a conceptual deployment model that describes a journey toward robust TLS security. The model has five maturity levels.

At level 1, there is chaos. Because you don't have any policies or rules related to TLS, you're leaving your security to chance (e.g., vendor defaults), individuals, and ad-hoc efforts generally. As a result, you don't know what you have or what your security will be. Even if your existing sites have good security, you can't guarantee that your new projects will do equally well. Everyone starts at this level.

Level 2, configuration, concerns itself only with the security of the TLS protocol, ignoring higher protocols. This is the level that we spend most time talking about, but it's usually the easiest one to achieve. With modern systems, it's largely a matter of server reconfiguration. Older systems might require an upgrade, or, as a last resort, a more secure proxy installed in front of them.

Level 3, application security, is about securing those higher application protocols, avoiding issues that might otherwise compromise the encryption. If we're talking about web sites, this level requires avoiding mixing plaintext and encrypted areas in the same application, or within the same page. In other words, the entire application surface must be encrypted. Also, all application cookies must be secure and checked for integrity as they arrive in order to defend against cookie injection attacks.

Level 4, commitment, is about long-term commitment to encryption. For web sites, you achieve this level by activating HTTP Strict Transport Security (HSTS), which is a relatively new standard supported by modern browsers (IE support coming in Windows 10). HSTS enforces a stricter TLS security model and, as a result, defeats SSL stripping attacks and attacks that rely on users clicking-through certificate warnings.

Finally, at level 5, robust security, you're carving out your own private sliver of the PKI cloud to insulate yourself from the PKI's biggest weakness, which is the fact that any CA can issue a certificate for any web site without the owner's permission. You do this by deploying public key pinning. In one approach, you restrict which CAs can issue certificates for your web sites. Or, in a more secure case, you effectively approve each certificate individually.

The conceptual simplicity of the TLS Maturity Model enables us to easily understand where we are and what we need to do to improve. As a result, we can focus our attention on what really matters. Although level 5 provides best security, it involves most work and addresses risks that don't exist for most sites. Level 4 is arguably the minimum level that can be called secure, and the level that most organisations should be aiming for.

SSL Labs: Increased penalty when TLS 1.2 is not supported

2015-05-22T00:00:00+01:00

Earlier this week we released SSL Labs 1.17.10, whose main purpose was to increase the penalty when RC4 is used with modern protocols (i.e., TLS 1.1 and TLS 1.2). We had announced this change some time ago, and then put in place on May 20. The same release introduced another change, which was to increase the penalty for servers that don't support TLS 1.2 from B to C. And it seems that this second change is being somewhat controversial, with many asking us to better explain why we did that.

Although what initially prompted us to think about changing the grading for not supporting TLS 1.2 was grade harmonisation (ensuring that a wide range of servers all get grades that make sense -- in other words, to have better-configured servers have better grades), that doesn't change the fact that the reality is that TLS 1.0 is an obsolete security protocol. TLS 1.0 came out in 1999, followed by TLS 1.1 in 2003 and TLS 1.2 in 2008. These new protocol versions were released for a reason -- to address security issues with earlier protocol versions. But, despite being obsolete, TLS 1.0 continues to be the best supported protocol version on many servers. It's not very bad, mind you -- we know from SSL Pulse that about 60% of servers already support TLS 1.2. Client-side, the situation is probably better, because modern browsers have supported TLS 1.2 since 2013. You could say that, overall server configuration is the weaker link.

In that light, we feel that the increase of the penalty for the lack of TLS 1.2 is the natural next step in the deprecation of TLS 1.0. In fact, SSL Labs is probably late in doing that. Just last month, the PCI Security Council deprecated SSL v3 and TLS 1.0 for commercial transactions. No new systems are allowed to use TLS 1.0 for credit card processing and existing systems must immediately begin to transition to better protocols. In comparison, the SSL Labs change of grading is only a mild nudge in the right direction. And, while some people are not happy that we're pushing for TLS 1.2, others are complaining that we're not doing enough. For example, the Chrome browser has been warning about lack of TLS 1.2 and authenticated (GCM) suites for some time now. Clearly, it's difficult to make everyone happy.

The bottom line is that TLS 1.0 is insecure and we must migrate away from it. In 2011, there came the BEAST attack, and, in 2013, the Lucky 13 attack. TLS 1.0 remains vulnerable to this problems, but TLS 1.2 (with authenticated suites) isn't. These attacks are serious and some organisations continue to use RC4 in combination with TLS 1.0 just to be sure that they are mitigated. We understand that many organisations face significant challenges adding support TLS 1.2, but that is unavoidable. In computer technology, and in security in particular, it is often necessary to keep running just to stay in place.

We did get one thing wrong, however -- we didn't communicate our grading changes in advance. It was not our intention to surprise anyone. In fact, we'd prefer much more if changes were smoother. To that end, in the future we'll be announcing all grading changes with at least one month notice, and hopefully more for some more significant changes.

Update (3 June 2015): Notification of SSL Labs grading changes (including signups to get notifications by email) is now available at SSL Labs Notifications.

SSL Labs 1.17: RC4, Obsolete Crypto, and Logjam

2015-05-21T00:00:00+01:00

Yesterday we released SSL Labs 1.17.10, whose main goal was to introduce grading adjustments we had talked about a month ago. We delivered the planned changes as well as a few additional tweaks. Our release coincided with an announcement of a new attack against TLS, called Logjam, and we had some time to work on that, too.

RC4

As discussed last month, starting with this version we are increasing our penalty for using RC4 with modern TLS versions, namely TLS 1.1 and better. Sites that do that are now capped at C. Sites that use RC4 only with older clients will be capped at B. Sites that do not use RC4 will get an A, assuming absence of other problems.

No TLS 1.2 Support

It is important for servers to support modern protocols in order to take advantage of the best security features present in modern clients. To emphasise this, sites that don't support TLS 1.2 are now capped at C (was B previously).

Logjam

Logjam, the new attack on weak Diffie-Hellman (DH) parameters is yet another reminder that supporting obsolete cryptography is never a good idea. Even though TLS provides a negotiation mechanism that should in theory enable modern clients to communicate using only strong security, in practice there are ways to abuse either the clients or the protocol and perform downgrade attacks.

Diffie-Hellman key exchange strength is a relatively obscure aspect of TLS protocol configuration. Until recently, most web servers didn't even have an ability to tune this setting, and some servers don't even today. That wouldn't be a problem, except that most servers default to insecure values. SSL Labs started highlighting servers with weak DH parameters some years ago in an effort to raise awareness of this issue.

Logjam affects only incorrectly configured SSL/TLS servers. Those who have followed best practices (e.g., SSL/TLS Deployment Best Practices from SSL Labs) aren't using any of the vulnerable cryptography and need not make any changes to mitigate LogJam. In addition, for performance reasons, well-tuned sites prefer key exchanges based on Elliptic Curve cryptography, avoiding problems with DH altogether. In SSL Labs, servers vulnerable to the LogJam attacks are graded as F; no changes were made specifically for this attack.

That said, we did extend our SSL/TLS Client Test to detect when user agents accept Diffie-Hellman key exchange that has only 512 bits of security.

Weak DH Parameters

Even though for most sites there isn't an immediate vulnerability if they're using 1024-bit DH parameters (state attacks are not part of most sites' threat model), such parameters are weak and should be discouraged. We have been warning about weak DH parameters for a long time; now, with the announcement of Logjam, we feel that it's a good time to move one step further. As of yesterday, sites that continue to use weak DH parameters are capped at B.

What's new in SSL Labs 1.16

2015-04-28T00:00:00+01:00

Yesterday, we released a new version of SSL Labs. In this blog post I'd like to quickly go over what was changed: there were a healthy number of improvements, a few fixes, and a large number of additions to the API.

New features and assessment improvements:

Added checks for Certificate Transparency in certificate, stapled OCSP response and TLS extensions
Stapled OCSP responses are now always checked, with any errors shown in the UI
Java 8 simulation takes into account the 2048-bit DH parameter limit
Java simulations take into account that Java aborts TLS handshakes if it sees unrecognized_name TLS warning
When a strong suite is used with weak or insecure DH parameters, only the parameters are highlighted (using orange or red, as appropriate). This should make it easier to understand exactly what is problematic.
Tests for TLS version intolerance to TLS 1.3+ now use 0x0301 version at the record layer. This change aligns our testing with the recent similar change in the TLS 1.3 specification, which aims to minimise intolerance issues.
Enabled throttling for assessments submitted via the web site. Previously, throttling was enabled only for the API, but, unfortunately, we're seeing out-of-control scrapers that push our load for no good reason and use an unfair share of resources. Throttling is now uniformly implemented, with limits on per IP address-basis. Only new assessment requests are checked; if your IP address already has too many concurrent requests, you will be asked to come later. However, you're not actually supposed to see this message unless you're submitting automated assessments. If you do, please get in touch with us and tell us your IP address. Perhaps our throttling configuration needs to be tuned.

Other smaller changes and fixes:

Updated root store to the latest from Mozilla (only one weak 1024-bit root left!)
Updated browser simulations: Chrome 42, Firefox 37, IE11, and IEMobile 11
The terms and conditions now cover the case when our APIs are used by infrastructure providers (no need to contact us any more!)
All times are now shown in UTC
Fixed A+ awarded with 1024-bit DH parameters
Lots of other smaller changes

API improvements:

Added EndpointDetails.freak
New ChainCert fields: notBefore, notAfter, sigAlg, keyAlg, keySize, keyStrength
Added Cert.sct
Added EndpointDetails.hasSct
Added EndpointDetails.poodle
New EndpointDetails fields: staplingRevocationStatus and staplingRevocationErrorMessage
New Cert fields: crlRevocationStatus and ocspRevocationStatus
New ChainCert fields: revocationStatus, crlRevocationStatus and ocspRevocationStatus
Added Endpoint.gradeTrustIgnored
Field ChainCert.issues is now set to zero if there are no issues. Previously this field wouldn't exist in the JSON structure.
Fixed ChainCert.issues didn't flag weak (e.g., SHA1) certificates

SSL Labs RC4 deprecation plan

2015-04-23T00:00:00+01:00

Nobody wants to use RC4. This well known stream cipher would have been retired long time ago if it weren't for several critical problems in SSL and TLS, problems that affect block ciphers only–for example, BEAST, Lucky 13, and POODLE. So RC4 ended up being the lesser evil.

Take BEAST, for example. There are mitigations for it (the so-called 1/n-1 split) in all major browsers, but there's also potentially a large number of users who are not updating their browsers (or operating systems). For POODLE, on the other hand, we don't have a workaround. Those who can disable SSLv3 are lucky, because they don't have to worry about this problem. Anecdotally, there are still many companies that can't do that. Small sites usually don't have to worry about these problems, but, for large companies, the worry is about the long tail of vulnerable clients.

So it seems that we have two large groups: in one corner are users with modern software. They support TLS 1.2 and modern cipher suites. They are safe. In the other corner we have those with old SSL/TLS stacks, who support TLS 1.0 at best; some of them might be vulnerable to the BEAST attack, and most of them to POODLE as well. At SSL Labs, we want to fully deprecate RC4, but we don't want to penalise those who continue to need this cipher to support old clients. After all, there are no publicly-known feasible attacks against RC4, but there are such attacks for BEAST and POODLE.

At the moment, when a server offers RC4, we cap the grade at B, because we deem that the server supports an undesirable encryption algorithm. Although it might be all right to continue to use RC4 in some cases, it's only fair to give a better grade to those servers that do not use it.

In the future, we're going to start differentiating between servers that use RC4 with everyone and those that use it only with older clients. If you're using RC4 only with SSL 3 and TLS 1.0, your grade will continue to be capped at B. However, if you're using RC4 with TLS 1.1 or a better protocol, the penalty will be harsher.

In order to give time to server operators to act, we will increase the penalty in two steps. The first change will be in May, about one month from now, when we will start penalising servers that use RC4 with modern clients. They will be capped at C (now B). Several months after that (tentatively September), we will increase the penalty to F.

To sum up:

If you want the best grade, don't use RC4. This is the only recommended option.
If you feel that you need to continue to use RC4 for older clients, you'll get a B if you properly configure your systems.
Otherwise, the penalty for using RC4 with modern clients (TLS 1.1+) will increase to a C in about one month, and then an F in a couple of months after that.

OpenSSL Cookbook 2nd Edition released

2015-03-03T00:00:00+00:00

Today we’re releasing the second edition of OpenSSL Cookbook, Feisty Duck's free OpenSSL book. This edition is a major update, with some improvements to the existing text and new content added. The new edition has about 95 pages, an increase of about 35 pages.

Here’s a brief overview of what’s new:

New chapter Testing with OpenSSL, which focuses on secure server assessment.
New section Recommended Configuration, which contains a list of recommended cipher suites. I now prefer to configure OpenSSL by explicitly listing all the suites I wish to enable.
New section Creating a Private Certification Authority, which contains a step-by-step guide to creating and deploying a private CA.
Updated SSL/TLS Deployment Best Practices to v1.4. Important changes in this version include SHA1 deprecation and SSL 3 weaknesses (POODLE).

Another important improvement is that I am switching from updating OpenSSL Cookbook once in a while (the previous edition was released in October 2013) to making small changes as the need arises. There still might be further editions, but only when and if new content is added.

OpenSSL Cookbook draws from the content written for my bigger work, Bulletproof SSL and TLS. If you’re looking for a complete guide to the world of SSL/TLS and Internet PKI, give the bigger book a try.

That said, the main goals of OpenSSL Cookbook are to be useful, short, and contain documentation for everything you might want to do with it as a user (i.e., no programming). If you’re looking for something and you can’t find it in this book, please get in touch to propose improvements.

SSL Labs APIs now available in Beta

2015-01-22T00:00:00+00:00

In the end-of-year post last month, I mentioned that SSL Labs APIs had been made available for early access. What that meant was that we wanted some people to have a look at our APIs and play with the open source reference client, but otherwise didn't want everyone to come at once. After a period of testing, we're ready to move to the next phase. The APIs (as in the specification, not the implementation) are now considered stable and we're committed to supporting them for a long period of time. We're also happy with more people looking at the APIs and using them. The APIs are still running on our development servers and may lack the power of our production cluster, but are otherwise stable and fully production ready. In the following weeks we'll do some more testing, with the goal of moving the APIs into production by the end of February.

We see three important use cases for our APIs:

Testing of your own infrastructure
Integration with CAs and large infrastructure providers (e.g., hosting providers, CDNs, etc).
Integration with non-commercial open source tools

We will formulate formal terms and conditions soon. We regret to say, but at this time we are not interested in integration of SSL Labs with commercial products, or the use of the APIs to build web sites (e.g., report aggregators) or online testing tools.

All you need to use the APIs is available from our GitHub repository: https://github.com/ssllabs/ssllabs-scan.

I hope you'll find the APIs useful. If you'd like to give us your feedback and/or participate in the further development of the APIs and the reference client, please join us on the ssllabs-devel mailing list: https://sourceforge.net/p/ssllabs/mailman/ssllabs-devel/.

SSL Labs end of year 2014 updates

2014-12-08T00:00:00+00:00

From the SSL/TLS perspective, 2014 was quite an eventful year. The best way to describe what we at SSL Labs did is we kept running to stay in the same place. What I mean by this is that we spent a lot of time reacting to high profile vulnerabilities: Hearbleed, the ChangeCipherSpec protocol issue in OpenSSL, POODLE (against SSL 3 in October and against TLS in December), and others. Ultimately, this has been a very successful year for us, with millions of assessments carried out.

We have just deployed what is principally our last update for 2014, bringing several improvements and refinements:

We made a series of improvements to our grading criteria, to keep up with recent discoveries and continue to nudge site operators to improve their configurations:
- Servers that support SSL 3 are now capped at B (C if vulnerable to POODLE).
- Grade F given to servers that support only SSL 3.
- Servers that support RC4 are capped at B.
- Incomplete certificate chains capped at B.
- A+ servers are now expected to support TLS_FALLBACK_SCSV and have a SHA2 certificate chain.
The Client Capabilities test has been extended to test client support for all protocol versions, from the first SSL 2 until the most recent TLS 1.2. There have been many improvements to handle various edge cases.
Our SSL/TLS Deployment Best Practices guide has been fully updated.
SSL Labs APIs and our open source client tool for automated bulk testing have become available for early access. We are very excited about our making our APIs publicly available and hope that this will make it easier for system administrators to keep an eye on their systems.
There have been many small improvements throughout, thanks for the attention to detail of the members of our growing SSL Labs community.

According to SSL Pulse, before these changes we had about 24% secure servers. Now, the latest results (not yet released, but will be soon) show that number drop down to 11%. This shows that others, too, have to “run” in the same way that we do.

Naturally, we have many plans for 2015, but we’ll talk about them in a couple of weeks. In the meantime, I hope that you will enjoy the SSL Labs updates.

POODLE bites TLS

2014-12-08T00:00:00+00:00

There’s a new SSL/TLS problem being announced today and it’s likely to affect some of the most popular web sites in the world, owing largely to the popularity of F5 load balancers and the fact that these devices are impacted. There are other devices known to be affected, and it’s possible that the same flaw is present in some SSL/TLS stacks. We will learn more in the following days.

If you want to stop reading here, take these steps: 1) check your web site using the SSL Labs test; 2) if vulnerable, apply the patch provided by your vendor. As problems go, this one should be easy to fix.

Today’s announcement is actually about the POODLE attack (disclosed two months ago, in October) repurposed to attack TLS. If you recall, SSL 3 doesn’t require its padding to be in any particular format (except for the last byte, the length), opening itself to attacks by active network attackers. However, even though TLS is very strict about how its padding is formatted, it turns out that some TLS implementations omit to check the padding structure after decryption. Such implementations are vulnerable to the POODLE attack even with TLS.

The impact of this problem is similar to that of POODLE, with the attack being slightly easier to execute–no need to downgrade modern clients down to SSL 3 first, TLS 1.2 will do just fine. The main target are browsers, because the attacker must inject malicious JavaScript to initiate the attack. A successful attack will use about 256 requests to uncover one cookie character, or only 4096 requests for a 16-character cookie. This makes the attack quite practical.

According to our most recent SSL Pulse scan (which hasn’t been published yet), about 10% of the servers are vulnerable to the POODLE attack against TLS.

For more information, head to some of these web sites:

Adam Langley - The POODLE Bites Again
F5 - SOL15882: TLS1.x padding vulnerability CVE-2014-8730

I’ll keep this post up-to-date as new information becomes available.

SSL 3 is dead, killed by the POODLE attack

2014-10-15T00:00:00+01:00

Update (8 Dec 2012): Some TLS implementations are also vulnerable to the POODLE attack. More information in this follow-up blog post.

After more than a week of persistent rumours, yesterday (Oct 14) we finally learned about the new SSL 3 vulnerability everyone was afraid of. The so-called POODLE attack (CVE-2014-3566) is a problem in the CBC encryption scheme as implemented in the SSL 3 protocol. (Other protocols are not vulnerable because this area had been strengthened in TLS 1.0.) Conceptually, the vulnerability is very similar to the 2011 BEAST exploit. In order to successfully exploit POODLE the attacker must be able to inject malicious JavaScript into the victim's browser and also be able to observe and manipulate encrypted network traffic on the wire. As far as MITM attacks go, this one is complicated, but easier to execute than BEAST because it doesn't require any special browser plugins. If you care to learn the details, you can find them in the short paper or in Adam Langley's blog post.

SSL Labs Changes

We made three improvements to the SSL Labs web site to properly test and warn about the POODLE attack: 1) warnings about SSL 3 support and vulnerability to POODLE, 2) test for TLS_FALLBACK_SCSV and 3) new client test that detects support for SSL 3. At this time, a server vulnerable to the POODLE attack will be given a C grade, but we're likely to change this grading in the near future, after we carefully consider all our options.

What Now?

POODLE is a protocol-level vulnerability that can't be easily fixed. Although it might be possible to attempt a BEAST-style mitigation, it seems that browser vendors are not interested in that approach. Adam said Chrome won't pursue that direction. Firefox said they would disable SSL 3 in Firefox 34. And that's great news. Traditionally we struggle with letting go of old protocols. Because SSL 3 is not very widely used and POODLE is serious enough, it seems that we'll be able to retire this old protocol version soon. In fact, some CDNs have already disabled it.

What You Should do

You can look at this problem from two perspectives. As a user, you want to protect yourself from attacks, and the best way to do that is to disable SSL 3 in your browser. (Instructions are easy to find online.) The updated SSL Labs Client Test will tell you if your change was successful.

As a web site operator, you should disable SSL 3 on your servers as soon as possible. You need to do this even if you support the most recent TLS version because an active MITM attacker can force browsers to downgrade their connections all the way down to SSL 3, which can then be exploited. In normal operation, SSL 3 shouldn't needed by the vast majority of sites. Although it's likely that there's a long tail of clients that don't support anything better, Internet Explorer 6 on Windows XP is potentially the biggest user segment that still relies on SSL 3. Options are to guide users to manually enable TLS 1.0 (IE6 supports it, but not by default) or upgrade to other browsers. In the short term, it's possible to mitigate POODLE by avoiding using CBC suites with SSL 3, but that involves relying on a certain insecure stream cipher whose name no one wants to mention. I don't recommend this approach.

POODLE wouldn't be as serious without the ability of the active network attacker to downgrade modern browsers down to SSL 3. There's a solution to this problem, via the TLS_FALLBACK_SCSV indicator that must be supported by clients and servers in order to be effective. Google implemented this feature in February (in Chrome and in their web sites) and has been successfully using since. Mozilla says Firefox will support the indicator in early 2015. A new version of OpenSSL has just been released, which includes support for the SCSV. The support might be backported to various Linux distributions. For best results, support also needs to be added to other major browsers. Once that happens, the POODLE attack surface will be much smaller; it will affect only the users with older browsers.

For detailed guidance on how to disable SSL 3 in various servers and browsers, head to Scott Helme's blog post.

SHA1 deprecation: what you need to know

2014-09-09T00:00:00+01:00

The news is that SHA1, a very popular hashing function, is on the way out. Strictly speaking, this development is not new. The first signs of weaknesses in SHA1 appeared (almost) ten years ago. In 2012, some calculations showed how breaking SHA1 is becoming feasible for those who can afford it. In November 2013, Microsoft announced that they wouldn't be accepting SHA1 certificates after 2016.

However, we're in a bit of a panic now because Google followed up to say that they will soon start penalising sites that use SHA1 certificates that expire during 2016 and after. This is a major policy change that requires immediate action—according to SSL Pulse, only 15% sites use SHA256 certificates in September 2014.

What you should do

Before this most recent development, the advice was very simple: don't use SHA1 certificates past 2016. Google's decision complicates things: now it's no longer safe to use SHA1 (with Google Chrome) even during 2016. For some sites there won't be a satisfactory outcome no matter what they do: if they want to maintain an error-free presence with Chrome they might need to cut off some older clients. I'll detail these problems later in this post.

Here's what I recommend:

Read the recent announcement from Google to understand how the changes will be introduced. Within months, certificates that expire after 2016 will be affected. Relatively soon thereafter, further changes will be introduced that will impact the certificates that expire during 2016.
Ensure new certificate and their chains use SHA256; this is critical—if your new certificates are not guaranteed to be SHA256 then all your other efforts will be pointless. If you get this right, all SHA1 certificates that expire by the end of 2015 will be guaranteed to be ready for 2016 without further effort.

It's also necessary to check that the entire certificate chain is free of SHA1. It's not common, but there are cases where the leaf uses SHA256 but one of the intermediates uses SHA1. Don't worry if the root certificate uses SHA1; signatures on roots are not used (and Chrome won't warn about them).

Companies that use centralized certificate procurement should find this step straightforward. For others, well, perhaps this is a good opportunity to centralise further certificate issuance.
Inventory your existing certificates; this might be tricky, depending on your environment. Automated scanning is not only easy to do once, but can also be repeated regularly to ensure new SHA1 certificates are not introduced. There are companies that offer products for this; for example one of the QualysGuard modules does this automatically after scanning the entire company network.
Replace SHA1 certificates that expire after 2015; start with those used on your most important sites and those that expire after 2016. Those will be the worst affected by the proposed changes and might stop working in 2017. Then work your way back to replace the remaining certificates. This step is time consuming but shouldn't involve further direct costs because most CAs will reissue certificates for free. However, there are some special cases you might wish to consider:
- Older server platforms might not be able to support SHA256 certificates. For example, that's the case with Windows Server 2003. Thus, upgrading to a SHA256 certificate might require an upgrade or patching of the underlying platform.
- Some older clients don't support SHA256. Most general-purpose sites can upgrade to SHA256 and expect the users to upgrade, too, but large sites with diverse user bases might want to preserve SHA1 compatibility for as long as possible. In some cases that will be possible with dual-certificate deployment, described below.

What older clients don't support SHA256

Many older clients don't support SHA256, but the real question is which of those are relevant? The answer will vary depending on the site. For detailed information on client capabilities, head to GlobalSign, which maintains a detailed summary of SHA256 support for a large number of platforms.

On the desktop, Windows XP introduced SHA256 in Service Pack 3. Users running SP2 should be able to upgrade to SP3. Depending on a site's profile, a significant chunk of the user base might be running XP. This operating system is still very popular in China and there is also strong anecdotal evidence that it remains widely used in some large organizations.

Among the mobile platforms, Android added SHA256 support in version 2.3. Earlier versions—still used in large numbers—support only SHA1.

What if you need to support older clients?

Technically, it's possible to have the best of both worlds by providing SHA256 certificates to modern clients and serve SHA1 to those that can't do better. Indeed, there's nothing to say that a site can't use more than one certificate at the same time. This approach is ideal for transitions such as this one. At this time, a site could use two certificates: ECDSA+SHA256 for modern clients and RSA+SHA1 for older clients.

Unfortunately, this feature might not be available for your favourite platform. As far as I am aware, Apache is the only major server to support multiple certificates. If you're running Apache and are willing to play with dual certificate deployment, you're in luck. As for other platforms, CloudFlare and Yahoo have stated that they will add support to Nginx and Apache Traffic server, respectively.

What will SSL Labs do?

We are making some changes to our SHA1 reporting, split into two phases. In the short term, we will:

Treat SHA1 signatures as weak and warn about them.
Introduce three new warnings:
1. To ensure renewal with SHA256 when the current certificate expires, if the server is using SHA1 now and the expiration date is before the end of 2016.
2. To renew with SHA256 as soon as possible, if the server is using SHA1 now and the certificate expires after 2016.
3. To renew certificate or fix the chain if the leaf is SHA256 but one of the intermediates is SHA1.
Stop awarding A+ to sites that use SHA1 certificates.
Link to this advice for more information.

~~These changes have already been implemented and deployed on our staging server. They will be migrated to production in the following days.~~ These changes were deployed to production on 16 September. Our second step, which will come some time later, will involve a change to our rating criteria to penalize sites that continue to use SHA1.

Bulletproof SSL and TLS proofs on my desk

2014-08-12T00:00:00+01:00

Since the official release of Bulletproof SSL and TLS last Tuesday, we've been busy submitting the book to print and ensuring it comes out just right. As a result, I now have three proofs sitting on my desk in all their glory! All the other copies are now on their way to our warehouse, from where they will be shipped to you.

Bulletproof SSL and TLS has been released!

2014-08-05T00:00:00+01:00

It gives me great pleasure to announce that my book, Bulletproof SSL and TLS, has now been officially released. Writing it took me more than two years (I started in May 2012, believe it or not), during which I spent the equivalent of about 7 months of full time work.

The end result is about 528 pages of text (in print; 513 in the version optimised for screen reading) spread across 16 chapters. The book is a complete package with an introduction to cryptography, SSL, TLS, and PKI, followed by a complete coverage of the current problems with the protocols as well as the entire ecosystem, and a ton of practical advice for configuration and performance tuning. OpenSSL is well covered with two chapters, and there's a chapter for each of Apache, Java and Tomcat, Microsoft and IIS, and Nginx.

During July I went through the entire book to update and refresh the earlier chapters. I extended the OpenSSL chapter with a section on running private certification authorities. The Apache and Nginx chapters were extended to include client certificate authentication. Apache 2.4.10 introduced some changes to how it handles SNI and, naturally, I needed to include that in the book, too. I added Preface to the beginning and Summary to the end. Finally, I added the index, without which the print edition wouldn't be complete.

If you purchased the early access edition since we had announced it in February, now is a good time to go back to the Feisty Duck web site and download the final files. (Final for now, that is.) If you purchased the paper version, your book is currently being printed and will be shipped to you soon.

For more information about Bulletproof SSL and TLS, please visit the Feisty Duck web site:

https://www.feistyduck.com/books/bulletproof-ssl-and-tls/

Bulletproof SSL and TLS June Update: Cryptography, Protocol, and PKI

2014-06-24T00:00:00+01:00

I've just released the June update of Bulletproof SSL and TLS. This batch completes the manuscript and brings about 80 new pages across three chapters:

Chapter 1, SSL, TLS, and Cryptography, begins with a brief introduction to SSL and TLS and discusses where these secure protocols fit in the Internet infrastructure. The remainder of this chapter provides a basic introduction to cryptography and discusses the classic cryptography threat model.
Chapter 2, Protocol, discusses the TLS protocol in detail. I cover TLS 1.2, with mentions of differences in earlier versions where appropriate. An overview of the protocol evolution over the years is included at the end for your reference.
Chapter 3, Public-Key Cryptography, is an introduction to Internet PKI, which is the predominant trust model on the Internet today. The focus is on the standards and organizations, as well as governance, weaknesses, and possible future improvements.

The manuscript is now complete and has slightly over 500 pages. Previous chapters include:

Chapter 4, Attacks against PKI, deals with attacks on trust. It covers all the major CA compromises as well as some other ways to subvert TLS authentication on the Internet.
Chapter 5, HTTP and Browser Issues, is all about the relationship between HTTP and SSL, the problems arising from the organic growth of the Web, and the messy interactions between different pieces of the web ecosystem.
Chapter 6, Implementation Flaws, deals with issues arising from design and programming mistakes related to random number generation, certificate validation, and other key TLS and PKI functionality. Additionally, it discusses voluntary protocol downgrade and truncation attacks.
Chapter 7, Protocol Attacks, is the longest chapter in the book at 60 pages. It covers all major protocol flaws discovered in recent years: Insecure Renegotiation, BEAST, CRIME, Lucky 13, RC4, TIME and BREACH, Triple Handshake, and the Bullrun program.
Chapter 8, Deployment, is the map for the entire book and provides step by step instructions on how to deploy secure and well-performing TLS servers and web applications.
Chapter 9, Performance, focuses on the speed of TLS, providing more detail as well as additional performance improvement techniques for those who want to squeeze every bit of speed out of their servers.
Chapter 10, HSTS, CSP, and Pinning, covers some advanced topics that strengthen web applications, as well as pinning, which is a way of reducing the large attack surface imposed by our current PKI model.
Chapter 10, OpenSSL Cookbook, describes the most frequently used OpenSSL functionality, largely focusing on installation, configuration, and key and certificate management. This is the most polished chapter, given that it had been released as a standalone short book in May 2013, and then updated in October.
Chapter 11, Testing with OpenSSL, continues with OpenSSL and explains how to use its command-line tools to test server configuration. Even though it is often much easier to use an automated tool for testing (e.g., the SSL Labs Server Test), OpenSSL remains the de facto standard for troubleshooting.
Chapter 12, Configuring Apache, discusses the SSL configuration of Apache httpd.
Chapter 13, Configuring Java and Tomcat, covers the current versions of Java and Tomcat, and provides full coverage of the SSL/TLS capabilities of Java 7 and 8.
Chapter 14, Configuring Microsoft Windows and IIS, discusses the Microsoft Windows platform and the Internet Information Server.
Chapter 15, Configuring Nginx, discusses the Nginx web server, covering the features in the stable and development version equally.

In the next couple of weeks we'll be working the finishing touches and preparing the book for printing. After two years of writing, it's very exciting to be this close to the finish.

If you already have access to the book, here's the direct link to access the new content:

https://www.feistyduck.com/library/bulletproof/

If you don't have the access yet, Bulletproof SSL and TLS is available now for early access and preorder, at a 10% discount:

https://www.feistyduck.com/books/bulletproof-ssl-and-tls/

SSL Labs: New grades for trust (T) and mismatch (M) issues

2014-06-17T00:00:00+01:00

In the 1.10.x code branch of SSL Labs, which was deployed to production last week, we made a change in how we handle assessments with trust issues. Previously, all certificates that we couldn't validate (largely because they were self-signed or issued from a private CA root) were given an F grade. In this latest version, we introduced two new grades:

Trust issues (T); If we don't trust a certificate (and there aren't any other security issues), we assign it a T grade (for "trust)". This grade is thus used when the server is otherwise well-configured. Just below the T grade, we note the grade the server would get if the trust issues were resolved.
Name mismatch issues (M); In some cases, trust issues come from name mismatches and usually when a server doesn't actually use encryption. Such sites now get an M grade (for "mismatch").

I expect the introduction of these new grades is going to help our users better understand what's really going on.

SSL Pulse: 49% vulnerable to CVE-2014-0224, 14% exploitable

2014-06-13T00:00:00+01:00

Last week (on June 5th), OpenSSL published an advisory detailing a number of serious problems. The CVE-2014-0224 vulnerability will be the most problematic for most deployments because it can be exploited via an active network (man in the middle) attack.

This vulnerability allows an active network attacker to inject ChangeCipherSpec (CCS) messages to both sides of a connection and force them to fix their keys before all key material is available. Weak keys are negotiated as a result. If you're interested in the details, Adam Langley published a good technical analysis.

Although virtually all versions of OpenSSL are vulnerable, this problem is exploitable only if (1) both sides use OpenSSL and (2) the server uses a vulnerable version of OpenSSL from the 1.0.1 branch.

The good news is that most browsers don't rely on OpenSSL, which means that most browser users won't be affected. However, Android browsers do use OpenSSL and are vulnerable to this attack. Additionally, many command-line and similar programmatic tools use OpenSSL. A particularly interesting target will be various VPN products, provided they are based on OpenSSL (like, for example, OpenVPN).

Over at SSL Labs, we've been testing a remote check for CVE-2014-0224 since Friday. Satisfied that the test is identifying vulnerable hosts correctly, yesterday we ran a scan against the SSL Pulse dataset. The results are that about 49% servers are vulnerable. About 14% (of the total number) are exploitable because they're running a newer version of OpenSSL. The rest are probably not exploitable, but should be upgraded because it's possible that there are other ways to exploit this problem.

If you'd like to test your servers, the latest version of SSL Labs incorporates a check for CVE-2014-0224.

Bulletproof SSL and TLS May Update: Deployment and Performance

2014-05-20T00:00:00+01:00

I've just released the May update of Bulletproof SSL and TLS. This batch brings 78 pages and three chapters to the book:

Chapter 8, Deployment, is the map for the entire book and provides step by step instructions on how to deploy secure and well-performing TLS servers and web applications.
Chapter 9, Performance, focuses on the speed of TLS, providing more detail as well as additional performance improvement techniques for those who want to squeeze every bit of speed out of their servers.
Chapter 10, HSTS, CSP, and Pinning, covers some advanced topics that strengthen web applications, as well as pinning, which is a way of reducing the large attack surface imposed by our current PKI model.

In addition, improvements were made to existing chapters:

Chapter 7, Protocol Attacks, has been completely revised in response to the excellent technical reviews I received.
Heartbleed is now fully documented, with the main coverage in Chapter 6 and detailed testing instructions in Chapter 11.

Overall, book is currently at 420 pages. Previous chapters include:

Chapter 4, Attacks against PKI, deals with attacks on trust. It covers all the major CA compromises as well as some other ways to subvert TLS authentication on the Internet.
Chapter 5, HTTP and Browser Issues, is all about the relationship between HTTP and SSL, the problems arising from the organic growth of the Web, and the messy interactions between different pieces of the web ecosystem.
Chapter 6, Implementation Flaws, deals with issues arising from design and programming mistakes related to random number generation, certificate validation, and other key TLS and PKI functionality. Additionally, it discusses voluntary protocol downgrade and truncation attacks.
Chapter 7, Protocol Attacks, is the longest chapter in the book at 60 pages. It covers all major protocol flaws discovered in recent years: Insecure Renegotiation, BEAST, CRIME, Lucky 13, RC4, TIME and BREACH, Triple Handshake, and the Bullrun program.
Chapter 10, OpenSSL Cookbook, describes the most frequently used OpenSSL functionality, largely focusing on installation, configuration, and key and certificate management. This is the most polished chapter, given that it had been released as a standalone short book in May 2013, and then updated in October.
Chapter 11, Testing with OpenSSL, continues with OpenSSL and explains how to use its command-line tools to test server configuration. Even though it is often much easier to use an automated tool for testing (e.g., the SSL Labs Server Test), OpenSSL remains the de facto standard for troubleshooting.
Chapter 12, Configuring Apache, discusses the SSL configuration of Apache httpd.
Chapter 13, Configuring Java and Tomcat, covers the current versions of Java and Tomcat, and gives a glimpse of what's coming in Java 8. (Java 8 coverage will improve soon after Oracle makes the final release candidate available.)
Chapter 14, Configuring Microsoft Windows and IIS, discusses the Microsoft Windows platform and the Internet Information Server.
Chapter 15, Configuring Nginx, discusses the Nginx web server, covering the features in the stable and development version equally.

The book is now almost complete. The remaining chapters, which will be released in the next batch in June, will provide the necessary background in cryptography, SSL and TLS protocols, and PKI.

If you already have access to the book, here's the direct link to access the new content:

https://www.feistyduck.com/library/bulletproof/

If you don't have access yet, Bulletproof SSL and TLS is available now for early access and preorder, at a 20% discount:

https://www.feistyduck.com/books/bulletproof-ssl-and-tls/

SSL Labs test for the Heartbleed attack

2014-04-08T00:00:00+01:00

Heartbleed is a name for a critical vulnerability in OpenSSL, a very widely deployed SSL/TLS stack. A coding error had been made in the OpenSSL 1.0.1 code, which was subsequently released in March 2012. The vulnerability is in the rarely used heartbeat mechanism, specified in RFC 6520. The error allows an attacker to trick the server into disclosing a substantial chunk of memory, repeatedly. As you can imagine, process memory is likely to contain sensitive information, for example server private keys for encryption. If those are compromised, the security of the server goes down the drain, too.

Your server is probably vulnerable if it's running any version in the OpenSSL 1.0.1 branch. If you'd like to verify if you're vulnerable, today I released a new version of the SSL Labs Server Test. I went through a lot of effort to implement a test that doesn't attempt exploitation (no server data is retrieved). So it should be safe to use. Despite the availability of the test, if you can identify the library version number, I would urge to assume that you are vulnerable, even if the test is not showing a problem.

It's difficult to underestimate the impact of this problem. Although we can't conclusively say what exactly can leak in an attack, it's reasonable to assume that your private keys have been compromised. Addressing this issue requires at least three steps: 1) patch, 2) replace the key and certificate, and 3) revoke the old certificate. After that you will need to consider if any additional data might have been leaked too, and take steps to mitigate the leak.

Unless your server used Forward Secrecy (only about 7% do), it is also possible that any past traffic could be compromised, but only if you are faced with a powerful adversary who has means to record and store encrypted traffic. If you did not before Forward Secrecy before, now is a great time to ensure you do support it from now on. If this topic is new for you, you can follow my advice here and here.

For more details on the nature of this OpenSSL blog, have a look at this post from Matthew Green.

Bulletproof SSL and TLS April Update: Attacks and Weaknesses

2014-04-08T00:00:00+01:00

I've just released the April update of Bulletproof SSL and TLS. This batch concludes the part of the book that deals with attacks, vulnerabilities and weaknesses, both in the protocols and the PKI infrastructure. There's about 90 new pages, in three chapters:

Chapter 4, Attacks against PKI, deals with attacks on trust. It covers all the major CA compromises as well as some other ways to subvert TLS authentication on the Internet.
Chapter 5, HTTP and Browser Issues, is all about the relationship between HTTP and SSL, the problems arising from the organic growth of the Web, and the messy interactions between different pieces of the web ecosystem.
Chapter 6, Implementation Flaws, deals with issues arising from design and programming mistakes related to random number generation, certificate validation, and other key TLS and PKI functionality. Additionally, it discusses voluntary protocol downgrade and truncation attacks.

In addition, I updated the Protocol Attacks chapter released last month to include coverage of the Triple Handshake attack. In total, the book is currently at 350 pages. Previous chapters include:

Chapter 7, Protocol Attacks, is the longest chapter in the book at 60 pages. It covers all major protocol flaws discovered in recent years: Insecure Renegotiation, BEAST, CRIME, Lucky 13, RC4, TIME and BREACH, Triple Handshake, and the Bullrun program.
Chapter 10, OpenSSL Cookbook, describes the most frequently used OpenSSL functionality, largely focusing on installation, configuration, and key and certificate management. This is the most polished chapter, given that it had been released as a standalone short book in May 2013, and then updated in October.
Chapter 11, Testing with OpenSSL, continues with OpenSSL and explains how to use its command-line tools to test server configuration. Even though it is often much easier to use an automated tool for testing (e.g., the SSL Labs Server Test), OpenSSL remains the de facto standard for troubleshooting.
Chapter 12, Configuring Apache, discusses the SSL configuration of Apache httpd.
Chapter 13, Configuring Java and Tomcat, covers the current versions of Java and Tomcat, and gives a glimpse of what's coming in Java 8. (Java 8 coverage will improve soon after Oracle makes the final release candidate available.)
Chapter 14, Configuring Microsoft Windows and IIS, discusses the Microsoft Windows platform and the Internet Information Server.
Chapter 15, Configuring Nginx, discusses the Nginx web server, covering the features in the stable and development version equally.
Appendix, SSL/TLS Deployment Best Practices, serves as a temporary replacement for the yet-to-be-written Chapter 8, Deployment. It covers the same material and gives the same advice, only in fewer words.

If you already have access to the book, here's the direct link to access the new content:

https://www.feistyduck.com/library/bulletproof/

If you don't have access yet, Bulletproof SSL and TLS is available now for early access and preorder, at a 20% discount (down from 25% last month):

https://www.feistyduck.com/books/bulletproof-ssl-and-tls/

I hope you'll enjoy the new content!

HTTPS mixed content: still the easiest way to break SSL

2014-03-19T00:00:00+00:00

Mixed content issues arise when web sites deliver their pages over HTTPS, but allow some of the resources to be delivered in plaintext. The active network attacker can't do anything about the encrypted traffic, but messing with the plaintext can result with attacks ranging from phishing in the best case to full browser compromise in the worst. A single exposed script is sufficient: the attacker can hijack the connection and inject arbitrary attack payloads into it.

We tend to talk a lot about other aspects of SSL/TLS, but mixed content is arguably the easiest way to completely mess up your web site encryption.

In the very early days of the Web, all mixed content was allowed; web browsers expected site operators to think through the consequences of mixing content. That, of course, did not result with great security. Site operators did whatever they needed to get their work done and decrease costs. Only in recent years did browser vendors start to pay attention and start to restrict mixed content.

Mixed content in modern browsers

Today, almost all major browsers tend to break mixed content into two categories: passive for images, videos, and sound; and active for more dangerous resources, such as scripts. They tend to allow passive mixed content by default, but reject active content. This is clearly a compromise between breaking the Web and reasonable security.

Internet Explorer has been the leader in secure mixed content handling. As early as Internet Explorer 5 (according to this post), they had detection and prevention of insecure content by default. Chrome started blocking by default in 2011, and Firefox in 2013. The default Android browser and Safari, however, still allow all mixed content without any restrictions (and with almost non-existent warnings).

Here are the results of my recent testing of what insecure content is allowed by default:

Browser	Images	CSS	Scripts	XHR	WebSockets	Frames
Android browser 4.4.x	Yes	Yes	Yes	Yes	Yes	Yes
Chrome 33	Yes	No	No	Yes	Yes	No
Firefox 28	Yes	No	No	No	No	No
Internet Explorer 11	Yes	No	No	No	No	No
Safari 7	Yes	Yes	Yes	Yes	Yes	Yes

They are mostly as expecting, but there's a surprise with Chrome, which blocks active page content, but still allows plaintext XMLHttpRequest and WebSocket connections.

It's worth mentioning that the table does not tell us everything. For example, browsers tend not to control what their plugins do. Further, certain components (e.g., Flash or Java) are full environments in their own right, and there's little browsers can do to enforce security.

Testing for mixed content handling in SSL Labs

To make it easier to evaluate browser handling of this problem, I recently extended the SSL Labs Client Test to probe mixed content handling. When you visit the page, your user browser is tested, and you will get results similar to these:

Mixed content prevalence

Anecdotally, mixed content is very common. At Qualys, we investigated this problem in 2011, along with several other application-level issues that result with full breakage of encryption in web applications. We analysed the homepages of about 250,000 secure web sites from the Alexa top 1 million list, and determined that 22.41% of them used insecure content. If images are excluded, the number falls to 18.71%.

A more detailed study of 18,526 sites extracted from Alexa top 100,000 took place in 2013: A Dangerous Mix: Large-scale analysis of mixed-content websites (Chen et al.). For each site, up to 200 secure pages were analysed, arriving at a total of 481,656 pages. Their results indicate that up to 43% of web sites have mixed content issues.

Mitigation

The best defence against mixed content issues is simply not having this type of problem in your code. But that's easily said than done; there are many ways in which mixed content can creep up. When that fails, there are two technologies that can come useful:

HTTP Strict Transport Security (HSTS) is a mechanism that enforces secure resource retrieval, even in the face of user mistakes (attempting to access your web site on port 80) and implementation errors (your developers place an insecure link into a secure page). HSTS is one of the best thing that happened to TLS recently, but it works only on the hostnames you control.
Content Security Policy (CSP) can be used to block insecure resource retrieval from third-party web sites. It also has many other useful features for to address other application security issues, for example XSS.

Significant SSL/TLS improvements in Java 8

2014-03-11T00:00:00+00:00

The next generation of the Java runtime, version 8, is around the corner, with the first production release planned for this month (March 2014). The new runtime brings a slew of language improvements and it’s actually proving to be quite an exciting release.

If you ask me, Java 8 also brings many security improvements that are as important as the new language features. Of particular interest are the improvements to the TLS stack, implemented in the Java Secure Socket Extension (JSSE) component. Why? Because Java 7 and earlier do not give you enough control over TLS termination (details below). As a result, it was simply not possible to terminate TLS at the Java level and achieve sufficient security.

The deficiencies have been addressed in Java 8. Several other key improvements ensure that Java now provides a very good TLS stack. Many of the changes will take effect as you change the JRE, even with older applications. However, for some, we will have to wait (hopefully a short time) until programs take advantage of the new APIs.

Server Cipher Suite Preference

Java 8 allows TLS servers to decide which is the best suite to use from those supported by user agents. In earlier versions, the first supported suite is selected. The old behaviour is a serious problem because you can’t rely on user agents to do the right thing. For example, without server-side control, it’s not possible to deploy Forward Secrecy consistently, nor use some old suites (e.g., RC4 and 3DES) for backup purposes only. For me, the inability to control cipher suite order was always a showstopper, forcing me to terminate TLS elsewhere, for example at the Apache level.

To enable server cipher suite preference, use the SSLParameters.setUseCipherSuiteorder() method. Because of the API change, this feature will require application-level support. For Tomcat, you can track the progress here.

Strong Server Ephemeral Diffie-Hellman Parameters

Java 8 makes it possible to deploy TLS servers with strong ephemeral Diffie-Hellman parameters. In Java 7, DH parameters are hard-coded to 768 bits (excluding export suites, which use 512 bits, but such suites should not be used anyhow), and that's just plain insecure. To preserve security, when using TLS on Java 7 you must disable all DHE suites. As a result, you lose Forward Secrecy with some user agents that do not support ECDHE.

In Java 8, DHE parameters are set at 1024 bits by default, which is passable (considering each connection is independently protected), but not great. However, it’s possible to increase the strength to 2048 bits in configuration, by using the jdk.tls.ephemeralDHKeySize system property.

Authenticated (GCM) Suites

In the new version, JSSE supports authenticated (AEAD) GCM cipher suites, which is the best TLS can currently offer. This improvement is not as significant as the previous two, but ensures you can have best security in Java’s TLS stack. [JEP 115]

Hardware Acceleration on Intel and AMD processors

Starting with Java 8, the Java Runtime Environment (JRE) supports hardware acceleration of cryptographic operations when running on capable Intel and AMD processors. [JEP 164]

Server-Side SNI Support

Server support for the Server Name Extension (SNI), which allows for virtual SSL hosting, is finally available in Java 8. This feature allows hosting of multiple SSL sites on the same IP address (without having to share certificates). Virtual SSL hosting should become feasible soon, which means that this improvement comes at a very good time. (SNI support on the client side had been introduced in Java 7.) [JEP 114]

Ability to disable client-initiated renegotiation

Client-initiated renegotiation is a TLS protocol feature no one needs, yet it can sometimes be abused to make Denial of Service (DoS) easier. I prefer to disable this feature in order to reduce the attack surface. In Java 8, there is an undocumented system property jdk.tls.rejectClientInitiatedRenegotiation that controls client-initiated renegotiation.

TLS 1.2 enabled by default in client mode

Java added support for TLS 1.2 in version 7, but had it enabled by default only when in server mode; clients use TLS 1.0 as their best protocol by default. This is changing in Java 8, with TLS 1.2 now available without having to explicitly enable it.

Clients support Ephemeral DH over 1024 bits.

In Java 8, ephemeral DH parameters are no longer limited to 1024 bits when in client mode, as is the case in Java 7 and earlier versions. These days, 1024-bit DH parameters are considered weak and some operators prefer to increase DH strength to 2048 bits. The limit means that some Java clients are not able to negotiate any DHE suites with servers that use stronger parameters. (TLS has a design flaw in that it does not have a way for clients to advertise their DH capabilities.) This is not a big problem, given that you can use server-side preference to negotiate (the faster) ECDHE with Java clients, but it’s still nice to see the limit removed. Somewhat less positively, the new limit is 2048 bits.

Conclusion

With these changes, Java is again a viable platform for TLS termination. Not all necessary features are there, however. Notably absent is support for OCSP stapling, which can be used to give a performance boost to your TLS sites.

The other thing to be aware of is that the Java ecosystem has been slow to support SPDY, possibly because this protocol relies on TLS for bootstrapping and JSSE des not provide support for the Next Protocol Negotiation (NPN) extension. Two significant new protocols are currently being developed (HTTP/2.0 and TLS 1.3), and it will be interesting to see how quickly Java will adopt them.

For more information, visit the following links:

How to build your own test for Apple's TLS authentication bug

2014-03-10T00:00:00+00:00

A couple of weeks ago, I added a test for Apple's TLS authentication bug to SSL Labs. Some people have asked me how they can do that themselves, so that they can test for this problem in a private setting (e.g., their intranet).

First, you need to prepare a special version of OpenSSL. I had to understand the source code a bit to find the exact place, but you can just apply this 2-line patch to OpenSSL 1.0.1f.

Any program that relies on this broken OpenSSL version will work only on the Apple system that suffer from the TLS authentication vulnerability. I used the latest version of the Apache web server. To do the same, follow my instructions how to compile Apache with static OpenSSL libraries.

Finally, the Apache configuration should disable TLS 1.2 as well as all RSA suites, because they are not affected by this bug:

# Apple's TLS authentication bug affects only ECDHE
# and DHE suites, and protocols before TLS 1.2.
SSLProtocol -all SSLv3 TLSv1 TLSv1.1
SSLCipherSuite "EECDH EDH !aNULL !eNULL !EXP !MD5"

You should also configure a certificate the client will trust. Only broken clients will succeed with establishing connections to this web server. Thus, to complete the installation, you need a web page that explains the problem and how it can be addressed.

To make the testing user-friendly, you can place the test on some other web server, then test using JavaScript. All you need to do is attempt to retrieve a page from the broken web server: if that works, you know that the client is vulnerable. I used jQuery for this. Feel free to copy the code from the SSL Labs test.

For the cross-site requests to work, you'll need to further configure the broken web site to allow access from your test site:

Header set Access-Control-Allow-Origin https://www.ssllabs.com

And it's best to disable caching, so that the browser has to attempt to retrieve the file on every test:

Header set Cache-Control "no-cache, no-store, must-revalidate"
Header set Pragma no-cache
Header set Expires 0

Bulletproof SSL and TLS March Update: Protocol Attacks

2014-03-04T00:00:00+00:00

I've just released the March update of Bulletproof SSL and TLS. This batch is focused on protocol attacks. In about 50 pages, I cover the major problems discovered in recent years. In chronological order, they are:

Insecure renegotiation (2009)
BEAST (2011)
CRIME (2012)
Lucky 13 (2013)
RC4 Weaknesses (2013)
TIME (2013)
BREACH (2013)

This has been a fantastically interesting section to write because, as you're learning about the attacks, you are also learning about some finer details of the TLS protocol, and cryptographic engineering in general. To help with that, I included historical references to the relevant research papers, so you can track the problems from when they were first discovered.

At this point, the book is at about 250 pages. The next update will conclude the "problems" section, covering PKI attacks, implementation issues in libraries and operating systems, HTTP and browser issues. In addition, now that the Java 8 final release candidate is available, I will go through the (existing) Java chapter to document the confirmed new TLS features.

If you already have access to the book, here's the direct link to access the new content:

https://www.feistyduck.com/library/bulletproof/

If you don't have access yet, Bulletproof SSL and TLS is available now for early access and preorder, at a 25% discount:

https://www.feistyduck.com/books/bulletproof-ssl-and-tls/

Yesterday, as I was putting the finishing touches on the today's release, a new TLS protocol attack was published:

Triple Handshakes Considered Harmful:
Breaking and Fixing Authentication over TLS
https://secure-resumption.com

This is quite an interesting discovery if you're care about secure protocol design, but it's unlikely that you would be affected by the flaw. It might be an issue if you're using client certificates and support renegotiation. I will provide more information in subsequent updates.

Today, GnuTLS is in the news because they announced a serious vulnerability in the certificate validation code (CVE-2014-0092):

http://www.gnutls.org/security.html#GNUTLS-SA-2014-2

An attacker could use this flaw to impersonate any web site in a man in the middle attack. Further details are available in this Hacker News thread:

https://news.ycombinator.com/item?id=7338389

Two weeks ago (on 21 February), we learned that Apple had fixed a serious TLS connection authentication issue in iOS 6.x and 7.x, but left OS X users vulnerable. After a lot of pressure from unhappy users, Apple released 10.9.2 to deal with the vulnerability.

If you using any of the Apple operating systems, I advise that you upgrade as soon as possible. This problem is very easy to exploit and leaves no trace. I extended the SSL Labs Client Test to detect the vulnerability:

http://blog.ivanristic.com/2014/02/ssl-labs-test-for-apple-tls-auth-bug.html

Interestingly, the same OS X security update enabled the BEAST attack counter-measures by default in Mountain Lion (OS X 10.8.5).

SSL Labs: Testing for Apple's TLS authentication bug

2014-02-24T00:00:00+00:00

On Friday, Apple released patches for iOS 6.x and 7.x, addressing a mysterious bug that affected TLS authentication. Although no further details were made available, a large-scale bug hunt ensued. This post on Hacker News pointed to the problem, and Adam Langley followed up with a complete analysis.

I've just released an update for the SSL Labs Client Test, which enables you to test your user agents for this vulnerability.

This bug affects all applications that rely on Apple's SSL/TLS stack, which probably means most of them. Applications that carry with them their own TLS implementations (for example, Chrome and Firefox) are not vulnerable. For iOS, it's not clear when the bug had been introduced exactly. For OS X, it appears that only OS X 10.9 Mavericks is vulnerable.

What you should do:

iOS 6.x and 7.x: Patches are available, so you should update your devices immediately.
OS X 10.9.x: ~~Apple promised a fix would be available soon. Update as soon as it is released.~~ The vulnerability has been fixed in 10.9.2. Update immediately.

Update (10 March 2014): If you want to build your own test (e.g., to deploy on your intranet), I have published the instructions here.

Checking OCSP revocation using OpenSSL

2014-02-24T00:00:00+00:00

If an OCSP responder is malfunctioning, it is often difficult to understand why exactly. As is usually the case with SSL, the best approach is to use OpenSSL for troubleshooting. Checking certificate revocation status from the command line is possible, but not quite straightforward. You need to perform the following steps:

Obtain the certificate that you wish to check for revocation.
Obtain the issuing certificate.
Determine the URL of the OCSP responder.
Submit an OCSP request and observe the response.

For the first two steps, connect to the server with the -showcerts switch specified:

$ openssl s_client -connect www.feistyduck.com:443 -showcerts

The first certificate in the output will be the one belonging to the server. If the certificate chain is properly configured, the second certificate will be that of the issuer. To confirm, check that the issuer of the first certificate and the subject of the second match.

---
Certificate chain
 0 s:/1.3.6.1.4.1.311.60.2.1.3=GB/businessCategory=Private Organization/serialNumber=06694169/C=GB/ST=London/L=London/O=Feisty Duck Ltd/CN=www.feistyduck.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certificates.starfieldtech.com/repository/CN=Starfield Secure Certification Authority/serialNumber=10688435
-----BEGIN CERTIFICATE-----
MIIF5zCCBM+gAwIBAgIHBG9JXlv9vTANBgkqhkiG9w0BAQUFADCB3DELMAkGA1UE
[30 lines of text removed]
os5LW3PhHz8y9YFep2SV4c7+NrlZISHOZVzN
-----END CERTIFICATE-----
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certificates.starfieldtech.com/repository/CN=Starfield Secure Certification Authority/serialNumber=10688435
   i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
-----BEGIN CERTIFICATE-----
MIIFBzCCA++gAwIBAgICAgEwDQYJKoZIhvcNAQEFBQAwaDELMAkGA1UEBhMCVVMx
[...]

If the second certificate isn't the one, check the rest of the chain; some servers don't serve the chain in the correct order. If you can't find the issuer certificate in the chain, you will have to find it somewhere else. One way to do that is to look for the Authority Information Access extension in the leaf certificate:

$ openssl x509 -in fd.crt -noout -text
[...]
    Authority Information Access:
        OCSP - URI:http://ocsp.starfieldtech.com/
        CA Issuers - URI:http://certificates.starfieldtech.com/repository/sf_intermediate.crt
[...]

If the CA Issuers field is present, it should contain the URL of the issuer certificate. If the issuer certificate information isn't available, you can try to open the site in a browser, let it reconstruct the chain, and download the issuing certificate from its certificate viewer. If all that fails, you can look for the certificate in your trust store, or visit the CA's web site.

If you already have the certificates and just need to know the address of the OCSP responder, use the -ocsp_uri switch to the x509 command as a shortcut:

$ openssl x509 -in fd.crt -noout -ocsp_uri
http://ocsp.starfieldtech.com/

Now you can submit the OCSP request:

$ openssl ocsp -issuer issuer.crt -cert fd.crt -url http://ocsp.starfieldtech.com/ -CAfile
issuer.crt
WARNING: no nonce in response
Response verify OK
fd.crt: good
        This Update: Feb 18 17:59:10 2013 GMT
        Next Update: Feb 18 23:59:10 2013 GMT

You want to look for two things in the response. First, that the response itself is valid ("Response verify OK" in the previous example), and second, what the response said. When you see "good" as status, that means that the certificate has not been revoked. The status will be "revoked" for revoked certificates.

The warning message complaining about the missing nonce is telling you that OpenSSL wanted to use a nonce as a protection against replay attacks, but that the server in question did not reply with one. This generally happens because CAs want to improve the performance of their OCSP responders. When they disable the nonce protection (the standard allows it), OCSP responses can be produced once (usually in batch), then cached and reused for a period of time.

You may encounter OCSP responders that do not respond successfully to the previous command line. The following may help in such situations:

Do not request a nonce; Some servers cannot handle nonce requests, and respond with errors. OpenSSL will request a nonce by default. To disable nonces, use the -no_nonce command line switch.
Supply a Host request header; Although most OCSP servers occupy an entire IP address and respond to HTTP requests no matter the hostname, some don't. If you encounter an error message that includes a HTTP error code (e.g., 404), you should try supplying the correct hostname in your OCSP request. You can do this if you are using OpenSSL 1.0 and better, using the undocumented -header switch.

With the previous two points in mind, the final command to use is the following:

$ openssl ocsp -no_nonce -header Host ocsp.starfieldtech.com -issuer issuer.crt -cert fd.crt -url http://ocsp.starfieldtech.com/ -CAfile issuer.crt

Bulletproof SSL and TLS available for early access and preorder

2014-02-04T00:00:00+00:00

My next book, Bulletproof SSL and TLS, is now available for early access and preorder. I am thrilled to publish my latest work, even if it is not yet finished. Actually, because it is not yet finished. With early access to the manuscript, you get a chance to read the book straight away, and, perhaps more interestingly, you get to tell me what you'd like to see improved before the book is officially published. I, on the other hand, no longer have to write in isolation. So bring it on!

This book is taking me an awfully long time to write. Not only is the topic very complex, but it keeps changing. What was true last month is not necessarily true today. I lost count of how many times I had to go back and update a "finished" section in one chapter or another.

By now I've completed the largest of 3 book parts—Practical Configuration. The 6 large chapters in this part, together with the appendix, have about 200 pages, or (estimated) about 60% of the final book. More importantly, this part is largely self-sufficient: if you have to do any SSL configuration work today, this early release has all you need and covers all the major web platforms.

Here's what I have so far:

Chapter 10, OpenSSL Cookbook, describes the most frequently used OpenSSL functionality, largely focusing on installation, configuration, and key and certificate management. This is the most polished chapter, given that it had been released as a standalone short book in May 2013, and then updated in October.
Chapter 11, Testing with OpenSSL, continues with OpenSSL and explains how to use its command-line tools to test server configuration. Even though it is often much easier to use an automated tool for testing (e.g., the SSL Labs Server Test), OpenSSL remains the de facto standard for troubleshooting.
Chapter 12, Configuring Apache, discusses the SSL configuration of Apache httpd.
Chapter 13, Configuring Java and Tomcat, covers the current versions of Java and Tomcat, and gives a glimpse of what's coming in Java 8. (Java 8 coverage will improve soon after Oracle makes the final release candidate available.)
Chapter 14, Configuring Microsoft Windows and IIS, discusses the Microsoft Windows platform and the Internet Information Server.
Chapter 15, Configuring Nginx, discusses the Nginx web server, covering the features in the stable and development version equally.
Appendix, SSL/TLS Deployment Best Practices, serves as a temporary replacement for the yet-to-be-written Chapter 6, Deployment. It covers the same material and gives the same advice, only in fewer words.

The remaining chapters will be released as they are ready, at one- or two-week intervals, depending on the chapter. The plan is to complete the manuscript by mid-April, at which point the book will go to copyediting and then production. We are aiming to publish the first edition in June.

In terms of quality, the chapters have been through several revisions already. I usually write and then rewrite at least once, often twice. Further, most chapters have been through a technical review, which adds a revision or two. There hasn't been any copyediting yet. That will come at the end, after the entire manuscript is complete, but before the final production stages begin.

SSL Labs: Stricter security requirements for 2014

2014-01-21T00:00:00+00:00

Today, we're releasing a new version of SSL Rating Guide as well as a new version of SSL Test to go with it. Because the SSL/TLS and PKI ecosystem continues to move at a fast pace, we have to periodically evaluate our rating criteria to keep up.

We have made the following changes:

Support for TLS 1.2 is now required to get an A. If this protocol version is not supported, the grade is capped at B. Given that, according to SSL Pulse, TLS 1.2 is supported by only about 20% servers, we expect this change to affect a large number of assessments.
Keys below 2048 bits are now considered weak, with the grade capped at B.
Keys below 1024 bits are now considered insecure, and given an F.
MD5 certificate signatures are now considered insecure, and given an F.
We introduce two new grades, A+ and A-, to allow for finer grading. This change allows us to reduce the grade slightly, when we don't want to reduce it to a B, but we still want to show a difference. More interestingly, we can now reward exceptional configurations.
We also introduce a concept of warnings; a server with good configuration, but with one ore more warnings, is given a reduced grade A-.
Servers that do not support Forward Secrecy with our reference browsers are given a warning.
Servers that do not support secure renegotiation are given a warning.
Servers that use RC4 with TLS 1.1 or TLS 1.2 protocols are given a warning. This approach allows those who are still concerned about BEAST to use RC4 with TLS 1.0 and earlier protocols (supported by older clients), but we want them to use better ciphers with protocols that are not vulnerable to BEAST. Almost all modern clients now support TLS 1.2.
Servers with good configuration, no warnings, and good support for HTTP Strict Transport Security (long max-age is required), are given an A+.

I am very happy that our rating approach now takes into account some very important features, such as TLS 1.2, Forward Secrecy, and HSTS. Frankly, these changes have been overdue. We originally meant to have all of the above in a major update to the rating guide, but we ran out of time, and decided to implement many of the ideas in a patch release.

Apple enabled BEAST mitigations in OS X 10.9 Mavericks

2013-10-31T00:00:00+00:00

Last week, on October 22, Apple released OS X 10.9 Mavericks, the latest version of their desktop operating system. This was a very important update, given that Safari now, in version 7, supports TLS 1.2. We are slowly moving toward a world in which TLS 1.2 is widely supported. Still, I wanted more. I was hoping that this OS X release was also going to have BEAST mitigations enabled by default. After all, the code was already a part of the previous OS X release (Mountain Lion) and the compatibility risks are minimal given that all other major browser vendors enabled the 1/n-1 split in early 2012.

Going through the security release notes, I was excited to see the BEAST attack (CVE-2011-3389) mentioned, but the explanation of the fix was disappointing. It said:

This issue was addressed by enabling TLS 1.2.

The BEAST attack affects only TLS 1.0 and earlier protocols, but client-side support for TLS 1.2 is currently not sufficient as defence because (1) only about 20% of servers support this protocol version and (2) all major browsers are susceptible to protocol downgrade attacks, which can be carried out by active MITM attackers.

There was still hope that the release notes were incomplete and I didn't want to give up just yet. Given that Apple releases parts of their operating system as open source and that the code for 10.9 was already available, I thought that reading the source code would be a good starting point. And I knew where I should look, because I had previously examined the SSL stack of Mountain Lion.

Today, I was delighted to see that the code had been changed, and that the default setting had been changed from disabled to enabled, meaning that the SSL stack that ships with OS X 10.9 uses BEAST mitigations by default. To see for yourself, look for the first mention of defaultSplitDefaultValue in the source code. It's near the top of the file.

Just to be completely sure, I subsequently observed the 1/n-1 split in action using Safari 7 and Wireshark, against a server running TLS 1.0 with only a single CBC suite configured.

Enabling mitigations on Mountain Lion

If you're still running the previous OS X version and do not wish to upgrade at this time, you can manually enable the BEAST mitigations by executing the following command:

$ sudo defaults write /Library/Preferences/com.apple.security SSLWriteSplit -integer 2

At the very least, you will need to restart Safari; it's probably best to restart the computer. (Disclaimer: I don't have a Mountain Lion installation and have not tried this procedure for myself. I did try to disable the mitigation on Mavericks, but without success.)

BEAST has finally been mitigated client-side

With this, we can finally conclude that BEAST has been sufficiently mitigated client-side, and move on.

Update (11 Nov 2013): Even though the source code indicates that the migitation can be controlled, in practice that does not seem to be the case. It is possible that there is a bug in the CoreFoundation framework that prevents the code from reading the settings correctly. Replacing kCFPreferencesAnyHost with kCFPreferencesCurrentHost in the CFPreferencesCopyValue() invocation makes it work, but requires a one-byte patch to the relevant system library. This investigation is the work of Stefan Becker, who also reported the problem to Apple.

SSL Pulse now tracking Forward Secrecy and RC4

2013-10-09T00:00:00+01:00

In October we made several changes to how we produce our monthly SSL Pulse reports. They include starting tracking Forward Secrecy and RC4, and removing the requirement to mitigate BEAST server side.

Forward Secrecy

Given the increased importance of Forward Secrecy (FS) in SSL/TLS server configuration, SSL Pulse now tracks support for it among the servers in our data sample.

Just before the October SSL Pulse scan began, we made some tweaks to the way we test, moving away from a simple binary test (Yes or No for Forward Secrecy support) to something more granular and more useful. Now, there are several possible outcomes:

Not supported - there are no FS suites in the server configuration.
Some FS Suites enabled - the server negotiates FS with some browsers.
Used with modern browsers - all modern browsers negotiate a FS suite. This will typically happen with a server that has support for ECDHE suites.
Used with most browsers - most browsers negotiate a FS suite. This will typically happen with a server that supports ECDHE suites, but falls back to DHE for clients that do not support Elliptic Curve cryptography.

You can see the October results in the following screen capture:

The results show that a large chunk of the servers (54%) does not use Forward Secrecy with any of the desktop browsers. However, a pretty large chunk (41.8%) does use it with some of the browsers. Only a small number support Forward Secrecy with modern browsers (3.6%), and an even smaller number (0.6%) support robust Forward Secrecy across most browsers.

RC4

We took this opportunity to also start tracking support for RC4 suites. As you may remember, earlier this year we learned that RC4 is much weaker than previously thought. In SSL Labs we now categorise RC4 support as follows:

Not supported - no RC4 suites supported.
Some RC4 suites enabled - server configuration contains RC4 suites, but they might not be actually used. For example, some servers will keep them around to use as a last resort.
Used with modern browsers - RC4 is used with at least one modern browser. This shows the servers where RC4 is not used as backup.

And the results are as follows:

As you can see, the green area is very small; only 7.2% servers do not support RC4. This is not very surprising, as RC4 is one of the most popular ciphers in SSL. Most servers (56.3%) have at least one RC4 suite enabled, but they are not always used. But more than a third of servers (36.5%) actually use RC4 with at least one modern browser. This is the number we need to bring down.

BEAST

This month we stopped requiring server-side mitigation for the BEAST vulnerability. Even though BEAST can still be a problem for some (see this longer explanation in my earlier blog post), the impending threat of RC4 means that we must give up on BEAST so that we can start phasing RC4 out.

Given that we are not yet penalizing servers that support RC4, the change in our rating means that there is a much higher number of servers that we consider secure:

But, with more than 50% of the servers supporting RC4, the number of secure sites will most definitely fall again in the following months.

OpenSSL Cookbook v1.1 released

2013-10-08T00:00:00+01:00

OpenSSL Cookbook is a free ebook based around one chapter of my in-progress book Bulletproof SSL and TLS. The appendix contains the SSL/TLS Deployment Best Practices document (re-published with permission from Qualys). In total, there's about 50 pages of text that covers the OpenSSL essentials, starting with installation, then key and certificate management, and finally cipher suite configuration.

The first version of OpenSSL Cookbook was published in May, but now, five months after that release, I've released version 1.1. The changes in this version are as follows:

Updated SSL/TLS Deployment Best Practices to v1.3. This version brings several significant changes: 1) RC4 is deprecated, 2) the BEAST attack is considered mitigated server-side, 3) Forward Secrecy has been promoted to its own category. There are many other smaller improvements throughout.
Reworked the cipher suite configuration example to add Forward Security as a requirement, making the example more useful in practice.
Increased coverage of different key types with a discussion of ECDSA keys. Explained when each type is appropriate.
Added new text to explain how to generate DSA and ECDSA keys.
Explained the challenge password, when generating Certificate Signing Requests.
Marked cipher suite configuration keywords that were introduced only in the OpenSSL 1.x branch. This makes it easier to use the text for reference purposes, if you're still running the older, OpenSSL 0.9.x, version.

You can get your copy from here.

Introducing the SSL Client Test

2013-10-02T00:00:00+01:00

I am delighted to introduce the most recent addition to the SSL Labs web site, the SSL Client Test. For some reason, even though we released sslhaf, our passive client fingerprinting tool, back in 2009, our attention until now remained on server testing only.

Then, this year, there was a noticeable increase in the interest in computer security and browser capabilities specifically, which led many of our users to ask us to implemented a client test. We already had a page that displayed the capabilities of well known browsers (linked from the Handshake Simulator section); from there, it was really easy to show what your browser can do.

Behind the scenes we rely on sslhaf to extract the entire raw client handshake request and make it available to our application (implemented in Java). From there, we simply disassemble the available information and present it to the user.

With the client test, you are now able to see the SSL/TLS capabilities of your preferred browser simply by visiting the test page. And, because the SSL protocol is designed in such a way that clients always tell servers about their capabilities, the best part is that testing does not take much time. In fact, it's pretty much instantaneous.

Updated SSL/TLS Deployment Best Practices deprecates RC4

2013-09-17T00:00:00+01:00

We are releasing an update to our SSL/TLS Deployment Best Practices document, which is our comprehensive guide to running secure servers. This is our third update since the first release in February 2012; our main goal is to keep the document up to date with the threats as they're evolving.

Since the beginning of the year we saw three major developments:

In March, a group of security researchers demonstrated that RC4 is seriously broken. Although the attack is not yet very practical, we are now recommending that this cipher is phased out. In the previous versions of the guide we had recommended using RC4 to mitigate the BEAST attack server-side. Clearly, this is no longer possible. Although we think that the BEAST attack can still be a threat in some environments, disabling RC4 globally will take a long time and we believe that we need to start that process straight away.
Last year, we learned about the CRIME attack, which uses information leakage stemming from compression before encryption. This year, CRIME evolved into TIME and BREACH, two attacks that go beyond attacking TLS compression (which is easy to disable without consequences) to attack the ubiquitous HTTP compression. Because they fall outside SSL/TLS, TIME and BREACH can only be addressed by making changes to application source code. For most, this approach will require a lot of work.
Finally, this year we also learned some details about widespread surveillance programs worldwide. In particular, it came to light that server private key compromise is a commonly used approach to breaking secure communication. For this reason, we now recommend that all secure servers support Forward Secrecy. With this feature enabled, each connection uses separate encryption keys, which means that the encrypted data remains safe if the server private key is compromised.

In addition to addressing these major threat changes, we took the opportunity to include several incremental updates, for example to recommend that you retire 1024-bit keys, SSL 3, and 3DES. We also included a discussion about new technologies, such as ECDSA keys.

Download SSL/TLS Deployment Best Practices v1.3 from the SSL Labs web site.

Is BEAST still a threat?

2013-09-10T00:00:00+01:00

Yesterday I changed the SSL Labs rating criteria to stop penalizing sites that do not implement server-side mitigations for the BEAST attack. That means that we now consider this attack sufficiently mitigated client-side, but, there are still some things you should now.

What is BEAST?

TLS 1.0 and earlier protocols suffer from a serious flaw: the Initialization Vector (IV) blocks that are used to mask data (plaintext) prior to encryption with a block cipher can be predicted by an active man-in-the-middle (MITM) attacker. IVs are used to prevent encryption from being deterministic; without them, every time you encrypt the same block of data with the same key, you get the same (encrypted) output. This is highly undesirable. A clever attacker who can 1) predict IVs, 2) see what encrypted data looks like, and 3) influence what is encrypted, is then able to make guesses about what plaintext looks like. Technically, he cannot decrypt any data, but he can find out if his guesses are right or wrong. With enough guesses, any amount of data can be uncovered.

This is a highly condensed explanation of the problem. If you care about the details, I suggest that you start with my previous post on this topic, and follow the links provided there.

Because guessing is not very efficient, the BEAST attack can in practice used to retrieve only small data fragments. That might not sound very useful, but we do have many highly valuable fragments all over: HTTP session cookies, authentication credentials (many protocols, not just HTTP), URL-based session tokens, and so on. Therefore, BEAST is a serious problem.

Mitigation status

BEAST is purely a client-side vulnerability. Since it had been released to the public, most major browsers addressed it using a technique called 1/n-1 split. This technique stops the attacker from predicting IVs and effectively addresses the underlying problem.

But one platform held back—Apple's. We know little about their intentions, because there hasn't been any official communication on this topic. My understanding is that the 1/n-1 split was incorporated in the Mountain Lion release, but that it is disabled by default. Also, as far as I am aware, the split is not in use on iOS either.

Without Apple addressing the BEAST attack, there's a substantial chunk of users that are still potentially vulnerable. For this reason, at the beginning of this year, SSL Labs started penalizing all sites that do not incorporate server-side mitigations against the attack.

Unfortunately, the only way to mitigate the BEAST attack is to enforce the use of RC4 suites whenever TLS 1.0 and earlier protocols are used (which is most of the time at this point). I say "unfortunately", because very shortly after we had started requiring server-side mitigations, new research about RC4 came out and we found out that this cipher was much weaker than previously thought. The weaknesses were not of immediate concern, but it was clear that RC4 was on the way out.

The situation became uncomfortable because we couldn't solve both problems, but also because both issues were of roughly the same risk. (Low.) Still, the end result was clear: RC4 affects everyone and cannot be mitigated; BEAST affects only a part of the user base and there isn't a workable exploitation path for it any more (we hoped). In addition, we knew that attacks against RC4 were going to get better; and that the attack surface vulnerable to BEAST likely to get smaller.

Is BEAST still a threat?

From this conclusion, the work that remained was to prove that the exploitation path used by BEAST was genuinely closed. We had no reliable information about that, and so I set out to test a bunch of browsers running on various platforms, read source code where available, and attempt to exploit BEAST myself.

The research required a lot of effort and time, mostly because I did not want just to run the existing exploit; I wanted to fully understand the attack as well as explore other potential attack vectors. Juliano and Thai (BEAST authors) have been very helpful answering my questions about their choices. I had detours, some because of real problems, some because of my mistakes. For a long time I thought BEAST was still exploitable because, to my great surprise, I discovered that the Same-Origin Policy (SOP) bypass that was used for BEAST still existed. Apparently, the fix for that problem was botched. Using this bypass, a MITM can still use a Java applet to instrument a victim's browser to encrypt arbitrary plaintext and send it to arbitrary hosts.

Fortunately, there have been many changes to how applets work since BEAST was originally discovered. For example, there are now always warnings before an applet is started. In my testing, the Java plug-in had no ability to access HttpOnly cookies; it couldn't even send them in a request, or receive any of them back. Most importantly, HTTPS request made by applets are encrypted using Java's TLS stack, not that of the host browser. Because Java does implement the 1/n-1 split, BEAST cannot be exploited.

Epilogue

Even though SSL Labs no longer penalizes sites that do not implement server-side BEAST mitigation, the problem remains for as long as we have a major browser without the fix. Although I don't believe that the problem is exploitable today, there might be other attack vectors we are not aware of. A new feature added to Safari could make it exploitable again tomorrow. Or, someone with more time on their hands could prove me wrong. For this reason, we need a healthy security margin, and we need Safari to implement the 1/n-1 split by default.

By the way, supporting TLS 1.1 and 1.2 does not actually address BEAST now or in the near future, even though these protocols do not have the predictable IV weakness that's exploited by the attack. The first problem is that most of the Internet still relies on TLS 1.0. Only about 18% of the servers tracked in SSL Pulse support TLS 1.2 today. Thus, even though the next generation of web browsers will all support TLS 1.2, it's going to take a while until the servers are upgraded.

But there is also the second issue, which is that all major browsers are susceptible to protocol downgrade attacks; an active MITM can simulate failure conditions and force all browsers to back off from attempting to negotiate TLS 1.2, making them fall back all the way down to SSL 3. At that point, the predictable IV design is again a problem. Until the protocol downgrade weakness is fixed, newer protocols are going to be useful only against passive attackers, but not against the active ones.

Update (31 Oct): Apple finally enabled BEAST mitigations by default in OS X 10.9 Mavericks. Read more about it in my follow-up blog post.

Increasing DHE strength on Apache 2.4.x

2013-08-15T00:00:00+01:00

Update (13 May 2015): Apache 2.2.30 (not yet released at the time of writing) will also support configurable DH parameter strength, in the same way Apache 2.4.x does.

Update (26 Nov 2013): Apache 2.4.7, released today, has been improved to automatically select appropriate DH parameters, using the strength of the server key as guidance. Thus, there is no need to modify the source code any more. The improvements are explained in the CHANGES file, and in the SSLCertificateFile documentation.

Update (18 Oct 2013): Since I wrote this post, Apache improved DH parameter handling. The trunk version now automatically selects appropriate DH parameter strength based on the strength of the private key. The bug report now includes a backport to 2.4.x.

Some users of older versions of the Apache web server, who are trying to get their Forward Secrecy configuration just right usually run into a brick wall when they determine that Apache won't use Diffie-Hellman parameters stronger than 1024 bits. ~~This is because Apache leaves the business of DH configuration to OpenSSL, and 1024 bits is just what you get by default (for the stronger suites; the weaker ones use 512 bits).~~

Other web servers expose configuration options that allow you to increase the DH strength, but Apache does not. But, if you went through the hassle of installing Apache from source code (as I described in my previous blog post), there's an easy fix for this problem. Apache Software Foundation's bug #49559 ("Patch to add user-specified Diffie-Hellman parameters") contains a patch that introduces a new configuration directive, called SSLDHParametersFile, that adds the missing functionality to Apache httpd 2.4.x.

The bug is more than 3 years old, even though the code seems straightforward. The latest version of the patch was made against httpd 2.4.2, just over a year ago. I've tested it against httpd 2.4.6, and, with a hiccup, it appears to work as advertised.

The hiccup is that the patch won't compile as-is; a trivial change is required. If you're a programmer, you'll have no problem understanding the error and finding the fix from looking at the rest of the mod_ssl code. And if you don't want to do even that, you can download my version. (Disclaimer: I just made it compile, but didn't otherwise read or review the code. Use at your own risk.)

Assuming the starting point is the pristine source code tree of httpd 2.4.6, apply the patch like this:

$ cd httpd-2.4.6
$ patch -p1 < /path/to/patch-49559-for-2.4.6.diff
patching file modules/ssl/mod_ssl.c
patching file modules/ssl/ssl_engine_config.c
Hunk #2 succeeded at 189 (offset 6 lines).
Hunk #3 succeeded at 318 (offset 15 lines).
Hunk #4 succeeded at 801 (offset 36 lines).
patching file modules/ssl/ssl_engine_init.c
Hunk #1 succeeded at 994 (offset 44 lines).
Hunk #2 succeeded at 1192 (offset -1 lines).
Hunk #3 succeeded at 1205 (offset -1 lines).
Hunk #4 succeeded at 1769 (offset 20 lines).
patching file modules/ssl/ssl_engine_pphrase.c
patching file modules/ssl/ssl_private.h
Hunk #2 succeeded at 546 (offset 18 lines).
Hunk #3 succeeded at 573 (offset 18 lines).
Hunk #4 succeeded at 744 (offset 28 lines).
patching file modules/ssl/ssl_util_ssl.c
patching file modules/ssl/ssl_util_ssl.h

From here, compile and install as usually.

To use stronger DH parameters, you first need to create a special parameter file with the desired strength:

$ openssl dhparam -out dh2048.pem 2048

The process will take some time and you'll see lots of output on your screen. (If you're curious what the various characters mean, have a look here.) Then you need to add this directive to your Apache configuration:

SSLDHParametersFile /path/to/dh2048.pem

That's all. Now you only need to restart the web server and test it using the SSL Labs test.

Update (15 Aug 2013): As Michael Reschly reminded me, increasing DH strength can cause interoperability issues. In particular, Java is known not to support DH parameters above 1024 bits. Here's a Stack Overflow thread that contains more information. The issue has been resolved in the (not yet released) Java 8.

Update (19 Aug 2013): Ryan Hurst also wanted me to tell you that Windows crypto libraries don't support DH parameters stronger than 1024 bits. (Windows 8.1 might appears to actually support stronger DHE keys.) The only browser that could be affected by this is Internet Explorer. Other browsers running on Windows use their own crypto, and do not have this limitation. But even with IE users—as Reschly pointed out via Twitter—the DH limitation should not be a problem, for two reasons. First, if you configure Forward Secrecy correctly using ECDHE suites (as I discussed in my previous post), IE will always use ECDHE. Second, IE does not support DHE in combination with RSA, and will never negotiate a DHE suite, anyway.

Update (13 May 2015): The original post incorrectly stated that Apache supported only 1024-bit DH parameters because it delegated DH parameter handling to OpenSSL. That is incorrect. The limit was in the Apache code. Thanks to Richard Moore for pointing this out.

Defending against the BREACH attack

2013-08-07T00:00:00+01:00

When Juliano and Thai disclosed the CRIME attack last year, it was clear that the same attack technique could be applied to any other compressed data, and compressed response bodies (via HTTP compression) in particular. But it was also clear that—with our exploit-driven culture—browser vendors were not going to do anything about.

Progress will be made now that there is an exploit to worry about because, this year at Black Hat, a group of researched presented BREACH, a variant of CRIME that works exactly where it hurts the most, on HTTP response bodies. If you're not already familiar with the attack I suggest that you go to the researchers' web site, where they have a very nice paper and a set of slides.

If you don't want to read the paper right this moment, I will remind you that the CRIME attack works by having the attacker guess some secret text. The trick is to include the guess in the same context as the actual secret (for example, the same response body). When his guess is 100% wrong, the size of the response increases for the size of the guess. But, when the guess is correct (fully, or partially, meaning there is some overlap between the guess and the secret), compression kicks in, and the response body shrinks slightly. With enough guesses and enough time, you can guess anything on the page.

TLS does not defend against this attack because, when the protocol was originally designed, it was impossible for MITM attackers to submit arbitrary plaintext via victims' browsers. Since then, the threat model evolved, but the protocols remained the same. (Interestingly, there is a draft proposal to deal with this sort of thing at the TLS level: Length Hiding Padding for the Transport Layer Security Protocol.)

Mitigation

Clearly, one option is to address the problem at the TLS level; but that will take some time.

Outside TLS, the paper itself includes a nice list of mitigation options, and, with exceptions, I am not going to repeat them here. In general, it's not going to be easy. When dealing with CRIME, we were fortunate because few people knew TLS compression existed, and only a small number of browsers/users actually supported it. This time, the flaw is exploited in a feature that's not only very widely used, but one which many sites cannot exist without. Just try convincing a large site to turn off compression, at a large financial and performance cost.

Although most discussions about BREACH will no doubt focus on its threat against CSRF tokens, we should understand that the impact is potentially wider. Any sensitive data contained in responses is under threat. The good news is that session tokens don't appear to be exposed. However, a well-placed forged CSRF request can do a lot of damage.

CSRF token defence

For CSRF tokens there is a simple and effective defence, which is to randomize the token by masking it with a different (random) value on every response. The masking does not hide the token (whoever has the token can easily reverse the masking), but it does defeat the attack technique. Guessing is impossible when the secret is changing all the time. Thus, we can expect that most frameworks will adopt this technique. Those who rely on frameworks will only need to upgrade to take advantage of the defence. Those who don't will have to fix their code.

HTTP chunked encoding mitigation

The award for least-intrusive and entirely painless mitigation proposal goes to Paul Querna who, on the httpd-dev mailing list, proposed to use the HTTP chunked encoding to randomize response length. Chunked encoding is a HTTP feature that is typically used when the size of the response body is not known in advance; only the size of the next chunk is known. Because chunks carry some additional information, they affect the size of the response, but not the content. By forcing more chunks than necessary, for example, you can increase the length of the response. To the attacker, who can see only the size of the response body, but not anything else, the chunks are invisible. (Assuming they're not sent in individual TCP packets or TLS records, of course.)

This mitigation technique is very easy to implement at the web server level, which makes it the least expensive option. There is only a question about its effectiveness. No one has done the maths yet, but most seem to agree that response length randomization slows down the attacker, but does not prevent the attack entirely. But, if the attack can be slowed down significantly, perhaps it will be as good as prevented.

Referer check mitigation

A quick, dirty, tricky, and a potentially unreliable mitigation approach you can apply today, is to perform Referer header checks on all incoming requests. Because the attacker cannot inject requests from the web site itself (unless he gains access via XSS, in which case he owns the browser and has no need for further attacks), he must do so from some other web site (a malicious web site, or an innocent site hijacked from a MITM location). In that case, the referrer information will show the request originating from that other web site, and we can easily detect that.

Now, you can't just drop such requests (because then no links to your web site would work any more), but you can drop all the cookies before they reach the application. Without the cookies, your application will not resume the victim's session, and won't place anything secret in the response. Attack mitigated.

There is a catch, however (as Hubert pointed out to me this morning): if your web site relies on being framed by arbitrary 3rd party web sites, or if it exposes public services to others (for browser consumption), then you can't use this defence. I am assuming your services need the cookies. If they do not, you're back in the game. If you do decide to try it, please test your major use cases in a staging environment first.

You can implement this defence with only two Apache directives (replace www.example.com with your own domain name):

SetEnvIfNoCase Referer ^https://www\.example\.com keep_cookies
RequestHeader unset Cookie env=!keep_cookies

The cookies are kept only for requests arriving from the same site. There's a potential problem with users that follow links from other sites and bookmarks and expect to be logged in straight away (either because they are already logged in, or because your site supports auto-log in). For such users you might need to have a welcome page, where you will ask them to click on a link to enter the web site. The cookies will be sent again on the next request.

Just to be clear, there is a long history of attacks focusing on spoofing the Referer header. For example, there was one such problem in Chrome just recently. However, such attacks are addressed quickly after discovery. Further, as Krzysztof Kotowicz pointed out, it is trivial to submit requests that do not contain the Referer header (read about it here and here).

To conclude, I can't really say that I like this approach, but its huge advantage is that you can deploy it very quickly at the web server or reverse proxy level, without having to make any changes to the application code. Even with all the constraints, I imagine there will be a large number of applications for which the trade-offs will be acceptable.

We should really fix browsers

I would really like to see this problem addressed where it should be addressed—at the browser level. At the moment, a MITM attacker can intercept your non-encrypted requests, mess with them, and trick your browser into sending requests with arbitrary content to the sites that you care about. It's this interaction that's making several very interesting attacks possible: BEAST, CRIME, RC4, and now BREACH.

A carefully designed opt-in security measure could do the trick, but I suppose it would take a lot of talking and politics to get it implemented. The idea is that a web site can control which other web sites (cross-origins) can initiate requests to it, even if it is via <script> and <img> tags.

Incidentally, just a couple of days ago, Mike Shema and Vaagn Toukharian (fellow Qualys employees), proposed a new cookie control (update: and there is now a follow-up post from Mike) that would restrict when cookies are sent. Their intention was to deal with CSRF, but the measure would work against BREACH, too. If a 3rd party web site initiates a request to your web site, against your wishes, being able to tell the browser to drop the cookies would mitigate the potential attacks.

Update (8 August 2013): The first version of this blog post included a referrer check defence that allowed empty referrers, with the idea to support auto-log in for the users following bookmarks. But then Krzysztof Kotowicz pointed out that the Referer header can be removed by the attackers. I have now modified the example to drop cookies on all requests not originating from the web site.

Update (14 October 2013): A better idea for mitigation based on referrer checking is to selectively disable compression, rather than drop cookies. This approach comes with a slight performance penalty, but no loss of functionality. Read the original discussion thread for more information how to achieve this with Apache.

Configuring Apache, Nginx, and OpenSSL for Forward Secrecy

2013-08-05T00:00:00+01:00

In my earlier blog post, I gave an overview of Forward Secrecy, as well as some configuration tips. If you're new to the concept, I suggest that you go and read that post first. This time, I am following up with detailed configuration examples for Apache, Nginx, and OpenSSL.

Software Requirements

To deploy Forward Secrecy, you need to have both your web server and the underlying SSL/TLS library support Elliptic Curve (EC) cryptography. For Apache, Nginx, and OpenSSL, the following minimum versions will suffice:

OpenSSL 1.0.1c+
Apache 2.4.x+
nginx 1.0.6+ and 1.1.0+

You will probably want to upgrade to the most recent versions wherever possible, because you don't want to be running old and obsolete and potentially vulnerable software. If your distribution does not support an acceptable version of one of the components, consider installing everything from scratch, as I described in a recent blog post.

You are probably aware that Linux distributions often ship modified packages. The modifications are usually improvements, but could mean feature removal in some cases. For example, Red Hat appears to have no support for Elliptic Curve crypto on their operating systems, because of patent issues. If you're running CentOS, for example, and wish to support Forward Secrecy, you will need to recompile the key packages to put EC support back in. (There appear to be plenty tutorials on the Web for this.)

Once the correct packages are in place, enabling Forward Secrecy requires two steps:

Configure the web server to actively select suites
Activate the correct OpenSSL suite configuration string

The following configuration advice applies only if you are using compatible software components, as described in the previous section. It is not possible to support Forward Secrecy otherwise.

Apache

To configure Apache, you need to have the following lines in your configuration:

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

Nginx

To configure Nginx, you need to have the following lines in your configuration:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

RC4 versus BEAST

Today, only TLS 1.2 with GCM suites offer fully robust security. All other suites suffer from one problem or another (e.g, RC4, Lucky 13, BEAST), but most are difficult to exploit in practice. Because GCM suites are not yet widely supported, most communication today is carried out using one of the slightly flawed cipher suites. It is not possible to do better if you're running a public web site.

The one choice you can make today is whether to prioritize RC4 in most cases. If you do, you will be safe against the BEAST attack, but vulnerable to the RC4 attacks. On the other hand, if you remove RC4, you will be vulnerable against BEAST, but the risk is quite small. Given that both issues are relatively small, the choice isn't clear.

However, the trend is clear. Over time, RC4 attacks are going to get better, and the number of users vulnerable to the BEAST attack is going to get smaller.

Configuring OpenSSL (with RC4)

This configuration assumes you wish to deploy best-possible configuration supporting Forward Secrecy, and that you have a preference for GCM suites (resistant to timing attacks) and RC4 (resistant to BEAST). To achieve best performance, the faster ECDHE suites are used whenever possible.

EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS

To see what suites the above configuration string uses, invoke the following command (all one line):

$ openssl ciphers -V 'EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA256 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EDH+aRSA EECDH RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS'

The output will be similar to this:

ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

If you deploy your configuration, your SSL Labs test results might look like this.

Notes:

The list begins with a number of strong TLS 1.2 suites (GCM, SHA256, and SHA384); this helps avoid RC4 whenever possible.
ECDSA suites are preferred to the RSA ones, giving you a performance edge in a dual-certificate deployment scenario.
The main 2 suites (for the current browsers, most of which do not support TLS 1.2) are ECDHE-RSA-RC4-SHA and ECDHE-ECDSA-RC4-SHA, used for RSA and ECDSA certificates, respectively.
The DHE suites are there to support those rare browsers that do not support ECDHE. (Opera before version 15 is one such browser. Firefox as shipped on Red Hat systems another.) These suites are slower, but the majority of browsers will offer the faster ECDHE.
The RC4-SHA suite at the end is there to support IE8 running on Windows XP. (And possibly IE6, but I have not tested for it.)

Issues:

Internet Explorer, in all versions, does not support the ECDHE and RC4 combination (which has the benefit of supporting Forward Secrecy and being resistant to BEAST). But IE has long patched the BEAST vulnerability and so we shouldn't worry about it.
Same comment as above for Firefox on Red Hat systems.
It is impossible to support Forward Secrecy for IE8 running on Windows XP, because this browser does not support the necessary suites. The same is probably true for any IE version running on Windows XP. If you'd rather not handshake with such browsers, add !RC4-SHA to the configuration.

Configuring OpenSSL (without RC4)

If you prefer not to use RC4, use the same configuration string (for simplicity), but add !RC4 to the end:

EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4

Alternatively (in order to support a very wide range of browsers, including the IE versions running on Windows XP), you could deploy with RC4 enabled, but used only as a last resort:

EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS +RC4 RC4

Final Remarks

Finally, consider the following:

There's a vast number of SSL/TLS clients in deployment, each potentially supporting a unique list of cipher suites. It is impossible to guarantee consistent results across such a large user base.
The Handshake Simulation feature of the SSL Labs test is of great help when choosing cipher suite configuration. It supports a wide range of desktop browsers (including older versions). However, do note that the support for mobile devices is not very good at the moment.
Configuring OpenSSL can be tricky. I recommend reading the (free) OpenSSL Cookbook, which describes the configuration in detail.

Update (21 August): I have tweaked the suite configuration string to position SHA256 and SHA384 suites (which are TLS 1.2-only) after GCM suites and before RC4 suites. This helps avoid RC4 whenever possible. (This matters now because Google Chrome 29 has just been released, and, for the first time, we have a desktop browser that supports TLS 1.2 by default). Of course, I assume that you have upgraded your OpenSSL to 1.0.1d or better in order to fix the timing issues with CBC suites (the so-called Lucky 13 attack).

Compiling Apache with static OpenSSL libraries

2013-08-03T00:00:00+01:00

Back in 2004, when I was writing Apache Security, it was quite common to install Apache from source code, and I spent a lot of time documenting the process. When the stabilized most people stopped bothering with the source code and relied on the binaries provided by the operating system.

We're back into unstable territories. Today, to get the best SSL/TLS configuration you have to roll your sleeves and do everything the old way. For example, I have a couple of servers running Ubuntu 10.04 LTS; the OpenSSL version installed does not support TLS 1.2, and its Apache 2.2.x does not support the ECDHE suites (which are necessary for Forward Secrecy). If you're running an operating that originated at Red Hat, I hear that you don't get any Elliptic Curve crypto from the default binaries.

The easiest way to run Apache with a recent version of OpenSSL is to compile the crypto code statically, and install everything into a separate location. That way you achieve the goal, but you don't mess with the rest of the operating system.

First, you should get the desired version of OpenSSL and install it at a location where it will not interfere with your system version. I usually choose /opt for this purpose.

$ ./config \
    --prefix=/opt/openssl-1.0.1e \
    --openssldir=/opt/openssl-1.0.1e
$ make
$ sudo make install

Now, get the latest Apache 2.4.x, APR and APR-Util libraries. You will need to unpack all three packages into the same source tree, with the latter two in the location where Apache expects them. For example:

$ tar zxvf httpd-2.4.6.tar.gz
$ cd httpd-2.4.6/srclib/
$ tar zxvf ../../apr-1.4.8.tar.gz
$ ln -s apr-1.4.8/ apr
$ tar zxvf ../../apr-util-1.5.2.tar.gz
$ ln -s apr-util-1.5.2/ apr-util

You are now ready to configure and install Apache. The mod_ssl module will be compiled statically, with all other modules dynamically.

$ ./configure \
    --prefix=/opt/httpd \
    --with-included-apr \
    --enable-ssl \
    --with-ssl=/opt/openssl-1.0.1e \
    --enable-ssl-staticlib-deps \
    --enable-mods-static=ssl
$ make
$ sudo make install

Deploying Forward Secrecy

2013-06-25T00:00:00+01:00

Update (5 August 2013): In my follow-up post, I discuss how to configure Apache, Nginx, and OpenSSL to support Forward Secrecy.

With revelations about mass surveillance in the news everywhere, an obscure feature of SSL/TLS called Forward Secrecy has suddenly become very interesting. So what is it, and why is it so interesting now?

Session keys generation and exchange

Every SSL connection begins with a handshake, during which the parties communicate their capabilities to the other side, perform authentication, and agree on their session keys, in the process called key exchange. The session keys are used for a limited time and deleted afterwards. The goal of the key exchange phase is to enable the two parties to negotiate the keys securely, in other words, to prevent anyone else from learning these keys.

Several key exchange mechanisms exist, but, at the moment, by far the most commonly used one is based on RSA, where the server's private key is used to protect the session keys. This is an efficient key exchange approach, but it has an important side-effect: anyone with access to a copy of the server's private key can also uncover the session keys and thus decrypt everything.

For some, the side-effects are desirable. Many network security devices, for example, can be configured to decrypt communication (and inspect traffic) when given servers' private keys. Without this capability, passive IDS/IPS and WAF devices have no visibility into the traffic and thus provide no protection.

In the context of mass surveillance, however, the RSA key exchange is a serious liability. Your adversaries might not have your private key today, but what they can do now is record all your encrypted traffic. Eventually, they might obtain the key in one way or another (e.g., by bribing someone, obtaining a warrant, or by breaking the key after sufficient technology advances) and, at that time, they will be able to go back in time to decrypt everything.

Diffie–Hellman key exchange

An alternative to RSA-based key exchange is to use the ephemeral Diffie-Hellman algorithm, which is slower, but generates session keys in such a way that only the two parties involved in the communication can obtain them. No one else can, even if they have access to the server's private key.¹

After the session is complete, and both parties destroy the session keys, the only way to decrypt the communication is to break the session keys themselves. This protocol feature is known as Forward Secrecy.²

Now, breaking strong session keys is clearly much more difficult than obtaining servers' private keys (especially if you can get them via a warrant). Furthermore, in order to decrypt all communication, now you can no longer compromise just one key (the server's), but you have to compromise the session keys belonging to every individual communication session.

SSL and Forward Secrecy

SSL supports Forward Secrecy using two algorithms, the standard Diffie-Hellman (DHE) and the adapted version for use with Elliptic Curve cryptography (ECDHE). Why isn't everyone using them, then?

Assuming the interest and knowledge to deploy Forward Secrecy is there, two obstacles remain:

DHE is significantly slower. For this reason, web site operators tend to disable all DHE suites in order to achieve better performance. In recent years, we've seen DHE fall out of fashion. Internet Explorer 9 and 10, for example, support DHE only in combination with obsolete DSA keys.
ECDHE too is slower, but not as much as DHE. (Vincent Bernat published a blog post about the impact of ECDHE on performance, but be warned that the situation might have changed since 2011. I am planning to do my own tests soon.) However, ECDHE algorithms are relatively new and not as widely supported. For example, they were added to OpenSSL only fairly recently, in the 1.x releases.

If you're willing to support both ECDHE and DHE, then you will probably be able to support Forward Secrecy with virtually all clients. But ECDHE alone is supported by all major modern browsers, which means that even with only ECDHE you might be able to cover a very large chunk of your user base. The decision what to do is entirely up to you. Google, for example, do not support any DHE suites on their main web sites.

Configuring Forward Secrecy

Enabling Forward Secrecy can be done in two steps:

Configure your server to actively select the most desirable suite from the list offered by SSL clients.
Place ECDHE and DHE suites at the top of your list. (The order is important; because ECDHE suites are faster, you want to use them whenever clients supports them.)

Knowing which suites to enable and move to the top can be tricky, because not all browsers (devices) support all Forward Secrecy suites. At this point you may want to look for inspiration from those who are already supporting Forward Secrecy, for example Google.

In the nutshell, these are some of the suites you might want to enable³ and push (close) to the top:

TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

To make this process easier, I've added a new feature to the SSL Labs test; this feature, tentatively called handshake simulation, understands the capabilities of major browsers and determines which suite would be negotiated with each. As a result, it also tells you if the negotiated suite supports Forward Secrecy.

Here's what it looks like in action:

When you get it right, you will be rewarded with a strong forward secrecy indicator in the summary section at the top:

Alternative attack vectors

Although the use of Diffie-Hellman key exchange eliminates the main attack vector, there are other actions powerful adversaries could take. For example, they could convince the server operator to simply record all session keys.

Server-side session management mechanisms could also impact Forward Secrecy. For performance reasons, session keys might be kept for many hours after the conversation had been terminated.

In addition, there is an alternative session management mechanism called session tickets, which uses separate encryption keys that are rarely rotated (possibly never in extreme cases). Unless you understand your session tickets implementation very well, this feature is best disabled to ensure it does not compromise Forward Secrecy.

(1) Someone with access to the server's private key can, of course, perform an active man in the middle attack and impersonate the server. However, they can do that only at the time the communication is taking place. It is not possible to pile up mountains of encrypted traffic to decrypt later.

(2) It's also sometimes called Perfect Forward Secrecy (PFS), but, because it is possible to uncover the communication by breaking the session keys, it's clearly not perfect.

(3) I am assuming the most common case, that you have an RSA key (virtually everyone does). There's a number of ECDHE suites that need to enabled if you're using an ECDSA key. I am also ignoring GCM suites for the time being, because they are not very widely supported. I am also ignoring any potential desire to mitigate BEAST by favouring RC4, which might be impossible to do across all client devices.

Announcing Bulletproof SSL and TLS

2013-05-22T00:00:00+01:00

For those of you who have been following my blog, or my work on the SSL Labs web site, it won't come as a surprise that my next book is about SSL/TLS and PKI, and all the related things you need to know if you want to use these technologies.

Bulletproof SSL and TLS is the book I wish I had back when I was starting to get involved with SSL. I don't remember when exactly that was, but I do remember how, when I was writing my first book, Apache Security, I began to appreciate cryptography. I began to like it, even. Before, SSL seemed simple to me; but then I realised how vast the world of cryptography actually is.

In 2009 I began to work on SSL Labs, and, for me, that world began to unravel. Fast-forward a couple of years, and in 2013 I still feel like I am only starting. Cryptography is a unique field where the more you learn the less you know.

In supporting the SSL Labs users over the years, I've realised that there is a lot of documentation on SSL/TLS and PKI, but that it suffers from two problems: (1) it's not documented in one place, and so the little bits and pieces (e.g., RFCs) are difficult to find and (2) it tends to be very detailed and low-level. I needed years of effort to begin to understand the everything fits together.

Bulletproof SSL and TLS aims to address the documentation gap, offering a very practical book that paints the whole picture and then proceeds to discuss the bits and pieces that you need in daily work, going as deep as needed to explain what you need to know.

At this point, the manuscript is about 120 pages long, which I estimate to be between 30% and 50% of the finished book. I expect the book will be available in Autumn. Until then, I have a little treat for you; if you head over to the Feisty Duck web site, I am realeasing the main OpenSSL chapter as a standalone free ebook called OpenSSL Cookbook. It's about 50 pages at the moment, but I hope that grows longer over time. Qualys has graciously allowed me to include the SSL/TLS Deployment Best Practices document in the appendix.

RC4 in TLS is broken: Now what?

2013-03-19T00:00:00+00:00

RC4 has long been considered problematic, but until very recently there was no known way to exploit the weaknesses. After the BEAST attack was disclosed in 2011, we—grudgingly—started using RC4 in order to avoid the vulnerable CBC suites in TLS 1.0 and earlier. This caused the usage of RC4 to increase, and some say that it now accounts for about 50% of all TLS traffic.

Last week, a group of researchers (Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt) announced significant advancements in the attacks against RC4, unveiling new weaknesses as well as new methods to exploit them. Matthew Green has a great overview on his blog, and here are the slides from the talk where the new issues were announced.

At the moment, the attack is not yet practical because it requires access to millions and possibly billions of copies of the same data encrypted using different keys. A browser would have to make that many connections to a server to give the attacker enough data. A possible exploitation path is to somehow instrument the browser to make a large number of connections, while a man in the middle is observing and recording the traffic.

We are still safe at the moment, but there is a tremendous incentive for researchers to improve the attacks on RC4, which means that we need to act swiftly.

What We (SSL Labs) Will Do

Start warning our users about RC4 weaknesses. RC4 is demonstrably broken and unsafe to use in TLS as currently implemented. The difficulty is that, for public web sites that need to support a wide user base, there is practically nothing 100% secure they can use to replace RC4. We now have no choice but to accept that, no matter what settings we use, some segment of the user base will be at risk.
If Apple were to implement 1/n-1 record splitting in their stacks (the only major browser vendor that hasn’t done that yet*), we’d likely consider BEAST sufficiently mitigated client-side, and that would allow us to start recommending CBC suites over RC4.
Start recommending the use of GCM suites. Browsers will no doubt provide better support for TLS 1.2 and GCM suites at an accelerated schedule, and site operators should be ready to take advantage of that.
Update SSL/TLS Deployment Best Practices with new information.
At some point in the near future, update the rating algorithm to take the RC4 weaknesses into account.

Recommendations

SSL/TLS library developers

Harden the stack against the Lucky 13 attack.
Support TLS 1.2 and GCM suites as soon as possible.

Browser vendors

Support TLS 1.2 and GCM suites as soon as possible.
Implement 1/n-1 record splitting to make CBC suites safe in TLS 1.0 and earlier. As far as we are aware, Apple is the only remaining vendor that has not patched their browsers, either on OSX or iOS.

System administrators

Disable TLS compression. This attack is similar in nature to the recent RC4 attacks, but practical.
Support TLS 1.2 and GCM as soon as possible.

TLS Working Group

Restore algorithm agility and diversity in TLS. AES GCM suites are now the only truly secure option in TLS, but we shouldn’t count on them to stay like that forever.
Consider introducing other stream ciphers to the standard. Algorithm agility, which TLS already provides, is not sufficient if there is only one choice for a component.
Consider changing how CBC is implemented in order to address the timing issues.

Application developers

Harden session management to support reliable and frequent rotation of session cookies, triggered by elapsed time or the number of requests observed. Recent years have seen a rise in attacks that require attackers to control the client end of a TLS connection in some fashion. Most such attacks focus on extracting small bits of information, typically credentials. Session cookies are now the most popular target. Given how many requests are needed for the best attacks to succeed, rotating session cookies frequently is a good defense in depth measure.

(*) Apple appears to have shipped the 1/n-1 split in Mountain Lion, but it is disabled by default. I was also unable to observe any splitting after the functionality had been manually enabled. iOS devices should support TLS 1.2, which means that they might be secure provided TLS 1.2 is available server-side.

SSL Labs update increases security requirements

2013-02-07T00:00:00+00:00

The SSL threat landscape has changed significantly since the rating guide was first published, back in 2009. The original text is thus no longer entirely adequate to deal with the threats of today. In addition, we now have several years of experience using the criteria in real life, and we know what works well and what not so much.

Our plan is to update the rating criteria to take all this new knowledge into account. However, because that process will take several months to complete and because an update to the guide is long overdue, we have decided to release a small patch release, labelling it 2009c. The year in the version number indicates that this is conceptually the same guide as previously published, with improvements.

Essentially, the purpose of this release is to keep the rating criteria relevant for a little while longer, until the next major version is ready. The text of the original document remains as is, but the following changes apply:

SSL 2.0 is not allowed (F).
Insecure renegotiation is not allowed (F).
Vulnerability to the BEAST attack caps the grade to B.
Vulnerability to the CRIME attack caps the grade to B.
The score (0-100) is not shown any more, in order to focus on the grade, which is more useful. Future versions of the guide will probably remove the score altogether.

In addition, we've taken the opportunity to remove the old configuration advice, directing the readers to our SSL/TLS Deployment Best Practices document instead.

Large-scale passive SSL monitoring at ICSI

2012-11-12T00:00:00+00:00

The International Computer Science Institute (ICSI) recently announced a new certificate notary project. Although I find the notary aspect of the project interesting, I think that their work is much more important because of the potential of their approach, which is based on large-scale passive monitoring of SSL connections. In the last couple of years I spent a lot of time looking at the server-side aspect of SSL (most recently, in the SSL Pulse project), but there's a large gap in our understanding when it comes to client-side capabilities, and actual real-life usage. The gap can be explained by ICSI's data.

Sadly, ICSI is unable to share their data because of various privacy concerns. However, they can still mine the data themselves. I decided to put together a list of unanswered SSL usage questions, as a way of contributing to the effort.

Focusing on client capabilities is a good way to start. Some of the most interesting attributes to track might be:

Highest TLS version
Cipher suites (and their order)
TLS extensions
Compression methods
BEAST mitigation
SNI (virtual SSL hosting)
Secure renegotiation (via extension or SCSV)
Session ticket support
Request for OCSP stapling
SPDY support (via the NPN extension)

The most exciting aspect of the project is that it might be able to finally give us the answer to the effective security of SSL. Some key data points include:

Negotiated protocol version
Negotiated cipher suite/strength
Was the suite actively selected by the server
Authentication strength (certificate key size)
DH params/strength (for applicable cipher suites)
Compression usage
Session resumption status (tracked via either mechanism)
Seen stapled OCSP response
Server certificate information
- Key size
- Signature algorithm
- Is it expired?
- Is it self-signed?
Certificate chain correctness
Is the trust root a well-known CA?
Vulnerabilities:
- Renegotiation (do both sides support secure renegotiation)
- BEAST (no browser mitigation and a CBC suite using TLS 1.0 or earlier)
- CRIME (use of TLS compression for the connection)

Improved passive SSL fingerprinting in sslhaf

2012-10-18T00:00:00+01:00

I've had some available time recently to work on sslhaf, my passive SSL fingerprinting tool. I made the following improvements:

Detect browser BEAST mitigation (1/n-1 splitting)
Extract compression support
Extract TLS extensions
Change licence from GPLv2 to BSD
Bug fixes

I think that the detection of BEAST mitigation measures is particularly useful, because it will help understand the risk coming from this attack. Most, but not all, major browsers have mitigations in place. In addition, we don't know how many vulnerable older clients there are. I hope to publish some measurements soon.

The tool is stable but technically still experimental, so use at your own risk. I'd be willing to make it production ready if there's anyone interested in deploying it in a large web site.

CRIME: Information leakage attack against SSL/TLS

2012-09-14T00:00:00+01:00

It seems that it is that time of year again, when Juliano and Thai present their most recent attack against crypto system. Last year, it was BEAST. This year, it's CRIME, a practical attack against how TLS is used in browsers. In a wider sense, the same attack conceptually applies to any encrypted protocol where the attacker controls what is being communicated.

Initially, it was only known that the attack builds on top of an information leakage weakness, and the full results were going to be revealed at the talk at Ekoparty on September 21. Funnily enough, the details that were revealed themselves "leaked" and were sufficient for the experts to understand what is going on: On StackExchange, Thomas Pornin speculated that it was about compression. An academic paper from 2002 (PDF) was revealed. A proof of concept was submitted by xorninja, and improved by Krzysztof Kotowicz. Dan Goodin wrote a great summary of what was known at the time, and included a video of the demonstration. Finally, Threat Post published a confirmation from Juliano and Thai that was indeed compression.

What is the problem?

The root cause of the problem is information leakage that occurs when data is compressed prior to encryption. If someone can repeatedly inject and mix arbitrary content with some sensitive and relatively predictable data, and observe the resulting encrypted stream, then she will be able to extract the unknown data from it.

In practice, the attack works best against session cookies. If a man-in-the-middle (MITM) attacker 1) can observe network traffic, and 2) manipulate the victim's browser to submit requests to the target site, she can, as a result, steal the site's cookies, and thus hijack the victim's session. In the current form, the exploit uses JavaScript and needs 6 requests to extract one byte of data. The use of JavaScript is desired, but not required: simple <img> tags can do the job just as well, although with a performance penalty.

How bad is it?

Several aspects need to come together for CRIME to be widely exploited. First of all, there has to be server-side support for compression of request data before encryption. TLS supports DEFLATE compression (not to be confused with HTTP response compression, which is very popular, but not vulnerable to CRIME), but not all servers implement it. SSL Labs tests across the SSL Pulse data set indicate that about 42% of the servers support TLS compression. The servers include some of the most popular sites in the world.

Another possibility is that the newer protocol, SPDY, is also vulnerable, because it has a separate mechanism for request header compression. In that case, all servers that support SPDY would be potentially vulnerable. SPDY is a young protocol and not very widely supported, but the sites that do support it are typically larger properties. SSL Labs is currently half way in measuring the support for SPDY across the SSL Pulse data set, but we're currently seeing SPDY support at ~~0.8~~2%.

The second requirement is that client-side also supports compression, and here we will find that the situation is much better. The only browser to properly support TLS compression is Chrome. As for SPDY, both Chrome and Firefox support it. However, it is understood that both Chrome and Firefox have removed support for TLS compression in their most recent updates. (For Firefox, it's even not clear if it was ever enabled.) SSL Labs runs a passive SSL fingerprinting tool called sslhaf. Using it we were able to estimate that only about 7% of browsers support compression at this point. This is on our site, which gets a higher portion of the traffic from Chrome and Firefox users. Analysing the logs, we could see traces of Chrome, and, it seems, some mobile browsers. It is not clear if there were any changes to the SPDY implementation in Chrome and Firefox, but it is reasonable to expect that there will be.

The third requirement for wide exploitation is an easy to use exploitation tool. Unlike BEAST, CRIME seems much easier to exploit; we've already seen a simple proof of concept, and so it's likely that we will see a complete tool soon, maybe as a fork of sslstrip.

Taking all of the above in the account, CRIME will be easy to exploit, but it will be harder to find vulnerable clients. Internet Explorer, Safari, and Opera do not seem to be affected. Chrome and Firefox seem to be, but they use automatic updates, so I expect that the majority of the user base will upgrade to the patched versions. The vulnerable clients will thus be restricted to those using older clients.

Further, unlike BEAST, which requires a manual intervention to mitigate, CRIME will be easier to patch. I expect most vendors will simply disable TLS compression.

What to do?

First of all, if you're using an older Chrome or Firefox, upgrade to the most recent version. If you're operating a web site, use the SSL Labs assessment tool to determine if your site supports TLS compression and SPDY (look for Compression and Next Protocol Support on the results page, towards the bottom). If you think the risk is too high, disable compression if your web software allows you to do it. (If they don't today, they will soon.)

Update (15 Sep 2012) In Details on the "CRIME" attack, iSec Partners give a very good overview of which browsers are vulnerable, and how to disable compression server side.

How good is client-side support for RC4?

2012-07-17T00:00:00+01:00

When it comes to the mitigation of the BEAST attack against SSL/TLS, the usual advice is to prioritize RC4 cipher suites in order to avoid CBC suites, which are vulnerable. In some cases, companies may even have to use RC4 suites exclusively. For example, I've recently heard of a case where a company was failed on its PCI compliance test because they had non-RC4 cipher suites enabled in their configuration.

When RC4 prioritization is discussed, people often seek assurance that RC4 is widely supported. Obviously, if you are going to disable a large number of cipher suites, you start to worry if the remaining suites are going to be sufficient for your user base. Until recently, I had no answer to those questions. Even though all major browsers support RC4 by default, there was no way to quantify the support. Further, some browsers allow users to turn off certain cipher suites, and we just didn't know what the situation on the ground was.

About two months ago I re-enabled mod_sslhaf on the SSL Labs web server. This Apache module, a project of SSL Labs, records all cipher suites offered by clients. Today I looked at the results, curious to find out exactly how many of the SSL Labs clients supported RC4. I choose to compare the total number of unique IP addresses against the number of IP addresses that did not support TLS_RSA_WITH_RC4_128_MD5 (0x04) or TLS_RSA_WITH_RC4_128_SHA (0x05).

In about two months, SSL Labs saw 48,481 unique IP addresses. Only 45 of those -- or 0.09% -- did not support RC4. Looking at the user agent information, the clients not supporting RC4 seem to be largely those whose users decided to explicitly disable RC4 for one reason or another.

The usual disclaimer applies here: the sample is taken from the SSL Labs web site and may not apply to other sites. However, if the assumption that the only non RC4 clients are those where this cipher suite was disabled by their owners, you could argue that an average site will see an even smaller number of non-compatible clients.

My Infosecurity London 2012 SSL Panel Notes

2012-05-23T00:00:00+01:00

Last month, GlobalSign invited me to participate on an SSL Panel at Infosecurity London. Other participants were David Holmes (F5), Ryan Hurst (GlobalSign), and Steve Roylance (GlobalSign, moderator). These are my rough notes. I hope you will find them interesting.

Can you tell us about yourself and why you’re here?

In 2009 I quit my job (because I had become bored), and I decided to work on something I can be passionate about. As it happens, that something was SSL. I had discovered SSL a few years before, while working on my book Apache Security, and always wanted to go back to it, to research it in more detail. To my dismay, I discovered that SSL, arguably the most important security protocol on the planet, is poorly documented, difficult to configure correctly, and that there are no tools to test SSL configurations. That's when SSL Labs was born. Today, SSL Labs offers the best assessment platform and for free. In the past 2 years we've conducted several large-scale surveys of public SSL implementation in an effort to understand exactly where we are, when it comes to the security of the Web.

Talk to us about your perspective on the last two years and the breaches at third-party trust providers?

I think that, in the last 2 years we learned that security is not static. It's not something you work on, and then leave it behind. You know, SSL was designed in 1994, and, today, in 2012, remains essentially the same, conceptually. In the meantime, we saw the Web evolve, and evolve around SSL. The threat model of today is vastly different to the threat model of 1994. Eighteen years! So we dropped the ball. But I think that's actually how things work, for us humans. We don't think about security while it's not a problem. As a result of that, security it becomes a real problem eventually, and then we start to think about it. It's a cycle; a never-ending cycle.

How would you describe the current situation of Public Trust on the Internet?

It's not as bad as it seems. I think that, practically speaking, our biggest problem is not that we have too many CAs, but that we cannot yet build secure systems. The events from the last two years made us realise that any system can be broken into, and -- surprise, surprise -- even the CAs. Once you accept that, the obvious problem with Public Trust is that any one CA can create a certificate for any web site. Site owner's permission is not even required. I am hopeful that that will be fixed with a new standard supporting public key pinning. Then, site owners will be able to say which CAs can issue certificates for their web sites.

Why aren’t Extended Validation certificates saving us now?

You know, back in the day, all certificates used to be "EV". I remember very well jumping through many hoops to get a certificate -- so long ago I don't even remember what year it was. I don't think that many people realise that, prior to EV certs, there wasn't a standard for certificate issuance. Today, there isn't a standard for non-EV certificae issuance [we may get one officially any time now]. So I welcome EV certificates, because they connect your online presence to your off-line identity. That's great, if you need it or if you want it. At the same time, DV certificates are getting cheaper, which is how it should be. The basic security of the communication channel should be available to everyone.

What is your take on the recent advances in cryptographic and protocol focused attacks?

The recent attacks against SSL are a sign of protocol maturity. The reality is that we are not smart enough to foresee all problems when we're designing protocols. So the only way to arrive at something that is secure, is to give it our best shot, start to use it, and fix it as problems are discovered. The recent attacks against SSL demonstrate that people are looking at SSL, and that's a great thing. That means that we're improving. The sky is not falling; but please don't tell everyone. I don't mind the sensational headlines, because they get people's attention. Without the headlines -- without fear -- we wouldn't be able to improve security in the same way. For example, about 75% of all SSL sites are vulnerable to the BEAST attack. I wouldn't mind seeing a sensationalist headline scaring everyone to improve their configuration. The reality is that we need more headlines and more working exploits. How CISO’s should approach trust providers and risk? Choose a CA that you can trust, and a company for which certificate issuance is a significant business (revenue stream). Most of the risk is in-house, in which how you manage your certificates, configure your SSL servers, and implement your applications.

If you were to sit down with an IT manager today and talk to them about his biggest risks relating to SSL what would you tell them?

The biggest SSL-related risk is at the application layer. Your SSL server may be misconfigured today, but you can fix that very quickly. We have people testing themselves using our online assessment tool, getting a bad grade, improving their configuration and even getting a new certificate, just an hour later. And, to be honest, no one is attacking SSL directly. The real risk lies in the application layer, when applications use features that completely subvert SSL. It's like SSL isn't there. We conducted a deep survey of these issues last yar (in the most popular web sites), and the conclusion was that most sites are vulnerable, and SSL effectively useless. I have a lot of hope for declarative security measures. For example, HTTP Strict Transport Security is an emerging standard where you can declare that your application/site uses only SSL (never plain-text HTTP). That means that, even if your application contains implementation errors, you remain secure. I also have a lot of hope for new protocols, which will include SSL as a mandatory component. Eventually, we will migrate to an Internet that is 100% encrypted. I hope.

What do you think is the future of Public Trust?

Realistically speaking, I think we will stay pretty much where we are. Public Key Pinning will remove the most obvious problem. To change anything else -- that's too much work for anyone's taste. I would very much like to see browsers incorporate some elements of crowd-source (Covergence-style) trust for those who understand it. Password-based SSL authentication could be interesting.

What changes are being proposed to augment existing security technologies and how these changes may affect the industry?

We've seen many proposals, but not all of them are equally easy to implement. For example, there's DNSSEC that implements a secure DNS, and DANE, which is a bridge between secure DNS and PKI. Because there is no doubt that we need a secure DNS, I have no doubt that DNSSEC will be widely deployed, eventually (it will take a few years). In the meantime, low-effort proposals, such as HSTS and Public Key Pinning, are likely to become practical. Technically speaking, other proposals can become reality, too, but they require a lot of lobbying and involve a lot of politics.

What do you think about DNSSEC and DANE?

There's one aspect of DANE that I am not sure about, and that's the ability to have valid certificates without CAs. It's not that I like CAs very much, but we forget that the PKI infrastructure was designed to be independent of DNS. And, with DNSSEC, we will revert to only one trust root -- that in the DNS. On the other hand, everyone deserves basic security, and that's something DNSSEC will most certainly achieve. The biggest problem is that with current CA-based ecosystem or with DNSSEC, site owners have no say.

What are the biggest problems of the security industry?

Our biggest problem is in having the security industry in the first place. Security is the business of the developers (used here in a wider sense, to mean those who implement things.) We have the security industry today only because those who are implementing our systems are not building security in. And that's our biggest problem. It's only when the economics of secure development improve that we are going to see substantial improvement in security. Apart from that, our biggest problem is complacency. For example, the CAs, who were (and are) getting serious money from issuing certificates, could have stayed on top of things. The could have tracked the threat model and reacted to new threats. (I don't actually blame CAs for that. I mean, I do, but, ultimately, a wider community should take the responsibility.) Browser vendors could have fixed usability issues (rather than putting the burden of security on the shoulders of end users). And so on... We need our incentives aligned, so that it is in everyone's interest to have better security.

Announcing SSL Pulse

2012-04-30T00:00:00+01:00

Last week we announced SSL Pulse, a continuously updated dashboard that is designed to show the state of the SSL ecosystem at a glance. While it is possible today to deploy SSL and to deploy it well, the process is difficult: the default settings are wrong, the documentation is lacking, and the diagnostic tools are inadequate. For these reasons, we cannot say that the Web is yet secure, but we hope that someday it will be. The purpose of SSL Pulse is to bring visibility to SSL implementation issues on the Web, and while businesses are starting to fix these issues we can keep track of progress made towards making SSL more robust and widely adopted on the Internet.

SSL Pulse is based on the assessment technology and testing conducted by SSL Labs. The underlying data set draws from the information on about 200,000 SSL web sites that represent the most popular web sites in the world. We cherry-picked only the most important data points, focusing especially on those aspects where improvements are needed. We have so far conducted only one round of testing, but, when the next month’s results become available, we will start to show historic values and hopefully see improvements for each data point.

So what do the results tell us? Looking at the SSL Labs grades, which are designed to sum up the quality of SSL configuration, we can see that about 50% (99,903 sites) got an A, which is a good result. Previous global SSL Labs surveys reported about 33% well-configured sites, which means that more popular sites are better configured. Unfortunately, many of these A-grade sites (still) support insecure renegotiation (8,522 sites, or 8.5% of the well-configured ones) or are vulnerable to the BEAST attack (72,357 sites, or 72.4% of the well-configured ones). This leaves us with only 19,024 sites (or 9.59% of all sites) that are genuinely secure at this level of analysis.

The number of sites vulnerable to insecure renegotiation is decreasing at a steady pace, as patches are applied or servers get replaced. The very high number of sites vulnerable to the BEAST attack is worrying, because this problem needs to be addressed in configuration, and that requires awareness, time, and knowledge. Plus, freshly installed systems are equally likely to be vulnerable because of the insecure defaults.

Among other interesting data points, we found only 19 weak private keys in our data. There are also 9 keys that trigger our black list of weak Debian keys. The support for HTTP Strict Transport Security, which is the state of the art configuration for SSL, is at 0.85% (1,697 sites).

As part of this effort, we also published an SSL/TLS Deployment Best Practices guide with clear and concise instructions to help overworked administrators and programmers spend the minimum time possible to deploy a secure site or web application.

Qualys supports reform at CA/Browser Forum

2012-03-30T00:00:00+01:00

Last month, the CA/Browser Forum announced the creation of a working group that will focus on organizational reform. We welcome the announcement with open arms; the public PKI infrastructure needs more structure, collaboration, and visibility, and the CA/Browser Forum is in the best position to advance the robustness of the infrastructure in the short term.

The PKI infrastructure has been evolving organically for too long, and, because of that, we are today faced with many of its structural cracks. The challenge now for the security community (not just the CA/Browser Forum) is to:

understand the complexities of the public PKI infrastructure,
bring all the key stakeholders together,
establish a system of governance that serves the collective interests,
realign stakeholders' incentives to make the ecosystem stronger,
in the short-term, resolve key structural and technical issues,
maintain an up-to-date threat model and address weaknesses proactively, and,
in the long-term, evolve the ecosystem to adequately address the real threats.

There is no doubt that a reform is needed; what is not clear is how it will take place. To facilitate the change, the CA/Browser Forum will need to transform substantially, inviting a wide participation as well as embracing openness and transparency. There is already a large number of organizations and individuals working on improving the security of the PKI infrastructure; those efforts need to be streamlined, and the changes orchestrated.

Some of the pressing issues that need to be addressed include the following:

The large attack surface stemming from a compromise of any one Certificate Authority
Not enough visibility into the operation of Certificate Authorities
Insufficiently defined operational requirements and auditing standards
Lack of reliable control mechanisms and ability to deal with failures
Low adoption rate of SSL/TLS across all web sites
Numerous configuration and implementation issues that subvert security in those sites that did adopt SSL/TLS
Inadequate browser SSL/TLS implementations that do not make security seamless and easy (instead pushing the burden of security onto the shoulders of the end users, who are not in the position to make informed decisions), but still make it difficult for advanced users (who are in the position to make informed decisions) to pursue alternative approaches

SSL and Browsers: The Pillars of Broken Security

2012-03-07T00:00:00+00:00

Last week at the RSA Conference, Wolfgang and I gave a talk called SSL and Browsers: The Pillars of Broken Security. We could have easily called it a State of SSL, because we went through the most relevant SSL issues today, demonstrated the problems using the data from SSL Labs surveys, and discuss how the issues can be overcome. Here's the talk summary:

Recent attacks on browsers and certificate authorities for SSL have shown how fragile these systems are, yet we all depend on them while using the Internet on daily basis. This talk will explore the implementation flaws in the SSL protocol and the browsers that support it. The speakers will showcase extensive research collected from millions of websites that reveal the state of SSL and Browse Security on the Internet. The session will then explore the mitigation options for the problems we are experiencing today, and provide a framework in which we can solve future SSL security issues.

Get this slides here:

SSL and Browsers: The Pillars of Broken Security (PDF, 4 MB)

Announcing the SSL/TLS Deployment Best Practices guide

2012-02-23T00:00:00+00:00

SSL/TLS is a deceptively simple technology. It is easy to deploy, and it just works . . . except that it does not, really. The first part is true—SSL is easy to deploy—but it turns out that it is not easy to deploy correctly. To ensure that SSL provides the necessary security, users must put more effort into properly configuring their servers.

In 2009, we began our work on SSL Labs because we wanted to understand how SSL was used and to remedy the lack of easy-to-use SSL tools and documentation. We have achieved some of our goals through our global surveys of SSL usage, as well as the online assessment tool, but the lack of documentation is still evident. This document is a first step toward addressing that problem.

Our aim here is to provide clear and concise instructions to help overworked administrators and programmers spend the minimum time possible to obtain a secure site or web application. In pursue of clarity, we sacrifice completeness, foregoing certain advanced topics. The focus is on advice that is practical and easy to understand. For those interested in advanced topics, we provide references at the end of the guide.

Download the guide:

SSL/TLS Deployment Best Practices (PDF, 500 KB)

TLS Renegotiation and Denial of Service Attacks

2011-10-31T00:00:00+00:00

A group of hackers known as THC (The Hacker's Choice) last week released an interesting DoS tool that works at the SSL/TLS layer. The tool is exploiting the fact that, when a new SSL connection is being negotiated, the server will typically spend significantly more CPU resources than the client. Thus, if you are requesting many new SSL connections per second, you may end up using all of the server's CPU.

The issue abused by the tool is not new, but what is new is that we now have a well publicised working exploit, and that always makes you pay attention. In addition, the tool uses the renegotiation feature, which means that it can force a server to perform many expensive cryptographic operations over a single TCP connection. It's not clear if the relying on renegotiation helps with the DoS attack (there's a very good analysis of the trade-offs on Eric Rescorla's blog), however the fact that external DoS mitigation tools (e.g., rate limiting setups) are only seeing one TCP connection certainly helps with avoiding detection.

But that's only if your server supports client-initiated renegotiation. If it does not, anyone wishing to perform a DoS attack against the SSL layer will have to fall back to using one TCP connection for one SSL connection. IIS, for example, does not support client-initiated renegotiation. Apache used to, but changed its behaviour when implementing RFC 5746 (which fixed the TLS Authentication Gap problem). Even if you depend on a product that does support client-initiated renegotiation, chances are you can easily disable that feature. And, when you do, you are not going to miss it (unlike server-initiated renegotiation, which some sites that require client certificates might need).

To help you with assessing your systems for this weakness, we have updated the SSL Labs assessment tool to test not only if secure renegotiation is supported (which we've been testing for some time now), but also to check if secure client-initiated renegotiation is enabled. Previously we only tested for insecure client-initiated renegotiation.

The sensible thing to do is to check for client-initiated renegotiation support in your servers, and disable it where possible. Although that won't substantially help you overall (defending against DoS attacks is notoriously difficult and expensive), it will harden your defences against this particular technique.

Mitigating the BEAST attack on TLS

2011-10-17T00:00:00+01:00

Update (19 March 2013): This blog post advises to use RC4 to migitate the BEAST attack, but RC4 has recently been discovered to be weaker than previously known. At this point the attacks against RC4 are still not practical. The only fully safe choice at the moment is the AES-GCM suites supported only in TLS 1.2. You can find out more in this new blog post.

During the summer rumours about a new attack against SSL started circulating. Then Opera released a patch, but made no comment about what it was patching. Eventually enough information leaked out that some smart people figured what the attack was about. What remained unknown was the exact technique used in the proof of concept, and that was eventually explained in Thai's blog post. For a comprehensive overview of related links, go to Thierry Zoller's blog post on BEAST.

As it turns out, the attack itself was conceived years ago, deemed impractical, but it was nevertheless fixed in TLS 1.1. The new attack technique introduced a few optimizations to make it practical.

In terms of mitigation, I expect this problem will be largely addressed on the client side, despite a potential compatibility problem that may cause some TLS sites to stop working. The only reliable way to defend against BEAST is to prioritise RC4 cipher suites, as proposed by PhoneFactor.

Just as an example, here's one way to do the above in Apache:

SSLHonorCipherOrder On SSLCipherSuite RC4-SHA:HIGH:!ADH

Not everyone likes RC4, even though there is little to no evidence that it is insecure in the context of SSL/TLS. If your server supports TLS 1.2+ you can try the approach recommended by Steve Caligo:

SSLHonorCipherOrder On SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

The idea is that you put a few TLS 1.2 cipher suites first so that they can be picked up by TLS 1.2 clients, which are not vulnerable, followed by RC4 for TLS 1.0 clients.

Now that I've discussed what works as mitigation, let's look at a few approaches that do not work:

Supporting TLS 1.1+ server-side is a good start, but does not amount to much because very few clients support newer versions of the protocol at this time. And even with TLS 1.1+ support client-side, there's nothing preventing the MITM to force a protocol downgrade back to TLS 1.0. (For a discussion on defense techniques against downgrade attacks, see this thread on the TLS WG mailing list).
Enabling the empty fragment technique server-side (details for OpenSSL here) does not work either. TLS 1.0 uses two initialisation vectors (IVs), one each for client- and server-side of the communication channel. The vulnerability exploited by BEAST is on the client-side and cannot be addressed by making server-side changes to how data is sent.
Compression is said to make the attack impossible, but, as with TLS 1.1+, the support for it client-side is inconsistent.

Update (20 Jan 2012): In testing OpenSSL 1.0.1-beta2, which came out yesterday, I realised that it will happily negotiate AES-CBC-SHA256 even on a TLSv1.0 connection. So I removed it from the recommendation, replacing it with two other TLSv1.2 cipher suites.

SSL Labs: Announcing launch of two Convergence notaries

2011-09-29T00:00:00+01:00

Convergence is Moxie Marlinspike's attempt to introduce fresh thinking into the debate about PKI, certificate authorities, and trust. A hint of what was in the works was in a blog post published in April (SSL And The Future Of Authenticity); the project was launched at Black Hat US in August. Moxie's talk (here's the video on YouTube) was entertaining and insightful.

Moxie advertises the project as a way of dispensing with certificate authorities ("An agile, distributed, and secure strategy for replacing Certificate Authorities"). At the first glance that's true. You get a browser add-on (only Firefox for the time being) that, once activated, completely replaces the existing CA infrastructure. Whenever you visit an SSL site your browser will talk to two or more remote parties (notaries) and ask them to check the site's certificate for you. If they both see the same certificate you decide to trust the site.

But when you dig deeper into the project, you realise that it consists of two parts. The first, and more important, part is the ability to delegate trust decisions from your browser to another party that's remote to you. That means that you are no longer forced to accept the decisions of the browser vendors, but you can make your own. That ability is, for me, the most thrilling aspect of the project.

The second part of the project is the current backend implementation that makes trust decisions. The approach is great in its simplicity: if you can see the same certificate from several different locations you conclude that it must be the correct certificate. We mustn't rush, however. We've just been given the ability to choose whom to trust, and it's too soon to settle on any one implementation. I am far more interested in experimenting with different approaches, to see what works and what does not.

To that end, it makes me very happy to announce that we (Qualys) have decided to support Convergence by financing and running two notary servers. While it's not yet clear if Convergence can succeed (there are many technological and adoption challenges to conquer), we want to play a part in it and help it succeed.

Finally, here are the links to the notary servers (one of which is in the US and the other in Europe):

Note: To use the above links, you have to have the Convergence plugin installed. After that, all you need to do is click on the links and the notaries will become part of your configuration. Please report any problems to convergence-notary@qualys domain name.

Key SSL/TLS mailing lists to follow

2011-09-26T00:00:00+01:00

The best way to really learn about SSL/TLS and related topics is to follow the discussions on the key technology mailing lists. These lists are always interesting, but especially so in turbulent times, when the value of participation simply goes through the roof.

The key mailing lists are the following:

Transport Layer Security Working Group (core protocols); list archive
Web Security Working Group (HSTS); list archive
SSL Observatory (trust ecosystem); list archive

The list archives are publicly available, so there's not even a need to subscribe.

SSL Survey: How many sites support TLS 1.1 and better?

2011-09-23T00:00:00+01:00

In the last two weeks there's been a lot of chatter about a new attack against SSL and a tool called BEAST. You can find some coverage here, here, and here. The public has not seen any details of the attack yet (they are expected to be released at the ekoparty security conference), but crypto experts have a good idea what it is.

As it appears that the attack wouldn't work against TLS 1.1 and better, suddenly everyone is interested in how many web sites support the newer protocol versions. Virtually none. To illustrate, I am including a slide from my recent Black Hat presentation, where you will see that, even though TLS 1.1 is a 5-year old protocol, there is virtually no support for it.

If you're interested in what exactly is supported in various products, Thierry Zoller has a very good overview. If you want to know more about how SSL is deployed in practice, read our full survey results.

Note: The above slides shows results from an analysis of about 300,000 SSL sites from Alexa's top 1m most popular list. In a separate analysis we also looked at all SSL sites (1.2 million of them), and the numbers are practically identical.

So, what really breaks SSL?

2011-08-09T00:00:00+01:00

After years of being ignored -- which is an unusual situation for the protocol that secures the Web -- SSL became the focus of the interests of the security community at some point in 2008 or thereabout. From then on, a couple of months wouldn't pass between discoveries of one flaw or another. Most problems were with the way SSL is implemented, with one notable exception (the SSL/TLS renegotiation gap) in the protocol itself. As a result of this attention, the effective security of SSL has been continuously improving.

However, for an average web site, the security of the communication channel is rarely compromised by attackers using advanced exploitation techniques. On the contrary, the compromises virtually always come from the flaws in the way SSL is deployed. These problems are created by those implementing and maintaining web sites. And, in most cases, they can relatively easily be fixed.

In the most recent round of our SSL research, SSL Labs focused on programming and deployment errors that compromise SSL security even when SSL is properly configured, with strong cryptographic primitives and up-to-date libraries. None of these issues are new: failure to use SSL (when there is something worth protecting), mixing of encrypted and non-encrypted areas in the same site, mixed page content, insecure session cookies, login forms delivered or submitted over HTTP, and so on.

Although we initially started with the idea to discover how many sites have weaknesses, we discovered that the situation is so bad that we ended up looking for sites that do not have weaknesses. And the number of such sites is very, very small. (You can find the details if you download our presentation slides.) Sites with support for Strict Transport Security are preciously rare.

Why are the weaknesses so prevalent?

On one level, problems come from the way web "standards" have evolved. Slowly, over many years, and without a coherent security strategy. The truth is, it is very easy to break SSL with mistakes that occur on the HTTP level. Thus, our challenge here, short term, is that of education -- making developers aware of these issues.

Businesses are not exactly rushing to secure their sites, either, because there is often little incentive for them to do that. Their money (of which there is never enough), is almost always "better" spent doing other things. As a result, companies today spend on security only when they can't avoid it.

Long term, our only option is to incrementally improve our technology stack to build communication channel security in. Once the option to communicate via plain-text is taken away, there will be no way to subvert SSL. This is a tough goal to achieve, but the journey has already started. A security conscientious site operator can today deploy state of the art SSL configuration (which isn't that difficult, by the way), and achieve pretty good SSL security. Over time, the hope is that we will migrate to better communication protocol that embed SSL in, and that, once communication security becomes invisible, we won't have to worry about it any more.

A study of what really breaks SSL

2011-05-25T00:00:00+01:00

Earlier this year, we at SSL Labs conducted a second, much deeper survey of SSL usage. (I can now say "we" and really mean it, because most of the work on the survey was done by my Qualys coleague, Michael Small.) I presented the results last week at Hack In the Box Amsterdam:

We love security metrics because they tell us what really goes on out there. Last year we conducted an analysis of millions of SSL servers, showing, for the first time, how SSL is really used. This year we are pushing our study further by deepening and expending our efforts in several key areas. We will be looking at the problems that really break SSL — insecure session cookies, mixed content, incorrect site configuration, and distribution of trust to third-party sites. The best crypto in the world is not going to help a site that has flaws in these critical areas.

To discover these flaws we are building a custom site crawler, which we are then going to run against the world’s 1 million most used web sites. In addition to all that, we are expanding the scope of the study to include protocols other than HTTP, as well as basing our assessment on an updated version of the rating guide. The end result? We are finally going to find out how useful SSL really is.

Get the slides here:

A study of what really breaks SSL (PDF)

Fresh Internet SSL Survey results (April 2011) available

2011-04-27T00:00:00+01:00

Last week I attended InfoSec World and presented an update to our global survey of SSL configuration. I present the slides for your enjoyment:

Qualys SSL Labs State of SSL InfoSec World April 2011 (PDF)

An analysis will follow shortly.

Unfortunate current practices for HTTP over TLS

2011-01-19T00:00:00+00:00

This is such a good summary of the current state of SSL in web servers from Adam Langley, that I couldn't resist preserving it here in full. Enjoy.

Network Working Group                                         A. Langley
Internet-Draft                                                Google Inc
Expires: July 5, 2011                                           Jan 2011


            Unfortunate current practices for HTTP over TLS
                      draft-agl-tls-oppractices-00

Abstract

   This document describes some of the unfortunate current practices
   which are needed in order to transport HTTP over TLS on the public
   Internet.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 5, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Handshake message fragmentation  . . . . . . . . . . . . . . .  4
   3.  Protocol Fallback  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  More implementation mistakes . . . . . . . . . . . . . . . . .  6
   5.  Certificate Chains . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Insufficient Security  . . . . . . . . . . . . . . . . . . . .  8
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Changes . . . . . . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12


1.  Introduction

   HTTP [RFC2616] is one of the most common application level protocols
   transported over TLS [RFC5246].  (This combination is commonly known
   as HTTPS based on the URL scheme used to indicate it.)  HTTPS clients
   have to function with a huge range of TLS implementations, some of
   higher quality than others.  This text aims to document some of the
   behaviours of existing HTTPS clients that are designed to ensure
   maximum interoperability.

   This text should not be taken as a recommendation that future HTTPS
   clients adopt these behaviours.  The security implications of each
   need to be carefully considered by each implementation.  However,
   these behaviours are common and the authors consider it better to
   document the state of practice than to simply wish it were otherwise.


2.  Handshake message fragmentation

   Many servers will fail to process a handshake message that spans more
   than one record.  These servers will close the connection when they
   encounter such a handshake message.  HTTPS clients will commonly
   ensure against that by either packing all handshake messages in a
   flow into a single record, or by creating a single record for each
   handshake message.


3.  Protocol Fallback

   Despite it being nearly twelve years since the publication of TLS 1.0
   [RFC2246], around 3% of HTTPS servers will reject a valid TLS
   "ClientHello".  These rejections can take the form of immediately
   closing the connection or a fatal alert.  Intolerance to the
   following has been observed:

      Advertising version TLS 1.0.

      Advertising a TLS version greater than TLS 1.0 (around 2% for 1.1
      or 1.2, around 3% for greater than 1.2).

      Advertising a version greater than 0x03ff (around 65% of servers)

      The presence of any extensions (around 7% of servers)

      The presence of specific extensions ("server_name" and
      "status_request" intolerance has been observed, although in very
      low numbers).

      The presence of any advertised compression algorithms

   Next, some servers will misbehave after processing the "ClientHello"
   message.  Negotiating the use of "DEFLATE" compression can result in
   fatal "bad_record_mac", "decompression_failure" or
   "decryption_failed" alerts.  Notably, OpenSSL prior to version 0.9.8c
   will intermittently fail to process compressed finished messages due
   to a work around of a previous padding bug.

   Lastly, some servers will negotiate the use of SSLv3 but select a
   TLS-only cipher suite.

   In all these cases, HTTPS clients will often enter a fallback mode.
   The connection is retried using only SSLv3 and without advertising
   any compression algorithms.  (This is obviously an easy downgrade
   attack.)  Also, the fallback can be triggered by transient network
   problems, which often manifest as an abruptly closed connection.
   Since SSLv3 does not provide any means of Server Name Indication
   [RFC3546], the fallback connection can use the wrong certificate
   chain, resulting in a very surprising certificate error.


4.  More implementation mistakes

   Non-fatal errors in version negotiation also occur.  Some 0.2% of
   servers use the version from the record header.  Around 0.6% of
   servers require that the version in the "ClientHello" and record
   header match in order to respect the version in the "ClientHello".  A
   very low number of servers echo whatever version the client
   advertises.

   In the event that the client supports a higher protocol version than
   the server, about 0.4% of servers require that the RSA
   "ClientKeyExchange" message include the server's protocol version.

   Some 30% of servers don't check the version in an RSA
   "ClientKeyExchange" at all.


5.  Certificate Chains

   Certificate chains presented by servers will commonly be missing
   intermediate certificates, have certificates in the wrong order and
   will include unrelated, superfluous certificates.  Servers have been
   observed presenting more than ten certificates in what we assume is a
   drive-by shooting approach to including the correct intermediate
   certificate.

   In order to validate chains which are missing certificates, some
   HTTPS clients will collect intermediate certificates from other
   servers.  Clients will commonly put all the presented certificates
   into a set and try to validate a chain assuming only that the first
   certificate is the leaf.


6.  Insufficient Security

   Some 65% of servers support SSLv2 (beyond just supporting the
   handshake in order to upgrade to SSLv3 or TLS).  HTTPS clients will
   typically not support SSLv2, nor send SSLv2 handshakes by default.
   Of those servers, 80% support the export ciphersuites.  (Although
   about 3% of those servers negotiate weak ciphersuites only to show a
   warning.)

   Some servers will choose very small multiplicative group sizes for
   their ephemeral Diffie-Hellman exchange (for example, 256-bits).
   Some HTTPS clients will reject all multiplicative group sizes smaller
   than 512-bits while others will retry after demoting DHE ciphersuites
   in their "ClientHello".


7.  Acknowledgements

   Yngve Pettersen made significant contributions and many of the
   numbers in this document come from his scanning work.  Other numbers
   were taken from Ivan Ristic's SSL Survey.

   Thanks to Wan Teh Chang for reviewing early drafts.


8.  Normative References

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 3546, June 2003.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

SSL Labs: Added test for ephemeral DH parameters

2010-12-23T00:00:00+00:00

Ephemeral Diffie-Hellman key exchange (EDH or DHE, depending on where you look) allows two parties with no prior knowledge of each other to establish a shared secret. In SSL, DHE is used together with some method of authentication (most commonly RSA) in the handshake phase. Ephemeral DH is valued because it provides perfect forward secrecy -- the session keys cannot be recovered if the authentication method is broken (e.g., someone retrieves the server's private key).

DH parameters are typically generated at runtime. Because of that they are not very visible and are often forgotten during the testing. As of 1.0.69, the SSL Labs online test will examine the DH parameters and warn if they are too weak. The scoring system has been modified to take into account the strength of the DH parameters when they are used for key exchange.

Thanks to Adrian Dimcev and Brian Smith for their help with the research of DH parameter evaluation.

Detection of certificate chain issues in SSL Labs

2010-11-30T00:00:00+00:00

One of the recent additions to the SSL Labs test was the detection of various chain issues. The feature is still marked as experimental, and it will remain so until we conclude that the advice we give there is safe.

Certificate chains are a PKI feature that allows root certificate authorities to delegate the work of certificate signing. Roughly one half of all sites have certificates that are signed by a trusted CA. Such sites need only provide the server's certificate in the handshake. The remaining half (of the sites) uses intermediate certificates (usually only one; it is rare to see a site with more than one such certificate). Such sites need to provide all the intermediate certificates in addition to the server's certificate.

In our tests, we detect the following chain issues:

Missing intermediate certificates; When a site does not provide the necessary intermediate certificates, a trust path cannot be established. Generally speaking, we cannot distinguish that case from a certificate signed by a custom CA. However, some server certificates include the information on which intermediate certificates are required, and also where to obtain them. SSL Labs will attempt to fetch missing certificates. If the intermediate certificates are found, then it's very likely that a trust path will be established. In such cases, the test will issue a warning. If you site receives the warning you should reconfigure the server to add the missing certificates.
Certificate chains that are too long; Sites often include more certificates in the handshake than necessary. Of those, most include one extra certificate, and that is the actual trusted root certificate (which browsers already have in their storage). This last certificate is not needed for the validation process. Having an additional certificate in the chain wastes bandwidth and decreases overal performance slightly. A small number of sites will include a very large number of certificates as a result of misconfiguration. Such sites will typically suffer significant performance issues and need to be reconfigured.
Certificates given in incorrect order; According to the standard, certificates must be presented in the order in which they are needed. The main, server, certificate must come first, followed by the certificate that signed it, followed by the next certificate in the chain, and so on. A small number of sites does not get this order right. Most SSL clients will deal with this problem silently, but there is a small number of platforms that will give up.

Debian stable (Lenny) will support secure renegotiation

2010-11-17T00:00:00+00:00

Thijs Kinkhorst from the Debian Security Team wrote to me in response to my recent blog post Disabling SSL renegotiation is a crutch, not a fix. I am publishing his entire comment (with permission):

It's true that Debian stable still doesn't have an openssl which supports the
new protocol enhancement, but it's definately not a refusal to fix it. First
let me note that the fix is already in the upcoming release of Debian,
codename Squeeze. The current stable release, Lenny, does not have the fix
yet, but it is being worked on; an updated openssl is ready but the blocker
currently is that we may need to implement changes in some of the packages
using it. As usual Debian is very cautious with respect to updating its stable
release. It takes a while, and it would have been nice if the fix was out
sooner, but the combination of impacted software takes quite some time and
time is one of the most sought after resources in a volunteer project.

So just so you know that the issue has not been forgotten or ignored; it only
takes "a while" to get everything in order.

Update: The fix was released on January 6, 2011.

Private assessment option added to the SSL server test

2010-10-07T00:00:00+01:00

Everyone I know likes the SSL assessment tool on the SSL Labs web site, but many dislike the fact that their domain name may end up on one of the boards that display recent test history. I am assuming most wouldn't mind being on the "Recent Best-Rated" one, but you never know before the test how it's going to turn out.

That's why we now support the private assessment option. If you tick the checkbox underneath the domain name field, the test results will not be publicly revealed. Not only that, but the results will remain hidden for as long as the results remain cached.

If you intend to send links to hidden assessment results, make sure the URL contains the "hiddenResults=on" bit, which is needed to ensure that a new public test is run after the earlier results expire from the cache.

Disabling SSL renegotiation is a crutch, not a fix

2010-10-06T00:00:00+01:00

In the days that followed the discovery of SSL/TLS Authentication Gap, some sites (those that did not need renegotiation) were able to deal with the problem by disabling renegotiation in server code. With no support for renegotiation, gone was the danger of exploitation. Good for them.

The sites that did need renegotiation had to wait, first for the TLS working group to solve the issue on the protocol level, and then for their SSL library (or web server) vendors to support the enhancement. The TLS working group did a great job negotiating the fix. As for the vendors, some implemented the new feature quickly, some dragged their feet a little, and some (Debian) seem to refuse to fix the problem, leaving their users vulnerable.

To sum it up, today, almost a year after the initial public discovery, we have some servers that are still vulnerable, some that refuse to support renegotiation, and some that support the new standard for secure renegotiation.

So where is the problem, you might ask? If disabling renegotiation prevents exploitation, that's surely a good thing? Well, it depends on how you look at things. Try to look at the problem through the eyes of a browser developer. I was actually prompted to write about this problem by Yngve Nysæter Pettersen, who's part of Opera's security group. Opera wants to protect its users, and for that to be possible they need to know if a particular server supports secure renegotiation. If a server does, Opera can happily renegotiate whenever necessary. But if a server does not support secure renegotiation, you can make an argument that Opera should refuse any renegotiation attempts.

The servers that support secure renegotiation indicate so during the SSL handshake phase, and everyone's happy and secure. The issue is with the servers that disable renegotiation, because they provide no indication of their security status. Some are insecure, while some aren't. Without knowing, browsers can't do anything. They can perhaps only inconvenience users and force them to manually configure protection levels.

While it is possible to test for insecure renegotiation (SSL Labs does it), the test is indicative but not conclusive -- there is no way to test for server-initiated renegotiation. Besides, it's not reasonable to expect browsers to test every SSL site they encounter.

My point is those that disabled SSL renegotiation must nevertheless implement the proper fix as soon as it becomes available for their platform. Patching is slow enough as it is, and we don't need any further distractions to slow us down.

Qualys SSL Labs releases raw data from the Internet SSL survey

2010-10-05T00:00:00+01:00

About two months ago, Qualys SSL Labs published the results of an Internet-wide SSL survey. We said that we would make the raw data available, and today we are following up on that promise. (By the way, we realize that two months is a long time, but we couldn't complete the process faster on this occasion. We hope to make future releases pretty much as soon as we obtain the data. As you may remember, our plan it to make our survey a quarterly event from 2011.)

The raw data contains the SSL assessment results of about 850,000 domain names (out of about 120M we inspected). The main file (1.2 GB 120 MB compressed, 3.5 GB 800 MB uncompressed) is a dump of our PostgreSQL database in CSV format. We include in the download a simple PHP script that iterates through all the rows, which means that you can consume the data directly. Alternatively, you can put the data back into the database and use SQL to run ad-hoc queries (we provide the schema along with the import instructions).

The database schema contains 63 fields that generally parallel the information you would obtain from the SSL Labs online test. The complete original certificate chain is included, which is handy if you want to look into the aspects we didn't. We chose not to release certain sensitive data: the information on the low entropy private keys, renegotiation support, and HTTP server signatures was removed.

This is what you need to do to obtain the data:

First, make sure that our terms and conditions are acceptable to you. At the core, we use the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported licence, but there are a few additional requirements. For example, we ask the obvious -- that you don't use the data for illegal activities. The other requirements are just common sense. (Please do read the entire file, however.)
Second, send us an email (username "ivanr"; domain name "webkreator.com"), introduce yourself, and tell us how you intend to use the data. We will then send you back the download instructions. We need this second step to give us an idea if the data is used, and how.

Update: We are removing the certificate chain data from the database until we confirm that we are legally allowed to redistribute it. If you need such data in the meantime, retrieve it directly from the servers.

Internet SSL Survey 2010 is here!

2010-07-29T00:00:00+01:00

Since joining Qualys in May, I spent virtually all my time perfecting the SSL Labs assessment engine and looking at how SSL is used on the Internet (HTTP servers only this time). I wrote about this work on a couple of occasions already:

Now, after a couple of months of hard work, the slides are finally ready. Here they are, without further ado:

Qualys Internet SSL Survey 2010 v1.6 (PDF, 3.2 MB)

I will present the results at Black Hat later today (10am PDT). Looking forward to seeing you there.

SSL Labs 1.0.63: Detection and reporting of certificate chain issues

2010-07-13T00:00:00+01:00

The latest revision of the SSL Labs assessment engine (v1.0.63) adds several improvements in the area of certificate chains:

The engine will now try to download missing intermediate certificates. Although sites are supposed to configure complete certificate chains, many forget to do that, and their sites fail to work properly as a result.
Chain size and length are reported in the user interface, which makes it easy to spot ridiculously long chains.
Incomplete chain certificates are reported. This is the case where the engine was able to locate missing intermediate certificates elsewhere and establish trust.
Certificate chains that are too long are reported. It turns out that quite a few sites have chains that are longer than necessary. Such setups not only waste bandwidth, they make the overall site performance worse too.
Incorrectly ordered chains are reported too. Although most browsers will deal with this problem, some SSL clients are sensitive to the issue.

SSL Server Survey: what data are we collecting?

2010-07-02T00:00:00+01:00

As you may have heard by now, Qualys SSL Labs is conducting a large-scale survey of SSL servers. Naturally, the focus of such survey is to collect as much data as possible, then mine it to obtain useful information.

This is the data we are currently looking at collecting:

Certificate information

Common name
Is the common name a wildcard?
Alternative names
Validity period (not before and not after)
Revocation information (CRL and OCSP)
Public key algorithm and size
Signature algorithm
Certificate chain: how many certificates are there in the chain?
Certificate chain: Are the chains complete and well formed?
Certificate chain: How long is the certificate chain?
Certificate chain: keep complete raw data for subsequent deeper analysis
Is there support for Server Gated Cryptography (both Netscape and Microsoft flavours)?
Validation type (DV, IV/OV, EV)
Issuer information
Is certificate trusted (and why not if it isn't)?

Protocol support

SSL v2
SSL v3
TLS v1.0
TLS v1.1
TLS v1.2

Cipher suite support

Test for all known cipher suites (200+ of them)
Cipher suite order preference test

Other

Test support for both Insecure and secure renegotiation
SSL session resumption support
Debian weak RNG weakness
Retrieve HTTP server signature
Presence of the Strict Transport Security response header
TLS version intolerance tests
Grade, according to the SSL Rating Guide 2009

SSL Server Survey: So what's with the 22M invalid certificates claim?

2010-07-02T00:00:00+01:00

After I talked about my research in a Black Hat Preview webcast last week, a number of people rushed to tell me that there can't be 22M invalid certificates in the world. Some got in touch directly, some just talked about it, and, in one instance, a company managed to issue a press release (!) to urge me to clarify my statements.

"Surely I was mistaken", they said, because "there's only about 2M certificates sold by commercial certificate authorities? Something does not add up." Of course it doesn't.

The short answer is that they've generally focused on the wrong aspect of the study and that, in fact, I made no such sensational claims. So what is the real story?

The goal of the SSL Survey is to understand how SSL is used in real life. We generally know what is the right way to configure and deploy SSL, but are the best practices followed, and by how many sites? This sort of analysis is difficult to pull off because you have to know what to test. (The testing itself is not so difficult for us, because we already have a robust assessment engine running on SSL Labs.)

Here are the possible approaches to discover publicly-available SSL servers:

Scan all IPv4 address space. This is only possible because of the still-prevalent deficiency of most SSL deployments that they require a dedicated IP address to operate.
Crawl the Internet to discover the SSL servers that appear in all the hyperlinks in the world.
Analyse the domain name space. One option is to obtain the lists of all domain names registered under a specific TLD, which is slow and cumbersome, but possible. Another option is to use a list such as Alexa's top 1M most popular sites, which is a much more palatable approach.
Use a browser toolbar (or a similar service) to collect the hostnames the users are visiting. This is the only approach that will reveal internal SSL servers, although I doubt that would be very useful.

For my study I opted to analyse the domain name space. The other approaches were either not feasible, would take years, or simply cost too much. We'd love to collaborate with the organisations that have the data that we need, but that hasn't happened yet.

From VeriSign's reports we know that there's about 193M registered domain names in the world, and I managed to obtain a list of about 119M to start with (all .com, .org, .net, .biz, .us, and .info domain names). The idea was to first perform a series of lightweight tests (there are so many domain names!) to give us an idea which domain names are worth looking at in depth. Here are the results:

92M domains are active on port 80 or port 443
33M domains have port 443 open
22.65M domain names run SSL on port 443
On 0.72M domain names certificates match the domain name

Now it becomes clear where the 22M invalid certificates number comes from. If you take the number of domain names that responded on port 443 and subtract the number of certificates that matched the domain name on which they reside (0.72M), you get about 21.93M domain names that do not have valid certificates on port 443. This number is not very important and certainly not ground-breaking. It's a by-product of the methodology whose end-goal is to find something else.

The important number is the 720,000 certificates whose names do match the domain names on which they reside. For each of those, someone made an effort to match the names, and those are the servers that are worth investigating further.

Sadly, some people chose to focus on the numbers that help make an interesting headline, but which aren't very interesting from the research point of view. The reason we have so many domain names that do not have proper SSL certificates installed is that most of them are not _intended_ to have them. Multiple domain names will point to the same IP address and, thus, to the same SSL server. (Remember, virtual SSL hosting is not yet mainstream.) The difference in numbers is because of the widespread use of virtual web hosting, which is available for non-SSL sites, but not yet for SSL sites. You can host a million plain-text web sites on a single IP address, but if you want a million secure sites, you'd need a million IP addresses.

Internet SSL Server Survey at Black Hat USA 2010

2010-07-02T00:00:00+01:00

Ever since starting SSL Labs I wanted to know and understand how SSL was deployed in real life. The only way to find out is to perform an assessment of many (most?) public SSL servers. That's a lot of work, but, as with everything else, if you persist and make continuous progress you eventually get there. This survey has been in the making for about a year and a half now.

The survey consists of three major pieces:

The first piece is assessment methodology, which is covered by the SSL Rating Guide. My goals for the guide were two-fold: provide a comprehensive SSL server analysis, but also make the end result easy to understand. I didn't want only SSL experts to find the guide useful.
The second piece is the assessment tool, which implements the methodology. That's the SSL Labs online assessment tool, which has been running for a year now. The good aspect of doing things slowly is that it makes the end result better. This is especially true in this case, because it's one thing to read the RFCs -- making something work as expected in real life and interoperate with other implementations is much more difficult.
The third and final piece is the scan of as many public SSL servers we can find, which is what we are focusing on right now.

The first results of our study will be published at my talk at Black Hat USA 2010 later this month. The good news is that all our work will be publicly available, and that we intend to continue to run the survey in regular intervals.

SSL Labs assessment engine v1.0.59 improvements

2010-06-17T00:00:00+01:00

The latest version of the SSL Labs assessment software (1.0.59) is now online, and it includes the following improvements:

Cipher suite preference test, which tells you if servers pay attention to which cipher suites they use (or merely use the first suite offered by a client)
Clear cache feature, which clears cache and allows for a quick check-fix-check cycle
Detect Strict-Transport-Security header in response, which indicates STS support
Session resumption test, which checks for the performance optimization after the initial full handshake
TLS version intolerance test, which tests how servers react to not-yet-released versions of TLS
Prefix handling changes; this test will now take into account if the tested domain name (with and without prefix) points to a particular server. It will also relax the check for 2nd-level domain names (e.g., secure.example.com)

Enjoy!

Qualys acquires SSL Labs

2010-06-15T00:00:00+01:00

I am late in writing about this, but SSL Labs is now part of Qualys. If you came to this blog entry through the SSL Labs home page, then you already know the news -- it's obvious from the change to the logo. If not, you can visit the site now to see the logo and the new colours.

Apart from the visual changes, there are no plans to change the concept of the site. The idea -- to research SSL -- remains. I do expect that I will have far more time to spend on my SSL-related research in the following months. In fact, I spent the best part of the last month and a half working on a big related project. It's something I've wanted to do for a long time.

But now is not the time to talk about that. I will share my progress with you in the days that follow.

Secure renegotiation test added to SSL Labs

2010-05-25T00:00:00+01:00

When the SSL and TLS authentication gap problem was initially discovered (in November 2009), there wasn't much anyone could do about the vulnerability. You could disable renegotiation altogether, which only worked if your site did not depend on the feature. Thus my initial test focused on testing whether renegotiation was allowed.

A couple of months ago, in February, the TLS Working Group published RFC 5746, Transport Layer Security (TLS) Renegotiation Indication Extension, to address the authentication gap. The RFC adds a secure renegotiation mechanism to both SSL and TLS. With a couple of parties supporting the RFC now (you can follow the status of the various patches and updates at this page at PhoneFactor), I thought it would be a good time to update my SSL Labs code so that the tests accurately report server configuration.

SSL Labs will now not only correctly discover if secure renegotiation is supported, but it will give a nice green cheer every time it sees it on a site.

Special offer: 25% off ModSecurity Handbook until May 31st. Enter discount code MSHBIRY671XHL1V at checkout.

Breaking SSL: Why leave to others what you can do yourself

2010-05-21T00:00:00+01:00

I will be giving my SSL talk at the ISSD conference later today (ISSD stands for International Secure Systems Development). Here's the presentation:

Breaking SSL: Why leave to others what you can do yourself (PDF, 400 KB)

It's virtually the same talk as my Rendering SSL Useless one from a couple of months ago, with slight reorganisation and some slides nicer.

Deep protocol and cipher suite testing in SSL Labs

2010-05-14T00:00:00+01:00

SSL has a usability problem when the negotiation of a secure communication channel fails: the user is left with a cryptic error message and his head to scratch. Let's say that you are someone whose browser is not particularly equipped in the cryptography department and that you want to connect to a high-security site. Your browser fails to negotiate a SSL session and tells you that "SSL peer was unable to negotiate an acceptable set of security parameters" (Firefox). The problem is that there is no way for the site to communicate the problem to you and explain how you can fix it.

It's a hard problem to solve. SSL could be extended to allow a custom redirection URL to be dispatched to the user who is unable to negotiate good-quality encryption, leading him to a non-SSL page with more information. But such a page could be intercepted and modified (think MITM and sslstrip), allowing an attacker to take control over the user's session. Even the redirection URL itself might be intercepted and modified in transit. The same could happen with a custom text message.

Although the failure to negotiate a secure connection is very rare, there are some sites that find it unacceptable. They will thus accept weak protocols and cipher suites on the SSL level, reporting the problem via HTTP. I think this approach is more secure because in many cases using a weaker protocol is better than no communication security at all.

It is inconvenience for me, though, because there is no standard way in HTTP say that you are, in effect, politely refusing to talk to someone. To detect the situation, I have to look for clues in HTTP responses. Here's what NetScaler responds with:

HTTP/1.1 500 Internal Server Error
Connection: close
Content-Length: 510
Content-Type: text/html

<html><body><b>SSL Alert</b><p>The browser and the web-site cannot communicate securely because there are no common encryption algorithms.</p><p>Please try the following:</p><p>- Check the SSL protocol settings on the browser for SSLv3/TLSv1 protocol support.</p><p>- The secure web-site may be using high-strength encryption algorithms(128 bit).<br>  Check the SSL settings on your browser, if it supports high-strength encryption algorithms.</p><p>- Upgrade your browser to latest version.</p></body></html>

I already did that last year for SSLv2 protocol detection, but a couple of days ago I further improved the assessment engine adding support for deep cipher suite testing. SSL Labs now detects the default NetScaler error response delivered for both weak protocols and weak cipher suites. If you want to see an example, have a look at the Amazon.com results.

Speaking on SSL at OWASP AppSec Research in Sweden

2010-04-27T00:00:00+01:00

I will be speaking at the OWASP AppSec European conference in Stockholm, Sweden. I am really looking forward to attending, too. I had a self-imposed year-free-of-security, and I miss it. My talk will be about SSL -- an improved version of the talk I gave to OWASP London earlier this year.

Firefox extension installation process vulnerable to MITM attack

2010-02-09T00:00:00+00:00

Adrian Dimcev made an important discovery the other day: the Firefox installation process is vulnerable to MITM attack. If a man in the middle is able to intercept the traffic of someone installing an extension, he will be able to get the user to install something else. Firefox is supposed to check the integrity of the extensions before it installs them, but it seems something somewhere broke, and the check is no longer in place.

This problem will be fixed in the next release (it has been fixed in the repository, it seems), but the fact remains that the installation process is seriously misleading. Looking at the user interface alone, the impression is that the entire installation process is carried out ever SSL. Even worse, the main domain name where the extensions are "stored" uses an EV certificate, so you are made to feel super-safe. In truth, the extensions are downloaded over HTTP from who-knows-where.

SSL Labs using Firefox 3.6 CA certs

2010-01-25T00:00:00+00:00

With Firefox 3.6 out, I took the opportunity to upgrade the CA root database. Up until earlier today SSL Labs used the Firefox 3.5.1 list, which has 142 certificate authorities on it. The new version of Firefox supports 155 certificate authorities and, now, SSL Labs does too.

After being prompted by Adrian Dimcev, I also added the support for a couple of obscure EXPORT 1024 cipher suites. Thanks Adrian!

How to render SSL useless

2010-01-14T00:00:00+00:00

Later today I will be presenting at the OWASP London meeting. The title of my presentation is How to Render SSL Useless, and I will be talking about the recent issues with SSL/TLS, my work at SSL Labs, as well as listing Top 11 SSL deployment mistakes that render SSL useless.

Here's the presentation:

ivan_ristic-how_to_render_ssl_useless.pdf

Testing for SSL renegotiation

2009-12-15T00:00:00+00:00

Edit: Please note that the test described here works only with OpenSSL version that was not patched to deal with insecure renegotiation. I recommend that you download version 0.9.8k directly from the OpenSSL web site and compile a special binary to use for testing.

Someone asked me how to test for SSL connection renegotiation, so I thought I would also write here for the benefit of everyone. Testing is easy provided you have access to an un-patched version of OpenSSL. To test, you will use the s_client tool (you'll type the bits in blue):

$ openssl s_client -connect www.ssllabs.com:443
[snip... a lot of openssl output]
---
HEAD / HTTP/1.0
R
RENEGOTIATING
28874:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530:

The idea is that you connect to an SSL server and start by typing the first line of a request. You then type a single uppercase letter R on a single line, which tells OpenSSL to ask for renegotiation. I am aware of the following outcomes:

Your HTTP request completes, which means that renegotiation is enabled
You get an error (one such possible error is shown in the example above), which means that renegotiation did not work
The connection blocks and timeouts after a while, which is how OpenSSL 0.9.8l deals with renegotiation.

Of course, a SSL Labs report will tell you whether a particular server supports renegotiation.

Clientless SSL VPN products break the Web

2009-11-30T00:00:00+00:00

Dan Goodin, of The Register, pointed me to a very interesting advisory issued today that again confirms that convenience trumps security, every single time. This particular problem concerns the so-called clientless SSL VPN products, which basically work like a reverse proxies on steroids. When you're on the road, you log into one of these devices and they provide you with a "window" through which you can access the sites you'd normally only see on your own network. Now, I've known about these products for a long time but, never having actually used one, I didn't think much about how they work. Now that I know, I am terrified. They basically map all the sites you're accessing into a single super-site, rewriting everything behind the scenes to maintain the illusion of a browser within a browser.

For example, if your internal's site address is internal.example.com and your clientless SSL VPN's address is vpn.example.com, while you're on the road you access your internal site through https://vpn.example.com/internal.example.com/.

It's pretty slick in how it's very convenient and works with any browser, but it kills the same-origin policy. A single rogue web site that you access through this VPN window is able to take over all your sessions, interact with all your sites and monitor whatever is that you're doing.

And the best part? The problem has been known since at least 2006. You can get more information from Dan's article or from the advisory.

Shameless self-promotion: ModSecurity Handbook, the guide to the world's most popular web application firewall, is now available for instant download.

Initial test for SSL renegotiation added to SSL Labs

2009-11-17T00:00:00+00:00

I've added an initial implementation of the test that determines if an SSL server is vulnerable to the Authentication Gap MITM attack. At this point the assumption is that no server supports the safe renegotiation TLS extension, which means that a warning is displayed if renegotiation is found to be supported.

In the following days, as the implementations of the safe renegotiation TLS extension start to arrive, I will improve the test to take that into account.

Not just CSRF: SSL Authentication Gap used for credentials theft

2009-11-14T00:00:00+00:00

Most people associate the recent SSL Authentication Gap vulnerability with mild CSRF, but a couple of days ago Anil Kurmus published an improved attack technique that enabled him to access victims' encrypted data streams. He wrote a proof of concept that could have been used to retrieve someone's Twitter credentials. Twitter's SSL servers no longer support renegotiation so the attack no longer works, but the same principle will still work with other sites. Anil's attack technique was posted to Full Disclosure last Wednesday, but it was ignored. It was subsequently picked up by Dan Goodin from The Register.

In researching the possible attack vectors made possible with the SSL authentication gap problem, most focused on trying to use the credentials included with hijacked requests (i.e., session cookies or Basic Authentication credentials). Anil realised that, although he was not able to decrypt the hijacked requests he was still able to include them as payload in arbitrary requests of his own. So all he needed was a site that has some sort of publishing functionality that can be used to reveal data. With the Twitter attack, he simply published the hijacked data as his Twitter status message.

The attack works because the hijacked information is used in a parameter of the attacker's request. Below is a partial attack example to describe the concept:

POST /statuses/update.xml HTTP/1.0
Authorization: Basic [attacker's credentials]

status=POST /statuses/update.xml HTTP/1.1
Authorization: Basic [victim's credentials]

This attack technique is best suited to exploit APIs protected using Basic Authentication. It will work equally well for session hijacking, but hijacking the credentials in the case of sites that use form-based authentication may be more difficult due to the presence of the ampersand characters in victims' data streams.

Marsh Ray (who discovered the SSL authentication gap issue), hinted that information theft might be possible in a comment to Eric Rescorla's blog post, but he said he was more interested in fixing the problem rather than seeking interesting ways to abuse it.

SSL and TLS Authentication Gap vulnerability discovered

2009-11-05T00:00:00+00:00

A serious vulnerability has been discovered in the way web servers utilise SSL (and TLS, up to the most recent version, 1.2), effectively allowing an active man-in-the-middle attacker to inject arbitrary content into an encrypted data stream. Both the Apache web server and the IIS have been found to be vulnerable.

The problem is with the renegotiation feature, which allows one part of an encrypted connection (the one taking place before renegotiation) to be controlled by one party with the other part (the one taking place after renegotiation) to be controlled by another. A MITM attacker can open a connection to an SSL server, send some data, request renegotiation and, from that point on, continue to forward to the SSL server the data coming from a genuine user. One could argue that this is not a fault in the protocols, but it is certainly a severe usability issue. The protocols do not ensure continuity before and after negotiation.

To make things worse, web servers will combine the data they receive prior to renegotiation (which is coming from an attacker) with the data they receive after renegotiation (which is coming from a victim). This issue is the one affecting the majority of SSL users.

The following example demonstrates how the flaw can be exploited by an attacker to send an arbitrary request using the authentication credentials of a victim. The red parts are sent by the attacker and the blue parts are sent by the victim.

GET /path/to/resource.jsp HTTP/1.0
Dummy-Header: GET /index.jsp HTTP/1.0
Cookie: sessionCookie=Token

The good news is that, although the attacker can execute an arbitrary request, he will not be able to retrieve the corresponding response. On the negative side, the client will see something different from that what she requested.

You can see that GET attacks are essentially trivial to execute. To date, no one has claimed a successful execution of a POST request using this flaw. Until someone does, that means that an application that only makes changes in response to POST requests will probably not be vulnerable. Further, an application not vulnerable to CSRF attacks will probably be safe too, because the attacker won't be able to generate or predict the token required for the request to go through.

Mitigation options:

If you can, disable renegotiation. There isn't normally a configuration option to do this, but patches are being developed and will be available soon. The majority of web sites do not use renegotiation so disabling it won't be a problem. Those that do will need to make changes to their sites to make them work without it.
Use a web application firewall to monitor the contents of all request headers to spot what seems like an embedded HTTP request line. The good news is that the embedded request line will not be obfuscated, making it easier to detect. I do not believe that this advice can help the bypass of the client certificate authentication, though.
If you can, monitor all connections that make use of the renegotiation feature. That won't help you if renegotiation is an integral feature of your web site, but it may do if it is rarely used.

Further information:

Marsh Ray's blog post (Marsh discovered the problem a couple of months ago) contains a detailed description of the problems in the attachment.
The post by Martin Rex to the TLS mailing list that prompted public disclosure.

Entropy on a USB stick

2009-10-01T00:00:00+01:00

If you care about security then you care about encryption. If you care about encryption then you know how important it is to have access to a good entropy source. (Or you should know. Not many people talk about entropy. I guess that it's something not very exciting to talk about.) Perhaps there are other similar devices and this is old news to some, but I was pleasantly surprised to learn that entropy is now available for little money, on a humble USB key:

The Entropy Key is a small, unobtrusive and easily installed USB stick that generates high-quality random numbers, or entropy, which can improve the performance, security and reliability of servers.

Get it from Simtec Electronics.

Analysis of Elliptic Curve support in current browsers

2009-09-29T00:00:00+01:00

In my previous post I mentioned Adrian Dimcev, who helped me get Elliptic Curve detection right, in SSL Labs. He has now posted a detailed analysis of the current support of elliptic curve cryptography across browsers:

tls.woodgrovebank.com meets the browsers

I recommend that you read this highly informational post if you have even a slight interest in TLS.

SSL Labs: Improved Elliptic Curve and TLS 1.2 detection

2009-09-22T00:00:00+01:00

The latest version of the SSL assessment software running on SSL Labs features much better detection of the SSL servers that use Elliptic Curve cryptography, TLS 1.1 and TLS 1.2. Windows Server 2008 leads when it comes to these technologies and Microsoft's test server (tls.woodgrovebank.com) demonstrates that very well. Sadly, there's currently no browser that can talk to the Windows Server 2008 in a way that uses all the capabilities that are on offer. Even IE8 has some of the high-end features disabled and gets some others wrong.

I must mention Adrian Dimcev, who pushed me to get this work done. He worked relentlessly to figure out the exact combinations of handshake bits (literally) that produce desired results. I've urged Adrian to describe his findings for everyone to read, and let's hope that he'll do that. In the meantime, his recent blog post provides a bunch of useful information on TLS 1.2.

SSL Threat Model

2009-09-09T00:00:00+01:00

SSL is easy to use but also very easy to use incorrectly. The ecosystem, which is built of the specifications, the implementations, the CAs and the PKI, is full of traps, each of which is very easy to fall into. Once I started to spend significant time thinking about SSL I set out to build a model of the ecosystem, for my own education and to ensure that I understand it all. That's how I arrived to the SSL Threat Model. The image is too big to include here, but just click on the link below to get it:

SSL Threat Model (PNG, 65 KB)

I do understand that many of the elements in the model need explanations, but the diagram is all I have at the moment. As a matter of fact, the diagram has been sitting in my virtual drawer for months in the hope that I would eventually accompany it with some documentation. But seeing that the documentation is not going to happen any time soon, I decided to go ahead and publish the diagram alone.

Feel free to post comments here, though!

Two bugs in mod_sslhaf fixed

2009-09-04T00:00:00+01:00

I fixed two bugs in mod_sslhaf (my passive SSL fingerprinting module for Apache; see my previous blog post for details), which means that you need to upgrade if you're using it:

Pure SSLv2 access was ignored due to a badly interpreted version number (SSLv2 uses a different byte order).
There was a problem with sites that do not use SSL, which would cause Apache to stall.

Everything seems to be in order now.

SSL Labs: a batch of small improvements

2009-09-03T00:00:00+01:00

I love when a project enters the phase where you're mainly concerned with improving upon what already works! I had some time yesterday and today to spend on SSL Labs so I used the opportunity to tweak the software a bit. The changes are as follows:

Successful assessments are now cached for 24 hours.
Unsuccessful assessments are now cached for 15 minutes.
Display complete certificate chains, and make clear which certificates are trusted.
Do more to detect SSLv2 error responses (a polite way for a site to say that it does not support SSLv2).
Use colours and tags ("weak", "insecure", "confusing") to point to the bits in a configuration that are bad or can be improved.

I also fixed a bug or two, but that's not very important.

Is RC4 safe for use in SSL?

2009-08-28T00:00:00+01:00

I received a rather interesting and informative couple of emails last week from Paweł Krawczyk, who wanted to make a point how RC4 is still safe to use in SSL. I thought that his comments would be of interest to a wider audience, so here they are (with permission):

[...] TLS_RSA_WITH_RC4_128_MD5 [...] is extremely widespread among commercial servers. Main reasons are 1) it's default preferred cipher in most versions of IIS, 2) these two algorithms are absolutely fastest and least CPU-intensive.
However, because there are known cryptoanalytic attacks against both RC4 and MD5, this ciphersuite is notoriously reported as "weak" by some pentesting tools and teams.
This is not true or at least not accurate, as the specific usage of RC4 and MD5 - in SSLv3 with 128 bit key - has no known and working attacks. That's one reason why PCI-DSS v1.2 now doesn't list any specific algorithms for SSL but instead just says you should use "strong" ones. And widespread usage of TLS_RSA_WITH_RC4_128_MD5 among financial organisations seems to confirm the interpretation that it's still considered a strong ciphersuite.
On the other hand NIST SP 800-52 doesn't allow neither RC4 or MD5 because they're not FIPS-approved algorithms, with one exception - connecting in client mode to external, commercial systems with this specific ciphersuite enabled. Which seems to set the balance quite even, because SP is only binding for US federal agencies.

And...

There are two reasons why the new attacks do not apply to RC4-based SSL. First, SSL generates the encryption keys it uses for RC4 by hashing (using both MD5 and SHA1), so that different sessions have unrelated keys. Second, SSL does not re-key RC4 for each packet, but uses the RC4 algorithm state from the end of one packet to begin encryption with the next packet. The recent techniques of Fluhrer, Mantis and Shamir thus do not apply to SSL.

Further resources:

RSA Security Response to Weaknesses in Key Scheduling Algorithm of RC4
Forgery and Partial Key Recovery attacks on HMAC and NMAC using Hash Collisions (PDF; concludes HMAC-MD5, HMAC-SHA1 - No immediate practical threats)

Black Hat 2009 SSL Review: Breaking the Myths of Extended Validation SSL Certificates (Alexander Sotirov and Mike Zusman)

2009-08-07T00:00:00+01:00

Sotirov's and Zusman's talk (the paper and the slides available for download) is a practical exercise in breaking the assurance provided by EV certificates, building on the discovery Collin Jackson and Adam Barth made in their paper Beware of Finer-Grained Origins:

Extended Validation. The browser’s scripting policy does not distinguish between HTTPS connections that use an Extended Validation (EV) certificates from those that use non-EV certificates. For example, Pay- Pal serves https://www.paypal.com/ using an EV certificate, but a principal who has a non-EV certificate for www.paypal.com can inject script into the PayPal login page without disrupting the browser’s Extended Validation security indicators...

The above has the following implications:

EV sites generally use components that are delivered from other non-EV SSL places. Thus, if you have a valid non-EV certificate in the name of the server used for the component delivery, you can subvert the EV site.
Sotirov and Zusman also point out that browsers don't perform SSL certificate pinning, happily accepting a request from a site with an EV certificate, followed by a request from the same site using another certificate. That allows for what they call SSL Rebinding. Through the same-origin policy, a subverted document delivered with a non-EV certificate can assume control of an EV site.
They further point that it is possible to perform SSL cache poisoning, which is a side-effect of the caching subsystem in browsers being separate from the security system. For browsers, a file from a non-EV site is the same as a file from a EV site:
1. A user is somehow lead into requesting a file supposedly from an EV site (e.g., a script file), but the file is delivered by an attacker performing a MITM attack and using a valid non-EV certificate.
2. The user goes to the real EV site, at which point his browser will attempt to refresh the previously cached script file.
3. If the EV site responds with an 304 (Not Modified) response, the browser will continue to use the subverted version of the script.

Sotirov and Zusman offer a number of suggestions to fix the above problems, but admit that most of them are not likely to happen. The problem here is that it is the browser vendors who should be pushing the security envelope (no one else is in a position to do it), but doing so would break sites and the vendors, who are primarily focused on winning market share, won't risk breakage. The only realistic solution seems to be to make it possible for sites to elect to be more secure so that, in time, we can upgrade to a more secure Internet.

I still maintain that a comprehensive solution (in a way similar to that I proposed in the Secure Browsing Mode document) is the best way forward. Band aids can only do so much and, for once, we need to do a job properly.

Black Hat 2009 SSL Review: More Tricks For Defeating SSL In Practice (Moxie Marlinspike)

2009-08-05T00:00:00+01:00

Moxie Marlinspike has a story to tell, and it's a story about SSL implementation flaws. His talk at Black Hat 2009 (get the slides and the movie from Black Hat Archives) is a continuation of his previous activities, which go way back, as early as 2002 (or something). I liked this talk, because it was delivered in a low key, here-is-what-I-discovered, way.

You first learn about the chained certificate validation flaws from the past, which were possible basically because X.509 is complex and programmers don't understand it. It was possible to exploit such flaws with the use of any valid certificate.
Moxie wrote and published his first SSL tool, sslsniff, because Microsoft claimed the chained certificate validation flaws could not be exploited. This tool automates the exploitation and makes MITM attacks really simple (as most Moxie's SSL tools do).
Next comes sslstrip, again a MITM tool, which relies on the fact that most people first browse using plain-text and let sites guide them to SSL. The tool strips away the links to SSL, leaving the user to communicate via plain-text.
The new stuff is about the same problem Dan Kaminsky pointed out in his talk (but independently discovered), which is that most SSL implementations are vulnerable to NUL-byte attacks. As a result, it is possible to get a CA to sign a certificate that effectively allows you to impersonate a web site you do not own. Combining this attack with a wildcard certificate, you get a certificate that can be used to impersonate any web site.
Moxie further discovered that it was possible to interfere (from a MITM position) with OCSP certificate validation to prolong a life of a revoked certificate.
Even worse, he discovered that it was possible to use a NUL-enriched wildcard certificate to subvert the Firefox and Thunderbird update mechanism.

The good thing about implementation flaws is that they are reasonably quick and easy to fix. The first issue is old news, so it's not a problem any more. The new flaws (#4, #5 and #6) are either fixed (I know they were fixed in Firefox) or will be fixed soon. You can make sure you're using a version of the browser that is not vulnerable. There's going to be a lot of people using older browsers, who are going to remain vulnerable. To help them, it is the CAs who are going to have to make sure they don't issue any more rogue certificates.

Although sslstrip is old news, I am worried about the fact that people can't recognise when a connection (to a web site) is insecure. No, scratch that. Why should people need to recognise that? I know how to and I do, but that's only out of necessity. I am really more worried about the fact that it's necessary to think about such things at all. Web sites should just be secure, period.

Short term, EV certificates help. That really means that they help me and you, but I don't believe they help normal (i.e., non-security) people. Can we do anything to help them? A solution comes to mind, and it consists from two parts:

Use only SSL and make plain-text connections impossible.
Refuse to connect to web sites that do not have valid certificates.

Black Hat 2009 SSL Review: Black Ops of PKI (Dan Kaminsky)

2009-08-04T00:00:00+01:00

SSL was again in the centre of attention at Black Hat USA this year (2009). I say SSL, as do many others, but most of the discussion wasn't about SSL but, rather, about the technologies on which it relies. I will cover the Black Hat SSL talks in a series of blog posts, the first of which I publish today.

Dan Kaminsky's talk (get it here as a QuickTime movie) has several very interesting points, but it fails on delivery. When you take the interesting bits out, the rest is a strange mixture of ranting, sarcasm, irrelevant detours and unproductive technology bashing, which I didn't enjoy. Here's my summary of what Dan said:

Humans are imperfect.
We generally care first about getting things done, with security always an afterthought (if we're lucky).

If you want to be more specific, that translates to:

We don't know how to write secure code.
We are using tools and languages that are inherently insecure (e.g., the C programming language, with its buffer overflows and NUL-terminated strings).
Specifications are often ambiguous.

It's hardly news. My biggest complaint to Dan's talk (his attitude aside) is that he doesn't tell us how to improve things. He mentions DNSSEC as a possible improvement, but how do we guarantee that DNSSEC and its implementations do not suffer from the same problems that plague our software today?

The very interesting new points (what Dan really said), are as follows:

MD2 is insecure, yet we are slow in retiring it. There's even one commonly deployed root certificate signed with it. This one MD2 signature could be abused through an preimage attack. Such an attack is not practical today, but it may become practical soon enough for us to be worried. Dan apparently orchestrated a synchronised removal of MD2 from the popular programs and libraries, which is great.
CAs, programs and libraries all have issues with input validation, the result of which is that it's possible to get a certificate with a NUL byte in the common name. This is the issue that was independently discovered by Moxie Marlinspike, who also spoke at Black Hat. (I will discuss his talk in a subsequent post.) The differences in the interpretation of such common names allow such certificates to be abused so that you get a certificate that works for the domains you do not own. It's even possible to get a wildcard certificate that works for all domain names (in some browsers). This problem is being fixed. (As an aside, Dan doesn't mention the alternative names field, so we don't know if it's vulnerable too. It would be very ironic if everyone would fix the problems in the common name field, yet leave the alternative names vulnerable. Perhaps that's an opportunity for a talk next year.)
It is possible for certificates to have more than one common name (e.g., the domain name, in the context of SSL servers), but its implementation-specific which one will be used.
Ambiguities in ASN.1 (which is used to encode certificates) and flaws in ASN.1 implementations can be used to insert OIDs that some consumers interpret as common names, but others don't.

Improved SSLv2 detection in SSL Labs

2009-08-03T00:00:00+01:00

Update (5 Sep 2012) Someone wrote to me recently to point out that accepting SSL v2 connection requests is insecure, even if the intention is to only display an error message. This is, of course, correct. I come to the same conclusion long time ago, but I had forgotten that I had left behind a written trail in favour of this technique.

One of the benefits of public testing is that you get exposed to, well, real life. I love that phase of development because you generally get to polish your code until it is perfect. Thus, after my SSL server assessment service went online, I monitored its performance closely, expecting to encounter a number of unforeseen cases, or cases that I didn't handle well.

One such area was SSLv2 detection. My first approach was to simply detect the cases where servers accept to negotiate a SSLv2 connection, but I soon discovered two edge cases:

Some servers have SSLv2 enabled, but all of the SSLv2 cipher suites disabled. Technically, although they support SSLv2, it is impossible for the handshake to complete, which has the same end result as protocol disablement.
Some servers accept SSLv2, but they always respond with a special error message to all requests. This is actually a very good idea from the usability point of view. An SSLv2 user connecting to a server that does not support SSLv2 is only likely to get a cryptic error message from their browser, which may leave him wondering what to do. Accepting a connection, only to deliver a user-friendly error message is a very good idea.

Now, dealing with the first case is easy: you just keep a would-be SSLv2 connection open for a bit longer. A failure to negotiate a cipher suite means SSLv2 connections are effectively impossible.

Handling the second case is difficult because there is no standard way to deliver user-friendly protocol errors. For example, this is what Amazon gives you (I suspect the error page is delivered by the load balancer, although it's perfectly possible to implement it on the application level):

HTTP/1.1 500 Internal Server Error
Connection: close
Content-Length: 309
Content-Type: text/html

<html><body><b>SSL Protocol Alert</b><p>The SSL protocol version that your
browser uses is SSLv2 and it is not compatible with the server settings.
</p><p>Please try the following:</p><p>- Check the SSL protocol settings
on your browser for SSLv3/TLSv1 protocol support and enable the same.
</p></body></html>

Amazon is kind enough to indicate that there is a problem by setting the response code to 500, which is easy to detect. Adding a check for this special case was easy. In a general case, however, I can't just assume that everyone is going to do the right thing. I know they won't. So, for the time being, I am logging all unusual responses to requests over SSLv2 connections. In time I plan to automate the detection by observing if the tested site "looks" substantially different over SSLv2 (not sure what exactly that means, but I will figure it out).

Thanks to Bo and Brandon, who emailed me to discuss the above two issues.

TLS Server Name Indication now in Apache

2009-07-29T00:00:00+01:00

Apache 2.2.12, which was released yesterday (see the changes), now supports TLS Server Name Indication (SNI), which is an extension to TLS that makes virtual SSL hosting possible. At the moment, every SSL web site requires a separate IP address and that makes SSL deployment more difficult than it could and should be.

Don't get your hopes up, though. Although the extension was defined in 2003, the support for it is still very limited. For example, Apache's adoption means that, for the first time, SNI is supported in a major web server. (For the record, you could have used SNI previously with mod_gnutls, but mod_gnutls is not widely used yet.) It is only now that the extension begins to have a fighting chance.

However, the server-side support is not the main problem, although we are yet going to see it IIS. The lack of client-side SNI support holds it back. Although Internet Explorer supports SNI since 7.0, the fact that it does so only on Vista and more recent versions, means that we will have to wait many years for SNI to become practical.

Can you have too much SSL?

2009-07-24T00:00:00+01:00

In response to my announcement of the SSL Rating Guide, Colin Watson left an interesting comment, which I thought would be better answered here.

Perhaps getting away from the issue of SSL configuration, and more onto application design, there's a couple of areas where I feel OVER-use of SSL might be a problem:

Overuse of SSL? Having previously stated (in my Secure Browsing Mode proposal) that I'd like to see the Web become a SSL-only place, I don't think overuse is likely. In fact, given my ongoing struggle to find a hosted blog or wiki service that uses SSL properly, I'd rather see overuse than what we have now — no security at all.

1. sites that ONLY operate under SSL, and are not available without SSL, even though most of the content is public and not in any way sensitive (does this over-use undermine confidence or increase distrust is other non-SSL sites?)

Even with web sites that do not contain sensitive content (no need for confidentiality), you'd still want SSL to provide authentication (are you seeing the correct web site?) and integrity (has anyone modified content in transit?).

2. sites that are generally not SSL, but allow content to be accessed using SSL by unauthenticated users (authenticated users always being forced to use SSL)

Actually, allowing non-SSL access anywhere on a site that requires authentication at some point is very dangerous. When you access a non-SSL site you have no way of telling if you are seeing the genuine site. A MITM attacker could have intercepted your DNS queries to redirect your HTTP requests elsewhere. He could have easily modified the site's content in transit. Either way, he's in charge of what you see. Links to an SSL-enabled portion of the web site could be rewritten to plain-text access. Similarly, such links could lead to an SSL-enabled site under the attacker's control. Granted, some advanced users would detect such an attack, most most users wouldn't.

Can you have too much SSL? I don't think so.

Announcing the SSL Server Rating Guide and the Public SSL Server Database

2009-07-22T00:00:00+01:00

It is my great pleasure to announce two new SSL Labs projects today. Although I launched SSL Labs a month ago using something else as an excuse, the two projects I am announcing today are the real reason SSL Labs exists. After several months of hard work, my two projects are finally ready for the public.

The SSL Server Rating Guide is a no-nonsense SSL server assessment guide. From the introduction:

The Secure Sockets Layer (SSL) protocol is a standard for encrypted network communication. We feel that there is surprisingly little attention paid to how SSL is configured, given its widespread usage. SSL is relatively easy to use, but it does have its traps. This guide aims to establish a straightforward assessment methodology, allowing administrators to assess SSL server configuration confidently without the need to become SSL experts.

The general idea is to give people something concise to work with, something they can pick up and use in a very short period of time. The guide not only makes SSL server assessment very easy, it also gives clear guidelines on what good configuration looks like.
But what good is a rating guide if you don't have tools that will do the hard work for you? Noticing a lack of good SSL assessment tools, I built one and made it into a free online service. The Public SSL Server Database was born.

I hope you will find the projects useful!

Firefox SSL extensions

2009-07-16T00:00:00+01:00

When I saw the email Adam Muntner sent to the webappsec mailing list, in which he advertises his webappsec collection of Firefox extensions, I immediately realised I wanted to do something similar, but for SSL. There are a few interesting SSL extensions for Firefox, but people generally don't know about them.

I ended up creating two collections: one for the extensions that work with the most recent version of Firefox, and another for the older ones:

Firefox SSL Add-on Collections

Examples of the information collected from SSL handshakes

2009-07-09T00:00:00+01:00

I've received an email or two asking me about the information I collected using mod_sslhaf, so I decided to make it available for everyone. Here it is:

sslhaf-20090709-2.txt.gz

The file contains a list of unique user agents seen on SSL Labs, each with information on the handshake they used and the protocols and cipher suites they offered to use. For example:

Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_2_1 like Mac OS X; en-us) AppleWebKit/525.18.1 \
(KHTML, like Gecko) Version/3.1.1 Mobile/5H11 Safari/525.20
 Handshake: h3
 Protocol: 03.01

 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
 TLS_RSA_WITH_RC4_128_SHA (0x05)
 TLS_RSA_WITH_RC4_128_MD5 (0x04)
 TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x0a)
 TLS_RSA_WITH_DES_CBC_SHA (0x09)
 TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x03)
 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x08)
 TLS_RSA_WITH_NULL_MD5 (0x01)

The information gives insight into how SSL is used in real-life, but it's not reliable enough to support any conclusions about individual clients. There are several problems I need to solve:

Parse User-Agent fields to group related clients.
Record request IP addresses in order to be able to verify the search engine clients are who they say they are.
Record request IP addresses to use them as a mechanism to determine forged User-Agent fields.
Deploy mod_sslhaf to multiple high-traffic sensors, in order to further minimise the possibility of using forged User-Agent fields.

Update (10 July): Now with no unknown cipher suites in the output.

Analysis of Googlebot's frugal cipher suite list

2009-07-02T00:00:00+01:00

Two weeks ago, I announced SSL Labs and my technique for passive SSL cipher suite analysis. It won't surprise you to learn that I've been carefully observing the cipher suites used in the requests that came to the web site since. (In fact, I announced the site slightly earlier than I had planned because I wanted to get my hands on some real-life data.) One client's SSL fingerprint immediately caught my attention, because it supported only 4 cipher suites. It was Googlebot.

There were 115 visits from Googlebot in the two-week period, using 5 different user agent strings (although Googlebot will sometimes send a request without User-Agent set):

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
Googlebot-Image/1.0
Feedfetcher-Google; (+http://www.google.com/feedfetcher.html; feed-id=9430846974815548184)

The first one is by far the most common, although the other ones appear on regular basis. I used reverse DNS to verify that the IP addresses belong to Google, with the exception of one Feedfetcher request, for which I had to use ARIN.

As I’ve already mentioned, Googlebot's SSL fingerprint is quite short:

h2,03.01,010080,04,05,0a

The first token indicates the version of the SSL handshake used. In this case it’s h2, which is a code for the SSL v2 handshake. The second token indicates the highest SSL version a client is willing to support. Googlebot’s choice, 03.01, indicates that is willing to go as far as TLS v1.0. Modern browsers do not support SSL v2.0 so it's generally rare to see a browser use a SSL v2 handshake. Search engines don’t care about security but they do care about accessing as many servers as possible: they’ll compromise and support the weaker protocols.

What follows is the most interesting part: the codes for only 4 cipher suites. They are:

SSL_CK_RC4_128_WITH_MD5 (0x010080)
SSL_RSA_WITH_RC4_128_MD5 (0x04)
SSL_RSA_WITH_RC4_128_SHA (0x05)
SSL_RSA_WITH_3DES_EDE_CBC_SHA (0x0a)

The first suite is only valid with SSL v2.0, while the three remaining ones work in SSL v3.0 or TLS v1.0. It's obvious that, unlike with most other SSL clients, the cipher suites on this list were hand-picked. If I would have to guess, I would say that the motivation was to save on bandwidth and increase performance. It’s likely that all SSL v2.0 servers support the one SSL v2.0 cipher suite, while 3 suites are needed to support the rest of the Internet.

Assuming the reason for such a short list of cipher suites is frugality, I am surprised it doesn’t contain suites with weaker ciphers. A search bot doesn’t really care about security so it could afford to negotiate a weaker cipher and perhaps save some CPU cycles. Similarly, 3DES is significantly slower (than, for example, RC4) so it would be my first candidate for removal if I am concerned with performance. Thus, I am guessing 3DES is there for interoperability.

It would be interesting to get someone from Google to comment.

Interestingly, my net caught one search engine imposter, who claimed he was Googlebot, but wasn't. While I could have also used a reverse DNS lookup to determine what the imposter wasn’t, in this case I was also able to identify what it was—someone browsing the Internet using a Firefox 2.x browser with and altered User-Agent field. Nice!

Improved handling of SSL warnings in Firefox 3.5

2009-07-01T00:00:00+01:00

Slightly over a year ago I discussed the SSL certificate error handling in Firefox. Where Firefox 2.x allows users to simply click through a warning about an invalid SSL connection, Firefox 3.0.x improves the handling and makes it difficult to access the invalid web site.

My blog post turned out to be quite popular, sparking a lively discussion, which spilled onto the Mozilla's Bugzilla when I filed two bug reports for Firefox:

The first bug report was rejected after a short discussion (still, I was happy to have been heard), but the second lingered on and, one year later, resulted in the change in how Firefox handles invalid SSL certificates. In Firefox 3.5, when you encounter an invalid SSL web site, you get a screen similar to this one:

Notice the improved language. The message now ways "[...] we can't confirm that your connection is secure", instead of "[a site] uses an invalid security certificate" (followed by technical mumbo-jumbo). Clicking the two headings at the bottom uncovers the hidden areas, which contain more information and the button to create an exception:

HTTP client fingerprinting using SSL handshake analysis

2009-06-17T00:00:00+01:00

My first SSL Labs project is about HTTP client fingerprinting when SSL is used. A cipher suite, in SSL, is a collection of cryptographic techniques that defines a secure communication channel. There are hundreds of cipher suites, and they are all built out of a dozen or so basic building blocks: key exchange, encryption and integrity validation algorithms. Different programs often use different cipher suites. By observing the list of supported cipher suites one can determine the maximal communication strength, and often even guess the make of the SSL client on the other side.

Possible uses:

System administrators can make informed decisions about which cipher suites to enable in the SSL servers they maintain. The general goal is disable as many of the weak(er) cipher suites, while leaving enough to still make it possible for users to connect.
Cross-checking the supported cipher suites with the HTTP client identity offered in the User-Agent header may help uncover some automated attack tools that masquarade themselves as browsers. Although the cipher suites used by an SSL client is completely under its control, such evasive actions require a new layer of SSL expertise. (Whereas it is trivial to spoof the contents of the User-Agent header.)

The proof of concept is an Apache module, which monitors SSL handshakes to extract the supported cipher suites. This approach is quite handy, because you can add the fingerprinting facility to your existing installation and suffer negligible overhead.

Security researchers ask Google to enable SSL encryption by default

2009-06-16T00:00:00+01:00

A group of 38 researchers and privacy advocates sent a letter to Google asking it to enable SSL encryption by default in all its applications. Google has had the always-use-SSL option for a while but, since the feature is disabled by default, only a small number of users is taking advantage of it. Google's response was somewhere along the lines of "we'll give the users security... eventually... if we must".

Although the performance overhead of SSL is negligible for most web sites, the price of security is likely to be significant in Google's case, considering the size of its user base.

SSL Labs launches

2009-06-15T00:00:00+01:00

Recently I've found myself spending more and more time not only thinking about SSL, but also working on several SSL-related projects. SSL is a remarkable technology that is not given nearly as much credit as it deserves. I think this is at least partially because SSL is so commonplace today that people take it for granted. Compared to other security technologies, it is also reasonably easy to configure. But therein lies the danger: SSL is so easy to use that most people have stopped thinking about SSL.

I think there's a large gap between how SSL is used today and how it should be used. Actually, I think we first need to make an effort to understand how SSL is actually used today in order to build on that knowledge. With that, in mind, I decided to start a new web site and use it as a launching point for my SSL-related projects. Fast-forward several months; today, I am happy to announce SSL Labs, which has just launched.

My initial work on HTTP client fingerprinting using SSL handshake analysis is already there (I will write more about it in subsequent posts), but I have several other projects, which I will publish in the following weeks.

The worst idea ever: Let's break SSL for mobile users

2009-01-31T00:00:00+00:00

This is definitely the scariest and stupidest idea I have heard in a very long time: some people on the W3C Mobile Web Best Practices Working Group think that is acceptable to break SSL—the security backbone of the Internet—in order to help transcoding proxies reformat content for mobile users:

The “WAP Gap” All Over Again - W3C, HTTPS and Transcoding

This just demonstrates one of the reasons we suck at security: small groups of people who do not really know what they are doing wield significant power and affect millions. It's like year 2000 all over again. We are lucky when in some cases (such as in this one) there are informed people willing to stand for what's right.

Will the real John Viega please stand up?

2008-12-31T00:00:00+00:00

I thought this was very funny. Yesterday I came across this post from John Viega where he discusses the certificate trust model, ending the post with:

That leaves the Internet fundamentally broken.

Then, today, in a guest post on the Zero Day blog, he states:

People are declaring the entire Internet is broken, and that it will be hard to fix. This is simply not true.

HOWTO: Create a rogue CA certificate for $2000

2008-12-30T00:00:00+00:00

An international group of researchers—speaking at the 25th Chaos Communication Club conference—published details on how they had managed to construct a rogue Certificate Authority (CA) certificate (!) using a weakness in the MD5 hashing algorithm. They estimate the attack costs $20,000 to execute today, but that the cost can be reduced to as little as $2000. With a rogue CA certificate in hand they are able to impersonate any SSL-enabled web site and conduct MITM attacks undetected (no browser warnings!).

The presentation is now available for download.

Update (30 Dec): And so is the paper, along with more information and a demonstration site (the CA certificate was purposefully constructed to expire in 2004, which essentially makes it harmless).

Update (31 Dec): Verisign fixes the problem.

Self-signed certificates in production point to a failure of SSL

2008-07-17T00:00:00+01:00

I am realising that, although the problem that many Firefox users have with self-signed certificates points to a failure in software design (this is not a stab at Firefox, rather a testament to how difficult it is to design software to suit a diverse user base), it really points to a failure of SSL. Why do we have such large numbers of self-signed certificates in the first place? Why isn't everyone using valid certificates?

SSL is a great security protocol and a great success overall. Consider the following:

Hybrid protocol that, when properly implemented, offers security and performance at the same time.
Future-friendly design that allows ciphers and hashing techniques to be replaced as they begin to age
Can be applied to any communication protocol (well, almost any; and the problem will eventually be fixed).
Free.
Rock solid, as the designs are in the public and they have been thoroughly reviewed.

The catch is in the "properly implemented" part. SSL can give you security but only if you can build on top of an existing trust relationship. Most people don't really think about the underlying trust foundation because this is something normally handled by browser vendors when they accept to trust the root certificates of the established certificate authorities. By the time you open a browser you already trust a few dozen entities. They, in turn, extend their trust to cover the web sites you are visiting and everything seems great. Except that there are a few rough edges:

Using valid certificates is an optional step in the configuration of any web server. It requires knowledge, time and effort, and many people can't be bothered. There's also the overhead of required regular maintenance.
The cost model falls apart for very small entities, mostly because of the administrative overhead, but also also because of the additional cost of the certificate itself.

At first I thought the best thing to do would be to relax handling of invalid SSL certificates in browsers. After all—I thought—we don't really trust; most people don't check certificates anyway. We really care about transport security and not having our credit card details snapped while in transit. My idea was to simply ignore the fact that a certificate is self-signed. Perhaps use different colours to show the difference. I felt pretty good about that until I realised that would allow for unrestricted exploitation through man-in-the-middle (MITM) attacks. You see, the problem is that it is impossible to differentiate between a self-signed certificate and a MITM attack. It's not a problem of SSL or even the implementation. Oh, well, back to the drawing board. (Bruce Schneier recently wrote about MITM attacks: his post has a couple of very interesting stories and workarounds.)

The only thing I can think of that would help is raising awareness, and browser vendors seem to be doing that at the moment. Yes, there's a number of angry people, but I trust all the vendors will do the right thing—eventually. We should just be patient and wait for it to happen, while continuing to remind the vendors that security matters.

Firefox versus SSL is really about security versus usability

2008-07-15T00:00:00+01:00

My blog post Firefox 3 improves handling of invalid SSL certificates is proving to be very popular. It touched a nerve, and the comments of unhappy Firefox users keep piling on. Although I suspect a large part of the problem stems from bugs (if you read the comments you will find the reports of clearly unintended behaviour), there is a bigger problem between Firefox and its user base: it is one of security versus usability.

Who knows better: developers, or users?

It's not a problem specific to Firefox, nor a problem that only exists in the security sphere. In fact, once you become aware of the existence of the problem and start looking around, you will find it in virtually every aspect of technology. GNOME, for example, is famous for dumbing down the user interface and forcing its users to behave in a certain way.

It's not surprising that, with two opposing sides, there are two schools of thought. Implementing either approach is easy—and that's what many applications do—but that only results in unhappy users. Finding a way to make products usable, yet secure (or feature-full, outside security) is the real challenge. How do we educate the innocent yet enable the proficient?

Speaking of implementation, the answer may be in making applications capable of adapting to user needs. A system-wide setting could tell applications whether a user prefers to have decisions made for him. Alternatively, an application-specific flag could be set during installation. Having just two settings is probably not feasible, but there should be an easy way for advanced users to ask applications to show them everything.

But it may be that, in order to really solve the problem, we need to make a further step back and examine the way we develop applications. I think the majority of applications are still built by technical people, pushed by business people with features (not security or usability) in mind. Happy users are productive users, but very few companies seem to recognise this fact.

Eliminating session hijacking... forever

2008-06-04T00:00:00+01:00

Jim Manico, over at Manicode, is doing an interesting thing: he is trying to convince the maintainers of every web application stack component everywhere (e.g. browsers, web servers, libraries) to implement the HttpOnly mechanism (read more on HttpOnly in Mitigating Cross-site Scripting With HTTP-only Cookies). Actually, he is doing more than that—in many cases he is fixing things himself and submitting the patches. It's his HttpOnly Crusade.

The general idea behind HttpOnly is to prevent the disclosure of session tokens to JavaScript, which would, in turn, reduce the likelihood of session hijacking attacks. It's a noble idea, but one which is very difficult to succeed. The problem is that we are dealing with a leaky bucket. HttpOnly deals with one of the leaks, but it doesn't do anything about the others. And there are many leaks to take care of. If you go through Jim's blog posts, you will find that AJAX requests will also need tweaking (to hide the cookies marked with HttpOnly), and there is not even mention of session tokens embedded in request URIs, or embedded in request parameters. There is no doubt that an implementation of HttpOnly in all software components would raise the bar and make us more secure, but it won't solve the problem. In this particular case I would prefer to replace the entire bucket.

Our real problem is that session management is not standardised, forcing every application platform (and many applications) to provide its own implementation. Why is this bad?

Implementing session management correctly is not trivial. First versions of many implementations have been found to be incorrect and, thus, insecure.
It's a waste of time. Session management is best abstracted and handled by the underlying platform or library.
Application-level implementations of session management (all implementations today) are inherently vulnerable to session hijacking. We must move session management to a different layer in order to be able to implement it securely (see below).

Why is session hijacking possible in the first place? The HTTP authentication model, as originally envisioned, is not vulnerable to session hijacking because it requires authentication on every request. Session tokens are still needed to identify which requests are part of a session, but since authentication always take place there can be no hijacking. The HTTP authentication model was lacking in many other respects (e.g. there were no provisions to log people out, expire sessions, and so on), so most people simply decided not to use it. In the currently dominant session management model authentication is done only once per session, which turns session tokens into time-limited password surrogates, and thus valuable. Anyone who knows a session token can resume the session it refers to.

There are two ways to solve the session hijacking problem cleanly:

Perform authentication on every request, thus making session tokens worthless (as far as hijacking is concerned). You can do this today in certain circumstances, for example if you are willing to use any of the HTTP authentication methods (Basic or Digest), or if your application uses client SSL certificates (in this case all you need to do is to attach the client's SSL certificate to the session, and check that it is the same on every subsequent request).
Start a new RFC effort to define session management, and then implement it in a layer other than HTTP. We already have the ideal candidate for this function—SSL. SSL actually already understands sessions (they were added to version 3 to increase performance) so only a few tweaks would be needed to make the mechanism suitable for web applications.

Firefox 3 improves handling of invalid SSL certificates

2008-04-29T00:00:00+01:00

I have downloaded the beta of Firefox 3 to check out the improvements related to SSL. First, there's the added support for Extended Validation SSL certificates, but I am not very excited about that (I wrote about this previously in Extended Validation SSL certificates not going anywhere, as predicted). It's a nice feature, but it's not going to bring much good overall. On the other hand, I am very happy with the improvements to the handling of invalid SSL certificates.

Firefox 2.x allows users to simply click-through their way to a site that uses an invalid certificate. There is a warning of some sort, but who reads warnings anyway? (Internet Explorer is not much better in this respect, although at least its warning is very clear about not recommending the user to proceed.)

With Firefox 3.x, the situation is much better. First you get the same style of error response as you would for any other network problem:

The beauty of this page is that it does not allow you to proceed to the site. To go through you have to create an exception, which is a multi-step process that you can start by clicking on that link at the bottom. You then get the following:

Another warning; very good. Clicking the Add Exception... button gives you the form that is used to actually create exceptions. There's a nice final warning on the top of the form, which will hopefully deter those who will be attempting to create an exception for the wrong reasons:

The changes represent a great step forward, and significantly reduce the likelihood of successful man-in-the-middle attacks. Still, I wouldn't mention exceptions at all on the error page: advanced users will find a way to do what they must, but normal users are better-off not knowing anything about exceptions.

Update (7 May 2008): My request to make hide the functionality to create exceptions from the error page was rejected. It's good to know that the issue was considered, even if the decision is not the one I would have made. Daniel Veditz pointed me to Johnath's blog post, which describes the history behind the new SSL error page. Very interesting.

Extended Validation Certificates: A change for the better (but not enough)

2007-06-15T00:00:00+01:00

On June 12th, 2007, the CA/Browser Forum (a group that consists of leading certificate authorities and browser vendors) ratified the first version of the Extended Validation (EV) SSL Guidelines. The goal of the guidelines is to introduce a new type of certificate, Extended Validation Certificate, with intent to standardise the certificate issuance process.

Those of you that remember the early days of SSL certificates will find that the "new" process is pretty much identical to the one we had to undergo years ago. Things such as verifying legal existence, identity, registration number, right to use the domain name--are all there. There is one crucial difference, though. This time the process is mandatory whereas before, it turns out, it was merely a matter of choice. No wonder the quality of the vetting had deteriorated over the years as companies fought for the market by lowering prices.

There are many who do not like the new Extended Validation Certificates. They usually say the new type of certificate will not solve our problems. And that they are merely a way for the certificate authorities to extract more money from their customer base. While I agree with the former, I do not necessarily agree with the latter (but this is not to say the CAs will not be happy to collect the extra funds).

The point is that a solid vetting process should have been a mandatory requirement from the start. The fact that we missed the opportunity to do the right thing then does not mean we have to continue living with the mistake. It is true--the new certificate does fall short of solving our problems. But, guess what, that was never the intention. Citing from the EV Certificate Guidelines (page 13):

(c) Excluded Purposes EV Certificates focus only on the identity of the Subject named in the Certificate, and not on the behavior of the Subject. As such, an EV Certificate is not intended to provide any assurances, or otherwise represent or warrant:

That the Subject named in the EV Certificate is actively engaged in doing business;
That the Subject named in the EV Certificate complies with applicable laws;
That the Subject named in the EV Certificate is trustworthy, honest, or reputable in its business dealings; or
That it is "safe" to do business with the Subject named in the EV Certificate.

SSL certificates have nothing to do with trust. (Admittedly, it's a fact we didn't fully appreciate when they were introduced.) Their purpose is simply to identify the party on the other side of the communication channel. For trust we need to turn to other methods. Actually, we developed perfectly good methods to do this in real life. For example, most people take into account the brand name of the store or that of the manufacturer. You are going to be very comfortable buying from Amazon because you know the company. By the same token, you are probably going to think twice before buying from a badly-designed, badly-built web site you've just run across.

There is one aspect where Extended Validation Certificates fall short, and that's the implementation and the changes in the browser user interfaces. To accommodate the new type of certificate browsers have resorted to displaying the sites protected with such certificates in a slightly different way. There are two problems with this. One is that a normal user stands to gain very little from the change. The other is that, even for the small gain that can be achieved, a huge marketing effort is going to be required to explain the difference. This effort is not only going to be expensive but also take time--a lot of time. It something we can successfully do maybe once or twice in a decade. The EV Certificates are simply not worth it.

A far better solution would have been to, slowly and quietly, reform the certificate issuance process. Let the old certificates expire and start issuing better ones today. While that is happening figure out a way to deal with our real problems and inform the normal Internet users only once we are happy we've done the right thing.