tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: How to limit the number of renegotiations for a single TLS / SSL connection
Date Sat, 09 Feb 2013 09:05:44 GMT
Hello All,

@ Mark

we have not specified any specific connector protocol in the connector 
tag, is that mean we are using native APR connector, and if it is so, then 
as renegotiation is not permitted in APR why VA tool says renegotiation 
DoS vulnerability, and it would be of great help if you explain how to 
implement HTTP NIO or BIO connector to handle this renegotiation issue.


Please find the connector tag of sever.xml

<Connector port="8443" SSLEnabled="true" acceptCount="500" ciphers="Some 
cipher" allowUnsafeLegacyRenegotiation="false"
               maxThreads="5" scheme="https" secure="false" 
               clientAuth="false" sslProtocol="TLS" 
keystoreFile="cert.key" keystorePass="password" />

Any help wold be appreciated.
Thanks and regards


From:   Mark Thomas <>
To:     Tomcat Users List <>
Date:   02/08/2013 08:44 PM
Subject:        Re: How to limit the number of renegotiations for a single 
TLS / SSL connection

On 08/02/2013 14:28, wrote:
> Hello All,
> We are using -
> Tomcat Version - 6.0.18
> Operating System Version : HP-UX 11.31
> SSL Version -  OpenSSL 0.9.8k 25 Mar 2009
> Port - 8443
> By running the venerability assessment test we are getting the following 

> observation 
> The remote service encrypts traffic using TLS / SSL and permits clients 
> renegotiate connections. The computational requirements for 
> a connection are asymmetrical between the client and the server, with 
> server performing several times more work. Since the remote host does 
> appear to limit the number of renegotiations for a single TLS / SSL 
> connection, this permits a client to open several simultaneous 
> and repeatedly renegotiate them, possibly leading to a denial of service 

> condition.
> Please suggest the recommended solution for tomcat

To repeat what I have said privately on this topic:

The Apache Tomcat security team has reviewed the available information
for CVE-2011-1473 and has performed some testing of Apache Tomcat
using one of the many tools that has be written to demonstrate this issue.

Our conclusions are:

- In terms of CPU usage there is not a large difference (same order of
magnitude) between a client creating multiple HTTPS connections and a
client creating a single HTTPS connection and repeatedly requesting
renegotiation. This is consistent with the findings / opinions of the
numerous SSL/TLS experts that have commented on this issue.

- Repeated renegotiation attempts from a single client can be detected
by a firewall.

- Multiple connection attempts from a client are easier for a firewall
to identify than multiple renegotiation requests.

- Client renegotiation is not permitted by the HTTP APR/native connector.

- It would be possible to add renegotiation rate limiting to the HTTP
BIO and NIO connectors but there is not a clear-cut case for doing this.

We would also draw your attention to the following text on the Apache
Tomcat website security pages [1]:

Note that all networked servers are subject to denial of service
attacks, and we cannot promise magic workarounds to generic problems
(such as a client streaming lots of data to your server, or
re-requesting the same URL repeatedly). In general our philosophy is
to avoid any attacks which can cause the server to consume resources
in a non-linear relationship to the size of inputs.

Further discussion of this issue, particularly the usefulness of
adding renegotiation rate-limiting to the the HTTP BIO and NIO
connectors, should take place on the public Tomcat users mailing list.

on behalf of the Apache Tomcat security team

With all the above in mind is there an argument for introducing
renegotiation rate limiting for BIO and NIO? Or do we just say if you
are bothered about CVE-2011-1473, use APR.


To unsubscribe, e-mail:
For additional commands, e-mail:

"Disclaimer and confidentiality clause -
 This message and any attachments relating to official business of CCIL OR ANY OF IT'S SUBSIDIARIES
is proprietary to CCIL and intended for the original addressee only.
The message may contain information that is confidential and subject to legal privilege. 
Any views expressed in this message are those of the individual sender. 
If you have received this message in error, please notify the original sender immediately
and destroy the message and copies thereof and any attachments contained in it .
 If you are not the intended recipient of this message, you are hereby notified that you must
not disseminate, copy, use, distribute, or take any action in connection therewith. 
 CCIL cannot ensure that the integrity of this communication has been maintained nor that
it is free of errors, viruses, interception and/or interference. 
CCIL is not liable whatsoever for loss or damage resulting from the opening of this message
and/or attachments and/or the use of the information contained in this message and/or attachments."
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message