[TLS] SSL Renegotiation DOS

"Jorge A. Orchilles" <jorge@orchilles.com> Tue, 15 March 2011 11:30 UTC

Return-Path: <jorge@orchilles.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 6E52C3A6C7B for <tls@core3.amsl.com>; Tue, 15 Mar 2011 04:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.714
X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2eEPnTFfBi0N for <tls@core3.amsl.com>; Tue, 15 Mar 2011 04:30:10 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com []) by core3.amsl.com (Postfix) with ESMTP id 4F8363A6B3A for <tls@ietf.org>; Tue, 15 Mar 2011 04:30:09 -0700 (PDT)
Received: by fxm15 with SMTP id 15so491653fxm.31 for <tls@ietf.org>; Tue, 15 Mar 2011 04:31:33 -0700 (PDT)
Received: by with SMTP id z4mr1377721faj.83.1300188691842; Tue, 15 Mar 2011 04:31:31 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com []) by mx.google.com with ESMTPS id n26sm365273fam.13.2011. (version=SSLv3 cipher=OTHER); Tue, 15 Mar 2011 04:31:31 -0700 (PDT)
Received: by fxm15 with SMTP id 15so491608fxm.31 for <tls@ietf.org>; Tue, 15 Mar 2011 04:31:30 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id r18mr1288312fah.140.1300188688497; Tue, 15 Mar 2011 04:31:28 -0700 (PDT)
Received: by with HTTP; Tue, 15 Mar 2011 04:31:28 -0700 (PDT)
Date: Tue, 15 Mar 2011 08:31:28 -0300
Message-ID: <AANLkTin2i3+K8oV68pZFJ0xabjEugJLePyZTTaZSr0VE@mail.gmail.com>
From: "Jorge A. Orchilles" <jorge@orchilles.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="0015173fef66eb3c8f049e83c4e1"
Subject: [TLS] SSL Renegotiation DOS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2011 11:30:11 -0000

Hello all,

Marsh Ray has invited me to present my research and report on SSL/TLS
Renegotiation Denial of Service on this mailing list. I have posted this on
my site and will paste here for your feedback:

*SSL/TLS Renegotiation Denial of Service*

An SSL/TLS handshake requires at least 10 times more processing power on the
server than on the client. The handshake is only performed at the beginning
of a secure connection to establish it. When SSL/TLS Renegotiation is
enabled on the server, a user is allowed to send a renegotiation request
which initiates a new handshake. Since it takes much less resources for a
client to perform a handshake, requesting multiple handshakes per second
could cause a denial of service on the server side SSL/TLS interface.
Therefore, if a malicious user on one host requests multiple renegotiation
requests it will exhaust the server’s resources and not allow any other user
to establish a connection.

This attack is different than a Distributed Denial of Service (DDOS) as it
does not require the volume, or botnet, to exhaust the network connection.
Instead it exhausts the server resources from a single host requiring only a
single TCP/IP socket.  A single server can perform between 150-300
handshakes per second. While a single client can request up to 1000
handshakes per second.

A preventive measure to this issue would be to disable SSL/TLS
Renegotiation. The vendor of your specific SSL Implementation should have
documentation on disabling this “feature.” Performing rate-limiting on new
incoming TLS connections AND renegotiations would also be a preventive
method; most implementations only perform rate-limiting on new connections
if at all. A mitigation would be to use an SSL Accelerator, although adding
one or two more hosts to your attack would render it useless as well.
Current DOS and DDOS detection and mitigation strategies will not work with
this attack as the initial handshake is legit and the renegotiation requests
are made directly with the server after the network and application layer

There are multiple ways to determine if SSL/TLS Renegotiation is enabled. Nasko
Oskov <http://netsekure.org/2009/11/tls-renegotiation-test/> site, Nessus
has a plugin for
,Qualys has a site to test for it
<https://www.ssllabs.com/ssldb/index.html>, and
you can do so manually with OpenSSL (thanks to Ivan

   - openssl s_client -connect ip:port
   - HEAD / HTTP/1.0
   - R

The Hackers Choice <http://www.thc.org/> semi-silently released a proof of
concept tool <http://www.thc.org/thc-ssl-dos/thc-ssl-dos-1.4.tar.gz>
on February 28,
2011 at DC4420 <http://dc4420.org/> that performs the described denial of
service against servers that allow SSL/TLS Renegotiation. I recommend
reading the source code before running it and ensure you have permission to
run a denial of service attack against the target. To use the tool, I used

   - Download: wget http://www.thc.org/thc-ssl-dos/thc-ssl-dos-1.4.tar.gz
   - Extract: tar -zvxf thc-ssl-1.4.tar.gz
   - View files and source: cd thc-ssl-dos/src
   - Edit the source: vim thc-ssl-dos.c
   - I recommend adding a 1 instead of 0 to the two flags required to run
   the program. You may also edit the max amount of connections.
   - Configure: cd .. Then: ./configure
   - Install: make all install
   - Run: cd src Then: ./thc-ssl-dos ip port
   - Options include: -l x where x is the number of connections, the default
   is 400.

I have calculated this as a High risk issue using CVSS v2:

I would like to thank all that provided feedback and peer review for this
issue: Ron Gula and Tenable, Steve Dispensa, Nasko
Marsh Ray, and Kai Engert.

Please leave a comment or use the contact form<http://orchilles.com/contact> to
provide feedback or request denial of service proof of concept testing on
your site.
Best Regards,
Jorge Orchilles

Best Regards,
Jorge Orchilles