https://issues.apache.org/bugzilla/show_bug.cgi?id=57116

            Bug ID: 57116
           Summary: Bio connector: Do not fallback to default protocol
                    list if "sslEnabledProtocols" has no matches
           Product: Tomcat 6
           Version: 6.0.41
          Hardware: PC
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Connectors
          Assignee: dev@tomcat.apache.org
          Reporter: knst.koli...@gmail.com

I noted this issue while reviewing Mark's patch to disable SSLv3 proposed for
Tomcat 6, but it is present in the code before that patch and is reproducible
with 6.0.42.

Steps to reproduce:
1. Configure an HTTPS connector in Tomcat using BIO protocol
2. Set sslEnabledProtocols property on that connector to some random value.

1.+2. may be done by the following steps:
a) Create a public key pair for localhost with
$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA
and specify a password value of "changeit".
"Your name" field is "localhost", the other fields are "Unknown".
b) Paste the following into server.xml:
    <Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
               SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS"
               sslEnabledProtocols="foo" />

3. Start Tomcat
4. Expected: Connector start failure due to broken configuration.
Actual: Tomcat starts successfully and can be accessed via
https://localhost:8443/

Cause:
======
In JSSESocketFactory.initServerSocket(ServerSocket ssocket) there is the
following code:

        String requestedProtocols = (String) attributes.get("protocols");
        setEnabledProtocols(socket, getEnabledProtocols(socket,
                                                         requestedProtocols));

The "getEnabledProtocols(..)" method filters requested protocols vs.
socket.getSupportedProtocols(). If there is no match, it returns null.

The "setEnabledProtocols(..)" does
        if (protocols != null) {
            socket.setEnabledProtocols(protocols);
        }

Thus instead of failing with a message, it silently falls back to using the
default list of enabled protocols on a socket.

The problem is that the default protocol list may be less secure, that server
administrator has tried to configure.

Improve error checking
=========================
I think that silent filtering of sslEnabledProtocols by
socket.getSupportedProtocols() is wrong. In case of a typo, e.g.
sslEnabledProtocols="TLSv1,foo" the "foo" value shall cause a configuration
error instead of being silently filtered.

The Nio connector uses different implementation, via
NioEndpoint.createSSLEngine() ->
engine.setEnabledProtocols(sslEnabledProtocolsarr)
and that method is documented to throw IllegalArgumentException on unsupported
protocol names. [1]

[1]
http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLEngine.html#setEnabledProtocols%28java.lang.String[]%29


The behaviour of Nio connector cannot be tested in 6.0.41/6.0.42, as it does
not handle "sslEnabledProtocols" attribute due to bug 57102. Testing it with
the current tc6.0.x @1632897 it starts successfully, but a web browser cannot
connect to it. The following is logged for each connection attempt via HTTPS
(using JDK 5u20):

[[[
19.10.2014 18:09:26 org.apache.tomcat.util.net.NioEndpoint setSocketOptions
SEVERE: 
java.lang.IllegalArgumentException: foo
    at
com.sun.net.ssl.internal.ssl.ProtocolVersion.valueOf(ProtocolVersion.java:120)
    at com.sun.net.ssl.internal.ssl.ProtocolList.<init>(ProtocolList.java:36)
    at
com.sun.net.ssl.internal.ssl.SSLEngineImpl.setEnabledProtocols(SSLEngineImpl.java:1723)
    at
org.apache.tomcat.util.net.NioEndpoint.createSSLEngine(NioEndpoint.java:1145)
    at
org.apache.tomcat.util.net.NioEndpoint.setSocketOptions(NioEndpoint.java:1098)
    at
org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:1331)
    at java.lang.Thread.run(Thread.java:595)
]]]

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to