Subject: [TLS] SSL Renegotiation DOS

From: "Jorge A. Orchilles" <[email-masked]>
Date: Tue, 15 Mar 2011 08:31:28 -0300

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:
http://orchilles.com/2011/03/ssl-renegotiation-dos.html

*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
controls/filters.

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
it<http://www.nessus.org/plugins/index.php?view=single&id=42880>
,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
Ristic<http://blog.ivanristic.com/2009/12/testing-for-ssl-renegotiation.html>
):

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

   - 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:
8.6 (AV:N/AC:L/Au:N/C:N/I:N/A:C/E:P/RL:W/RC:C/CDP:ND/TD:ND/CR:H/IR:H/AR:H)

I would like to thank all that provided feedback and peer review for this
issue: Ron Gula and Tenable, Steve Dispensa, Nasko
Oskov<http://netsekure.org/>,
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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 15 Mar 2011 12:46:14 +0100

On Tue, Mar 15, 2011 at 12:31 PM, Jorge A. Orchilles
<[email-masked]> wrote:
> SSL/TLS Renegotiation Denial of Service

Hello,
 I'm curious, what is the effect of that in typical HTTPS servers? Do
servers allow
for renegotiation initiated by the client? (apache with mod_gnutls doesn't)

regards,
Nikos

---

From: "Steve Dispensa" <[email-masked]>
Date: Tue, 15 Mar 2011 08:23:44 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Nikos Mavrogiannopoulos
>
> Hello,

When we looked at implementations last year, we found that IIS was definitely not willing to do client-initiated renegotiation, but at the time there were a few that would. I'm sure a lot has changed since I last looked at it.

 -Steve

---

From: Joe Orton <[email-masked]>
Date: Tue, 15 Mar 2011 15:39:43 +0000

On Tue, Mar 15, 2011 at 08:23:44AM -0500, Steve Dispensa wrote:
> >  I'm curious, what is the effect of that in typical HTTPS servers? 
> > Do servers allow for renegotiation initiated by the client? (apache 
> > with mod_gnutls doesn't)
> 
> When we looked at implementations last year, we found that IIS was 
> definitely not willing to do client-initiated renegotiation, but at 
> the time there were a few that would. I'm sure a lot has changed since 
> I last looked at it.

As part of the workaround for CVE-2009-3555 added in the 2.2.15 release 
of Apache httpd, mod_ssl will (or should!) reject any renegotiation 
initiated by the client.  The code still behaves this way, for both 
clients which support RFC 5746 and those which do not.

Older versions of Apache httpd/mod_ssl will allow a client-initiated 
reneg at any time, as is the default behaviour with OpenSSL-based 
servers.

I recall a complaint that some mobile browser was known to initiate 
renegs, but I can't find a reference for that; it might have been 
off-line discussion.  I'd be interested to hear any further data on 
that.

Regards, Joe

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 15 Mar 2011 15:49:37 +0000

> off-line discussion.  I'd be interested to hear any further data on 

It was mentioned in the openssl-dev list a couple of times. The title was
"Renegotiation denied wrong?" around Nov 23rd 2009.

Steve.	
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: "Steve Dispensa" <[email-masked]>
Date: Tue, 15 Mar 2011 11:03:54 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dr
> Stephen Henson

Seems like tor also used client-initiated renegotiation, if memory
serves. Don't know if that's still true.

 -Steve

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 Mar 2011 17:07:42 +0100 (MET)

Jorge A. Orchilles wrote:
> server than on the client.

I'm sorry, I completely fail to see what renegotiation has to do
with the DoS capability here.

The TLS protocol is a cryptographic protocol, and servers that expect
to talk to real clients performing the protocol as designed will attempt
to perform the cryptographic operations as requested.

A DoS-client could simply open new connections to the SSL server and
blindly fire away precompiled static SSL handshake messages, forcing the
server to do crypto work.  You should be able to make most servers
perform RSA decrypts on arbitrary data, and a significant number
to perform DHE computations.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Mar 2011 09:20:35 -0700

> to perform DHE computations.

I tend to agree with Martin here: I don't see how this is
significantly worse than separate
connections. Arguably, it's better from the victim's perspective,
since common implementations
run each SSL/TLS connection in its own control thread (or process) and
so the scheduler
will try to fairly share between connections to some extent meaning
that the single offending
connection is bounded in terms of how much it can affect other users.

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Tue, 15 Mar 2011 11:36:58 -0500

On 03/15/2011 11:20 AM, Eric Rescorla wrote:
> On Tue, Mar 15, 2011 at 9:07 AM, Martin Rex<[email-masked]>  wrote:
>>
>> [...]
>> A DoS-client could simply open new connections to the SSL server
>> and blindly fire away precompiled static SSL handshake messages,
>> forcing the server to do crypto work.  You should be able to make
>> most servers perform RSA decrypts on arbitrary data, and a
>> significant number to perform DHE computations.

Yes, but take a step back from the code for a minute. This is a 
potential problem, and the degree to which this is "not my (TLS's) 
problem" has to do mainly with how close you are to the web server 
getting DoSed.

> significantly worse than separate connections.

Presumably, somewhere there is a TCP-based load-balancing DoS prevention 
system protecting a TLS server that allows client-initiated 
renegotiation. This system may do a good job of resisting DoSes on the 
initial handshake but not DoSes on renegotiation handshakes.

My suggestion to Jorge would be to find such a product configuration and 
demonstrate the attack against it (and file a bug with the vendor of 
course).

I don't see this as a real weakness in TLS itself either. Nevertheless, 
I think might be something in scope here. Are there improvements to DoS 
resistance which could be made in the scope of the IETF's TLS activity?

For those of us wishing to promote the use of TLS/HTTPS in general, is 
susceptibility to DoS a significant barrier to adoption?

Look at it this way: If adding TLS increasing the susceptibility to DoS 
attacks, could a DoS be used to compel a site operator to turn off 
encryption? If so, is this not effectively an equivalent to a weakness 
in TLS itself?

> Arguably, it's better
> from the victim's perspective, since common implementations run each
> SSL/TLS connection in its own control thread (or process) and so the
> scheduler will try to fairly share between connections to some extent
> meaning that the single offending connection is bounded in terms of
> how much it can affect other users.

That's an interesting point.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Tue, 15 Mar 2011 18:57:18 +0100 (MET)

> initial handshake but not DoSes on renegotiation handshakes.

The issue might be more about the classification of what counts as
a DoS attack.  Recognizing TLS renegotiations is technically possible for
Intrusion dectection systems, since the ChangeCipherSpec handshake
message remains visible on on the wire, even for TLS renegotiations.
(also, the fact that handshake messages rather than application data
is exchanged, remains visible on the wire).

The workload impact of full TLS handshakes on the TLS server is
far from marginal.  Therefore, even non-hostile clients can consume
most of a servers resources.

Distinguishing DoS from clients with a flaw in their TLS session caching
and defective server-side TLS session caching or inappropriate configuration
might be tricky for an IDS.  Server resources may get drained without any
errors showing up on the communication protocol level, simply by
performing the cryptographic operations of the protocol over and over again.

A TLS server can easily DoS _itself_ with an inadequate,
too small or disabled server side TLS session cache (or due to
bugs in the session cache management of the implementation).

Personally, I consider it a bad idea to run a TLS server on the
internet with TLS session caching entirely disabled.  Limiting
session cache lifetime and session cache size on the TLS server
seems sensible, but running entirely without session cache
does not look sensible to me (for public Web-Servers on the internet).

TLS clients without session caching capabilities also seem to
be unnecessarily common.  Apache mod_proxy used to be incapable
of client side TLS session caching--which causes a serious
performance impact on the communication link between reverse
proxy and backend if that link is TLS-reencrypted.

> resistance which could be made in the scope of the IETF's TLS activity?

When the topic of "client identity protection" came up on the TLS
mailing list, the suggestion was made to solve this by performing
a TLS renegotiation.

Today (after the TLS renegotiation vulnerability), many servers may
have unsolicited renegotiations disabled (and may continue to have
it disabled after adopting the rfc5746 solution).  Microsoft IIS
seems to have never supported unsolicited renegotiations so far --
it was primarily "added value" for TLS implementations that could
perform TLS renegotiation "transparently", i.e. without requiring
support from the (TLS) application caller to do renegotiation.

The results that TLS renegotiation might have on the client identity,
as seen by the server application, is sufficiently non-trivial that some
discussion on this was added to the security considerations of rfc5746

   http://tools.ietf.org/html/rfc5746#section-5

-Martin

---

From: "Steve Dispensa" <[email-masked]>
Date: Tue, 15 Mar 2011 14:52:14 -0500

> Marsh Ray

Yes; any DoS mitigation work that has been done on initial handshakes
should also be done on renegotiations. It wouldn't surprise me if there
are implementations out there for which this is not the case. (Not that
I have any evidence, but I'm eagerly awaiting the results of Jorge's
search.)

If nothing else, it'd be good advice for implementers to keep in mind
going forward.

 -Steve

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 16 Mar 2011 19:54:55 +1300

Martin Rex <[email-masked]> writes:

>A DoS-client could simply open new connections to the SSL server and blindly
>fire away precompiled static SSL handshake messages, forcing the server to do
>crypto work.  You should be able to make most servers perform RSA decrypts on
>arbitrary data, and a significant number to perform DHE computations.

Exactly.  You can do this with virtually no effort using netcat, I continue to
be surprised that we've never seen this deployed in the wild (not wanting to
give any hints to Anonymous, but LOIC is 1990s script-kiddie technology
compared to the DoSes you could use if you gave it a few minutes thought).
What makes it even worse is the Bleichenbacher-attack defense that says you
have to complete the handshake, at full crypto cost, even if it's obvious that
you're just processing garbage.

(Every time this comes up I'm tempted to release some quick tool to exploit
the problem, on the basis that if the good guys don't point it out now, the
bad guys will take advantage of it later.  So far I've resisted the
temptation...).

Peter.

---

From: Martin Rex <[email-masked]>
Date: Wed, 16 Mar 2011 15:02:50 +0100 (MET)

> you're just processing garbage.

If a hostile client is targetting specific servers, it could create
a valid PKCS#1 encrypted premaster secret once and then reuse it in
all further handshakes -- saving the client the asymmetric crypto work
on all additional connections, while still allowing the client to
complete the TLS handshake successfully.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 17 Mar 2011 03:47:50 +1300

Martin Rex <[email-masked]> writes:

>If a hostile client is targetting specific servers, it could create a valid
>PKCS#1 encrypted premaster secret once and then reuse it in all further
>handshakes -- saving the client the asymmetric crypto work on all additional
>connections, while still allowing the client to complete the TLS handshake
>successfully.

If you're just interested in a DoS then you don't even need to do that, just
shovel in 128 bytes of random noise and wait for the server's crypto engine to
collapse under the load.  You can't complete the handshake in this case, but
that's not the bit that you're targetting.

Peter.

---

From: "Jorge A. Orchilles" <[email-masked]>
Date: Fri, 18 Mar 2011 20:04:39 -0300

Thank you for the response. Many implementations allow SSL Renegotiation by
default. IIS is one that does not.

Best Regards,
Jorge Orchilles

On Tue, Mar 15, 2011 at 10:23 AM, Steve Dispensa
<[email-masked]>wrote:

> definitely not willing to do client-initiated renegotiation, but at the time
> there were a few that would. I'm sure a lot has changed since I last looked
> at it.
>
>  -Steve
>

---

From: "Jorge A. Orchilles" <[email-masked]>
Date: Fri, 18 Mar 2011 20:08:47 -0300

It is different that you don't need the volume that you typically need for
DDOS. With renogatiation the attacker can request the server to do all the
crypto work by requesting multiple handshakes per second.

Best Regards,
Jorge Orchilles

---

From: "Jorge A. Orchilles" <[email-masked]>
Date: Fri, 18 Mar 2011 20:06:43 -0300

Looks like Tor fixed that in 0.2.1.21
http://archives.seul.org/or/announce/Dec-2009/msg00000.html

Best Regards,
Jorge Orchilles

On Tue, Mar 15, 2011 at 1:03 PM, Steve Dispensa <[email-masked]>wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Jorge A. Orchilles" <[email-masked]>
Date: Fri, 18 Mar 2011 20:12:45 -0300

However many servers continue to allow SSL Renegotiation. I am identifying
what implementations, suites and web servers allow this and reporting it to
the vendor and site.

Best Regards,
Jorge Orchilles

---

From: "Jorge A. Orchilles" <[email-masked]>
Date: Fri, 18 Mar 2011 20:14:26 -0300

I have password protected the post on my blog because of this. I have
confirmed this is an issue and many sites are vulnerable to DOS. I am
reporting to vendor and vulnerable sites. Until then I will keep the post
locked. You can email me individually for the password as this mailing list
is public and I continue to update the post based on feedback and tests.

Best Regards,
Jorge Orchilles

On Wed, Mar 16, 2011 at 3:54 AM, Peter Gutmann <[email-masked]>wrote:

> blindly

---

From: "Jorge A. Orchilles" <[email-masked]>
Date: Fri, 18 Mar 2011 20:11:20 -0300

I think a solution would be to only allow a certain amount of renegotiations
per a given period.

Best Regards,
Jorge Orchilles

On Tue, Mar 15, 2011 at 1:36 PM, Marsh Ray <[email-masked]> wrote:

> Yes, but take a step back from the code for a minute. This is a potential
> problem, and the degree to which this is "not my (TLS's) problem" has to do
> mainly with how close you are to the web server getting DoSed.
>
>
> system protecting a TLS server that allows client-initiated renegotiation.
> This system may do a good job of resisting DoSes on the initial handshake
> but not DoSes on renegotiation handshakes.
>
> I don't see this as a real weakness in TLS itself either. Nevertheless, I
> think might be something in scope here. Are there improvements to DoS
> encryption? If so, is this not effectively an equivalent to a weakness in
> TLS itself?
>
>
>  Arguably, it's better