[RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation

Sebastian Andrzej Siewior-2
From: Sebastian Andrzej Siewior <[hidden email]>

If the client performs repeatedly a SSL handshakes (via
SSL_renegotiate()) then the server will use much more resources than
the client does. I managed to get 30% load on the server and 7% on the
client side.
This is a computation attack and unfortunately the way a SSL handshake
works. I understand that this `feature' is part of the TLS specification
and I am not trying to nuke from openssl. Instead I would like to
describe the possible attack and some countermeasures to mitigate its
outcome. Having it in the doc section would allow one to ping other
projects, point them to this section and ask them if they could drop the
support for re-negotiation request from the client. From looking around,
nginx for instance does not support renegotiation from client's side.

Signed-off-by: Sebastian Andrzej Siewior <[hidden email]>
---
 doc/ssl/SSL_CTX_set_options.pod | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/doc/ssl/SSL_CTX_set_options.pod b/doc/ssl/SSL_CTX_set_options.pod
index 635b470e1245..137035c7f6f0 100644
--- a/doc/ssl/SSL_CTX_set_options.pod
+++ b/doc/ssl/SSL_CTX_set_options.pod
@@ -255,6 +255,23 @@ renegotiation between OpenSSL clients and unpatched servers B<only>, while
 B<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION> allows initial connections
 and renegotiation between OpenSSL and unpatched clients or servers.
 
+=head2 Possible attack through renegotiation
+
+The renegotiation performs a new handshake. A handshake is more expensive on
+the server side than on the client side. It is possible that a client with
+little bandwidth and with only a few connections to the server will put the
+server in a position where it will use 100% of its CPU if the client repeatedly
+attempts to renegotiate and therefore constantly performs a new handshake.
+Therefore it is recommended not to renegotiate the handshake if the client
+requested it but only do it on the server side.
+
+If the server drops the connections once the client tries to abuse via a
+renegotiation attempt then the attack is not yet fully mitigated. The client
+can still open multiple connections only for the purpose to perform a handshake
+and close it immediately. This is similar to the initial scenario. It is
+recommended to track frequent connects at firewall level and reject abusive
+connections attemps before the handshake is performed.
+
 =head1 RETURN VALUES
 
 SSL_CTX_set_options() and SSL_set_options() return the new options bitmask
--
2.8.1

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation

Viktor Dukhovni
On Mon, Aug 08, 2016 at 08:57:26PM +0200, Sebastian Andrzej Siewior wrote:

> This is a computation attack and unfortunately the way a SSL handshake
> works. I understand that this `feature' is part of the TLS specification
> and I am not trying to nuke from openssl. Instead I would like to
> describe the possible attack and some countermeasures to mitigate its
> outcome. Having it in the doc section would allow one to ping other
> projects, point them to this section and ask them if they could drop the
> support for re-negotiation request from the client. From looking around,
> nginx for instance does not support renegotiation from client's side.

Postfix supports rate limiting new session creation:

    http://www.postfix.org/postconf.5.html#smtpd_client_new_tls_session_rate_limit

Other servers can implement similar resource limits as appropriate.

--
        Viktor.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation

Sebastian Andrzej Siewior-2
On 2016-08-08 20:16:58 [+0000], Viktor Dukhovni wrote:
> On Mon, Aug 08, 2016 at 08:57:26PM +0200, Sebastian Andrzej Siewior wrote:
> > support for re-negotiation request from the client. From looking around,
> > nginx for instance does not support renegotiation from client's side.
>
> Postfix supports rate limiting new session creation:
>
>     http://www.postfix.org/postconf.5.html#smtpd_client_new_tls_session_rate_limit
>
> Other servers can implement similar resource limits as appropriate.

I don't really know what I am supposed to do with this information. Do
you want me to add this as an example into the doc patch or do you
simply point out that others already took precautions?

Sebastian
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation

Viktor Dukhovni
On Tue, Aug 09, 2016 at 09:18:58PM +0200, Sebastian Andrzej Siewior wrote:

> > Postfix supports rate limiting new session creation:
> >
> >     http://www.postfix.org/postconf.5.html#smtpd_client_new_tls_session_rate_limit
> >
> > Other servers can implement similar resource limits as appropriate.
>
> I don't really know what I am supposed to do with this information. Do
> you want me to add this as an example into the doc patch or do you
> simply point out that others already took precautions?

CPU exhaustion attacks on servers are a fundamental feature of TLS.

I am not sure that OpenSSL needs to say anything about this.  Server
applications that want to protect against inadvertent DoS by buggy
clients can implement the obvious counter-measure (rate limit
handshakes with clients that generate too many new sessions per
sample interval).  If you feel that this is not obvious, and others
agree, feel free to propose some text.

Note, that deliberate DoS and especially DDoS will overcome even
rate limits, by attacking from multiple clients, or just flooding
the target network.  So this can only protect against accidents,
not malice by capable adversaries.

--
        Viktor.
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation

Sebastian Andrzej Siewior-2
On 2016-08-09 19:26:44 [+0000], Viktor Dukhovni wrote:
> On Tue, Aug 09, 2016 at 09:18:58PM +0200, Sebastian Andrzej Siewior wrote:
> > I don't really know what I am supposed to do with this information. Do
> > you want me to add this as an example into the doc patch or do you
> > simply point out that others already took precautions?
>
> CPU exhaustion attacks on servers are a fundamental feature of TLS.

I mentioned this.

> I am not sure that OpenSSL needs to say anything about this.  Server
> applications that want to protect against inadvertent DoS by buggy
> clients can implement the obvious counter-measure (rate limit
> handshakes with clients that generate too many new sessions per
> sample interval).  If you feel that this is not obvious, and others
> agree, feel free to propose some text.

I tried. There was some text in the patch.

> Note, that deliberate DoS and especially DDoS will overcome even
> rate limits, by attacking from multiple clients, or just flooding
> the target network.  So this can only protect against accidents,
> not malice by capable adversaries.

I don't claim the opposite. I came across server software which supports
client side renegotiation and I don't think that this is required and
would like to patch it out. So far, so good? And then there is the
"same" thing if the attacker starts multiple connections the sake of a
handshake. So I though to point this out as well. And then I though it
would be nice to document this within the openssl documentation so I
could just point there and make them aware.

Sebastian
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation

Hubert Kario
On Tuesday, 9 August 2016 21:51:32 CEST Sebastian Andrzej Siewior wrote:

> On 2016-08-09 19:26:44 [+0000], Viktor Dukhovni wrote:
> > On Tue, Aug 09, 2016 at 09:18:58PM +0200, Sebastian Andrzej Siewior wrote:
> > > I don't really know what I am supposed to do with this information. Do
> > > you want me to add this as an example into the doc patch or do you
> > > simply point out that others already took precautions?
> >
> > CPU exhaustion attacks on servers are a fundamental feature of TLS.
>
> I mentioned this.
>
> > I am not sure that OpenSSL needs to say anything about this.  Server
> > applications that want to protect against inadvertent DoS by buggy
> > clients can implement the obvious counter-measure (rate limit
> > handshakes with clients that generate too many new sessions per
> > sample interval).  If you feel that this is not obvious, and others
> > agree, feel free to propose some text.
>
> I tried. There was some text in the patch.
>
> > Note, that deliberate DoS and especially DDoS will overcome even
> > rate limits, by attacking from multiple clients, or just flooding
> > the target network.  So this can only protect against accidents,
> > not malice by capable adversaries.
>
> I don't claim the opposite. I came across server software which supports
> client side renegotiation and I don't think that this is required and
> would like to patch it out. So far, so good? And then there is the
> "same" thing if the attacker starts multiple connections the sake of a
> handshake. So I though to point this out as well. And then I though it
> would be nice to document this within the openssl documentation so I
> could just point there and make them aware.
it all depends on the environment, in some renegotiation is completely
unnecessary (public HTTP servers without client certificate based
authentication), in others just client-initiated renegotiation is needed
(typical configuration for HTTP with client certificates), while in other
still renegotiation is necessary for both sides (long sessions that want the
ability to renew encryption keys).


--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation

Sebastian Andrzej Siewior-2
On 2016-08-11 11:34:24 [+0200], Hubert Kario wrote:
> it all depends on the environment, in some renegotiation is completely
> unnecessary (public HTTP servers without client certificate based
> authentication), in others just client-initiated renegotiation is needed
> (typical configuration for HTTP with client certificates), while in other

Is this renegotiation (in this case) triggert by the client or by the
server? I have here access to a few servers which require a client certs
and they don't support renegotiation (triggert by the client) right
after connect.

> still renegotiation is necessary for both sides (long sessions that want the
> ability to renew encryption keys).
You are talking here about long sessions. A simple rate limit would be
okay. My wording was "remove client initiated renegotiation if possible"
I think. Also keeping a rate limit per connection would be nice then.

Sebastian
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation

Hubert Kario
On Thursday, 11 August 2016 13:50:53 CEST Sebastian Andrzej Siewior wrote:

> On 2016-08-11 11:34:24 [+0200], Hubert Kario wrote:
> > it all depends on the environment, in some renegotiation is completely
> > unnecessary (public HTTP servers without client certificate based
> > authentication), in others just client-initiated renegotiation is needed
> > (typical configuration for HTTP with client certificates), while in other
>
> Is this renegotiation (in this case) triggert by the client or by the
> server? I have here access to a few servers which require a client certs
> and they don't support renegotiation (triggert by the client) right
> after connect.
in this case the renegotiation is triggered by server

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation

Sebastian Andrzej Siewior-2
On 2016-08-11 18:04:41 [+0200], Hubert Kario wrote:

> On Thursday, 11 August 2016 13:50:53 CEST Sebastian Andrzej Siewior wrote:
> > On 2016-08-11 11:34:24 [+0200], Hubert Kario wrote:
> > > it all depends on the environment, in some renegotiation is completely
> > > unnecessary (public HTTP servers without client certificate based
> > > authentication), in others just client-initiated renegotiation is needed
> > > (typical configuration for HTTP with client certificates), while in other
> >
> > Is this renegotiation (in this case) triggert by the client or by the
> > server? I have here access to a few servers which require a client certs
> > and they don't support renegotiation (triggert by the client) right
> > after connect.
>
> in this case the renegotiation is triggered by server

good. So still no reason to accept a renegotiation request from the
client (except your "long standing connection" point (which could be
ratelimited or shifted to the server)).

Sebastian
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev