Bug 57234 - Use case-insensitive substring search when filtering SSLv2/v3 protocols in connectors
Summary: Use case-insensitive substring search when filtering SSLv2/v3 protocols in co...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Connectors (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal (vote)
Target Milestone: ----
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-18 20:30 UTC by Konstantin Kolinko
Modified: 2014-12-06 19:27 UTC (History)
0 users



Attachments
2014-11-25_tc6_57234_v1.patch (4.22 KB, patch)
2014-11-25 13:07 UTC, Konstantin Kolinko
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Kolinko 2014-11-18 20:30:55 UTC
Regarding "protocol.contains("SSL")" check in org.apache.tomcat.util.net.jsse.JSSESocketFactory  from r1632512 etc.

If one reads [1], it has the following phrase at the top of the document:
"Note: Standard names are not case-sensitive."

I doubt that anybody is really bitten by this, as I doubt that any JVM vendor misspells "SSL"

On [1] there is a link named "Note: The Sun Provider Documentation contains specific provider and algorithm information.". If you follow it to [2], it lists the actual names used by Oracle JRE. Those are spelled with uppercase "SSL".

Nevertheless, technically it would be better to do protocol.toUpperCase(Locale.ENGLISH).contains("SSL")


[1] https://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#jssenames
[2] https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html
Comment 1 Christopher Schultz 2014-11-18 20:59:58 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.)
Comment 2 Konstantin Kolinko 2014-11-18 22:46:18 UTC
> 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.
Comment 3 Mark Thomas 2014-11-24 11:48:23 UTC
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.
Comment 4 Konstantin Kolinko 2014-11-25 13:07:08 UTC
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).
Comment 5 Konstantin Kolinko 2014-12-06 19:27:00 UTC
Fixed in Tomcat 6 by r1643590 and will be in 6.0.44 onwards.