Bug 48192 - Allow to specify the SSLSocket class in connector tag of server.xml
Summary: Allow to specify the SSLSocket class in connector tag of server.xml
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Connectors (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2009-11-13 01:38 UTC by Ralf Hauser
Modified: 2009-11-22 22:32 UTC (History)
2 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Hauser 2009-11-13 01:38:44 UTC
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
Comment 1 Ralf Hauser 2009-11-18 06:12:49 UTC
this might solve the race condition problem in http://marc.info/?l=tomcat-dev&m=125855279313354&w=2
Comment 2 Mark Thomas 2009-11-19 13:37:27 UTC
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.
Comment 3 Ralf Hauser 2009-11-20 00:34:31 UTC
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
Comment 4 Bill Barker 2009-11-22 15:48:13 UTC
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.
Comment 5 Ralf Hauser 2009-11-22 22:32:26 UTC
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?