in the connector as per http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html#Edit%20the%20Tomcat%20Configuration%20File , it should be possible to define a FQDN of a class implementing javax.net.ssl.SSLSocket This way it might be possible to implement one's own SSLSocket subclass. String org.apache.tomcat.util.net.jsse.JSSEImplementation.SSLSocketClass = "javax.net.ssl.SSLSocket" Must be enhanced to honor such a "sslSocketClass" attribute. This might allow to ban the currently harmful "kickstartHandshake()" renegotiation method as described in Bug 48158 comment 5
this might solve the race condition problem in http://marc.info/?l=tomcat-dev&m=125855279313354&w=2
Assuming this enhancement request is solely to address CVE-2009-3555, then I am closing this as WONTFIX as this is not the solution that will be implemented. Current thinking is that the solution to CVE-2009-3555 will be based on the solution proposed in bug48236 combined logging based on the original patch ie r881774. If there are other reasons for wanting this enhancement, feel free to re-open this issue. Enhancement requests with patches are more likely to be applied sooner.
yes, there are also other purposes, e.g. we might get a forensics requirement that we might have to record the exact handshake because in the AS-IS we see the ssl session id and the client certs, but we cannot prove to an independent third party that whoever connected to our tomcat really was in possession of the corresponding private key
There has been the capability to specify a custom SSLImplementation since Tomcat 3.3. That would be the proper way to inject your own SSL handling code into Tomcat.
Bill, do you mean "sslProtocol" of http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html#Edit%20the%20Tomcat%20Configuration%20File ? If so, isn't a different security provider a rather big piece of code to change for just some minor subclassing of a few (or even just 1) class?