Summary: | Use case-insensitive substring search when filtering SSLv2/v3 protocols in connectors | ||
---|---|---|---|
Product: | Tomcat 6 | Reporter: | Konstantin Kolinko <knst.kolinko> |
Component: | Connectors | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | ---- | ||
Hardware: | PC | ||
OS: | All | ||
Attachments: | 2014-11-25_tc6_57234_v1.patch |
Description
Konstantin Kolinko
2014-11-18 20:30:55 UTC
It's also feasible that a user would want to use SSLv2Hello, which is not really a protocol. One could argue that nobody should even be using SSLv2Hello since all of SSL should be dead, now -- any client that can use TLS should be able to use a proper TLS hello. (I didn't check to see if SSLv2Hello is returned by socket.getEnabledProtocols() but I wanted to mention it in case someone was going to patch this quickly.) > I didn't check to see if SSLv2Hello is returned by socket.getEnabledProtocols()
It is possible to turn on logging with
org.apache.tomcat.util.net.jsse.JSSESocketFactory.level = FINE
In my experiments SSLv2Hello is listed as present and excluded by protocol name filtering (running with Oracle JDK 8u25).
According to [2] Java 7 clients do not have SSLv2Hello enabled by default. Is there anything (non having EOL status) actively using it?
Do "generic purpose" web servers (configured by default) need it? It can be enabled with explicit configuration.
Fixed in trunk, 8.0.x (for 8.0.16 onwards) and 7.0.x (for 7.0.58 onwards). Comment added to existing proposal for Tomcat 6 to fix this as well. Created attachment 32226 [details] 2014-11-25_tc6_57234_v1.patch Patch for Tomcat 6. Backport of r1641377 + Includes patch by Christopher Schultz to de-duplicate code and fix name of the filtering method + A pair of compiler warning fixes (duplicate ';' and generics for a local variable). |