Re: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation
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
Re: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation
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 signature.asc Description: This is a digitally signed message part. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation
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
Re: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation
On Tuesday, 9 August 2016 21:51:32 CEST Sebastian Andrzej Siewior wrote: > On 2016-08-09 19:26:44 [+], 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 signature.asc Description: This is a digitally signed message part. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [RFC PATCH] doc/ssl: describe the possible DoS via repeated SSL session re-negotiation
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
