Best way of preventing denial of service attacks by way of secure client-initiated renegotiation
tim.j.culhane at gmail.com
tim.j.culhane at gmail.com
Mon Apr 15 08:35:28 UTC 2019
A customer of ours was recently running security checks against our mail
server. To do this they were running the testssl.sh script available at:
The test tool reports a potential DoS thread as a result of client-initiated
secure renegotiation as shown from the following line from the test tool's
[1m Secure Client-Initiated Renegotiation [m[0;33mVULNERABLE (NOT
ok)[m, potential DoS threat
I have also reproduced their findings in-house.
Our mail server is using version 1.0.2g of openssl and the client openssl
version was 1.0.2j.
In the testssl.sh script it connects to the ssl port using TLS1.2 and the
When I do a similar test in my test environment I get results like the
Issue a connect request, pause for 1 second and then Send 'R' to start a
(echo -n; sleep 1; echo R) | openssl s_client -CAfile NightlyBuild-CA.cert
-crlf -tls1_2 -legacy_renegotiation -connect <hostname>:465
Output is as follows:
i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms:
Shared Requested Signature Algorithms:
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
SSL handshake has read 1297 bytes and written 445 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
No ALPN negotiated
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 61 3a da 77 02 6c 7e 26-c1 98 84 ae 26 21 8f 1d
Start Time: 1555315404
Timeout : 7200 (sec)
Verify return code: 0 (ok)
220 devimpala13.es.cpth.ie ESMTP Service ready
depth=1 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
depth=0 C = ie, CN = something, CN = devimpala13.es.cpth.ie
So, as you can see the initial connection is successful. The
renegotiation begins and it returns:
I'm not sure if this means renegotiation has failed? Either way the
connection remains open. Presumably if a client issued a large number of
renegotiations like this the server could become overwhelmed.
Note that I got the same results if I remove the -legacy_renegotiation
option, so I don't think this has any impact?
So, I suppose I firstly need to know if the results from testssl.sh and from
my own investigations point to a potential security risk by way of a DoS
If so, what is the best way to prevent this.
>From what I've read online it isn't possible to disable client-initiated
secure renegotiation in openssl.
Indeed, it could be argued that there are circumstances when it is perfectly
valid for a client to renegotiate a connection especially if it is a
The only way I could find of limiting such an attack was to track the
number of renegotiation requests over a time and if we get a high number in
a short period then close the connection.
I believe this can be done in a callback function set up via a call to:
So, is the above information correct or is there a better way of preventing
this sort of attack. Do we really need to allow a limited form of
client-based secure renegotiation?
If preventing an attack by way of monitoring the number of renegotiations
over time is the only good approach, do you have any code examples in C as
to how to implement this?
More information about the openssl-users