tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: How to limit the number of renegotiations for a single TLS / SSL connection
Date Fri, 08 Feb 2013 15:13:51 GMT
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 to 
> renegotiate connections. The computational requirements for renegotiating 
> a connection are asymmetrical between the client and the server, with the 
> server performing several times more work. Since the remote host does not 
> appear to limit the number of renegotiations for a single TLS / SSL 
> connection, this permits a client to open several simultaneous connections 
> 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:

View raw message