tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
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, dkumar@ccilindia.co.in 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:

<quote>
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]:

<quote>
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.
</quote>

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.

Mark
on behalf of the Apache Tomcat security team
</quote>

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.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message