You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2013/09/08 22:30:24 UTC
[Bug 55536] New: allow to disable Secure Client-Initiated
Renegotiation - DOS risk
https://issues.apache.org/bugzilla/show_bug.cgi?id=55536
Bug ID: 55536
Summary: allow to disable Secure Client-Initiated Renegotiation
- DOS risk
Product: Tomcat 7
Version: unspecified
Hardware: PC
Status: NEW
Severity: enhancement
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: hauser@acm.org
The Apache/2.2.24 (FreeBSD) mod_ssl/2.2.24 OpenSSL/1.0.1e of
https://www.ssllabs.com/ssltest/analyze.html?d=issues.apache.org doesn't allow
Secure Client-Initiated Renegotiation
It is considered dangerous for DoS attacks:
https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks
How could this be done with tomcat7?
http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme-141115.html
maybe the approach of bug 48236 could be used for this purpose again?
// after creation, immediately disable all ciphers, avoiding any subsequent
handshake
((SSLSocket)sock).setEnabledCipherSuites(new String[0]);
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 55536] allow to disable Secure Client-Initiated Renegotiation -
DOS risk
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55536
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
OS| |All
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
http://tomcat.markmail.org/thread/xkxhfdrp6tslwkao
I've yet to see anyone argue that adding rate limiting to SSL renegotiations
for BIO and NIO is a worthwhile exercise. I'm not against it if there is a use
case and I have a few ideas on how it might be done. But, at the moment, I
simply don't see the point.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 55536] allow to disable Secure Client-Initiated Renegotiation
in Java TLS - DOS risk
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55536
--- Comment #4 from Ralf Hauser <ha...@acm.org> ---
with java8, a per Ivan Ristic's excellent article
http://blog.ivanristic.com/2014/03/ssl-tls-improvements-in-java-8.html,
adding somewhere even in your application code
System.setProperty("jdk.tls.rejectClientInitiatedRenegotiation", "true");
appears to have the same effect, albeit not thread-safe, but on a jvm-wide
level.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 55536] allow to disable Secure Client-Initiated Renegotiation
in Java TLS - DOS risk
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55536
Ralf Hauser <ha...@acm.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|allow to disable Secure |allow to disable Secure
|Client-Initiated |Client-Initiated
|Renegotiation - DOS risk |Renegotiation in Java TLS -
| |DOS risk
--- Comment #2 from Ralf Hauser <ha...@acm.org> ---
This RFE is not about APR, but the Java side of SSL/TLS.
But even then, I am not going to argue with you about renegotiation rate limit
meaningfulness - I leave the to qualsys and their ssllabs.
At least in Tomcat v>=7, it appears this might be relatively easily doable with
overwriting JSSEImplementation
public SSLSupport getSSLSupport(Socket s) {
}
and doing the setEnabledCipherSuites(new String[0]) .
Then put your new class into "sslImplementationName" as per
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL%20Support
Does this sound right?
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 55536] allow to disable Secure Client-Initiated Renegotiation
in Java TLS - DOS risk
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55536
--- Comment #3 from Mark Thomas <ma...@apache.org> ---
(In reply to Ralf Hauser from comment #2)
> This RFE is not about APR, but the Java side of SSL/TLS.
I'm aware of that. APR is an optional solution.
> But even then, I am not going to argue with you about renegotiation rate
> limit meaningfulness - I leave the to qualsys and their ssllabs.
It is a view, just not one I agree with. There does not appear to be a
consensus on this. My testing with Tomcat is consistent with others that have
tested OpenSSL that the difference between one connection and lots of
renegotiations and lots of connections each with an initial handshake is
minimal.
> At least in Tomcat v>=7, it appears this might be relatively easily doable
> with
> overwriting JSSEImplementation
> public SSLSupport getSSLSupport(Socket s) {
> }
> and doing the setEnabledCipherSuites(new String[0]) .
> Then put your new class into "sslImplementationName" as per
> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL%20Support
>
> Does this sound right?
I haven't tested it but that is the right sort of thing to be doing.
Mark
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org