On 08/02/2013 14:28, dku...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
