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.
@Daniel
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
Deepak.
From: Mark Thomas <ma...@apache.org>
To: Tomcat Users List <users@tomcat.apache.org>
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, 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
"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."
