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.

Unfortunate current practices for HTTP over TLS

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

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.