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]);
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.
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?
(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
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.
For now, I find two solutions for this problem to share: 1 improve the jdk to java8 and set the system property as Ralf Hauser said: System.setProperty("jdk.tls.rejectClientInitiatedRenegotiation", "true"); 2 use NIO to replace BIO protocol <!-- Define a HTTP/1.1 Connector on port 8443, JSSE NIO implementation --> <Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="8443" .../> this solution is finded from http://stackoverflow.com/questions/12359288/disabling-ssl-tls-renegotiation-in-tomcat