[openssl-dev] [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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160811/753bb063/attachment.sig>