Summary: | another workaround for CVE-2009-3555 for the BIO connector | ||
---|---|---|---|
Product: | Tomcat 5 | Reporter: | keilh <hartmut.keil> |
Component: | Connector:Coyote | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | hauser, moreira |
Priority: | P2 | ||
Version: | 5.5.28 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All |
Description
keilh
2009-11-19 04:51:14 UTC
Thanks for the alternative suggestion. I'll do some testign and if all looks OK, change the way we disable the handshake. *** Bug 48158 has been marked as a duplicate of this bug. *** Testing has been positive. I ended up keeping the listener from the original patch to log the handshake attempts. I'm not so concerned about the logging being in a separate thread and it was the easiest (only?) way to hook into the client triggered handshakes. Patch to trunk will follow shortly. Are there any junit or rather httpclient/httpunit tests for this? Or at least a detailed test script (e.g. documented in a wiki)? Looking forward to the new patch. Nothing formal, and the nature of the tests is such it might take a little longer than usual to set up something with the Tomcat JUnit tests. My testing uses a simple webapp that uses CLIENT-CERT and has one JSP that is protected by a security constraint. To test client renegotiation, I use openssl s_client and the R command To test server renegotiation, I use Firefox or IE and browse between the Tomcat homepage and the protected page. There is also org.apache.catalina.startup.TestTomcatSSL although a couple of tests are failing at the moment and I need to figure out why. I suspect it is because of some recent refactoring. The alternative patch has been applied to 6.0.x and will be included in 6.0.21 onwards. The new patch has been applied to 5.5.x and will be included in 5.5.29 onwards. |