Ivan Ristić

TLS Renegotiation and Denial of Service Attacks

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.

Note: This post was originally published on the Qualys Security Labs blog.

Mitigating the BEAST attack on TLS

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.

Note: This post was originally published on the Qualys Security Labs blog.

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

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):

• https://www.ssllabs.com/convergence/notary-eu.convergence.qualys.com.notary
• https://www.ssllabs.com/convergence/notary-us.convergence.qualys.com.notary

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

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?

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?

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

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

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.

IronBee versus ModSecurity

After spending a couple of weeks talking about IronBee to anyone willing to listen, I have assembled a list of commonly asked questions. Not unexpectedly, the question that tops the list is about the difference between ModSecurity and IronBee.

With IronBee we had a luxury of starting a brand new project with a wealth of experience and a clear idea of what we want to achieve long-term. (This is completely the opposite from where I was when I started ModSecurity.) Thus, we were able to look at our goals and choose the best path to reach them. Because so much of our lives were spent with ModSecurity, the first thing we did was look at its successes and limitations, with the idea that we should keep what's good and improve what's not as good. Two not so good things of ModSecurity stuck out: the lack of a community of developers and the fact that ModSecurity runs only in the Apache web server.

To deal with that, we do two core things differently:

• Community focus. We are making IronBee as open as it can be, not only by using a non-viral open source licence (Apache Software License v2), but also by adopting a transparent community-oriented approach to project management and development. We have also designed IronBee to be highly modular, so that adding to it does not have to mean having to understand the entire architecture and operation. Time will tell, but the idea is that giving up tight control will make for a better open source project in the long run.
• Abstracted data acquisition and host-container interaction model. IronBee is built as a framework from ground up, with focus on portability among web servers and a variety of deployment models (embedded, proxy, passive, batch, etc). Hence the universal application security sensor wording. We want you to have access to IronBee no matter what your platform is.

These two things are actually tightly related. For example, we can't succeed with the second goal without first succeeding with the first one. There are so many platforms (potential host containers) out there, so it is not possible for a small team to support all of them. However, by being open and by structuring the code base to make it easy to add new platforms, we create the right conditions for others to port IronBee to other platforms as the need arises.

IronBee, a new Apache-licensed web application firewall

It is my great pleasure to announce the launch of IronBee, a brand new open source web application firewall. It's a project whose main goal is build a universal application security sensor through focus on community-building first , code second. To that end, not only is the project open source, but it uses the Apache 2 license and does not require copyright assignments from contributors. How's that for a conversation starter?

If you head out to the project web site now, you'll find there a whitepaper that goes into detail about why we believe in application security monitoring, why we are taking this particular approach with IronBee, as well as an overview of our key directions. There's no need to repeat all that on this blog. I hope that the whitepaper will give you enough information to get you excited about where we're heading, and excited enough that you will join us on the mailing list for a discussion.

Of course, if you follow my blog you probably know about my work of at least 8 years on ModSecurity, which is a very good and popular open source web application firewall. I will freely admit that it feels a bit awkward to start what is effectively a competing project. Make no mistake, ModSecurity is a fantastic tool (and one very dear to my heart). IronBee exists because we want to do more and go further, and for that we need to start with a foundation different to that of ModSecurity.

Further, the existence of IronBee does not mean that we cannot collaborate with ModSecurity (the project and the community). In fact, we will. I imagine that a good chunk of our work (e.g., security research) will be useful to ModSecurity users. And, for the record, I intend to continue to keep ModSecurity Handbook up-to-date.