|Summary:||NIO and BIO connectors handle unsupported SSL ciphers and sslEnabledProtocols differently|
|Product:||Tomcat 7||Reporter:||Tim Whittington <timw>|
|Component:||Connectors||Assignee:||Tomcat Developers Mailing List <dev>|
|OS:||Mac OS X 10.4|
Description Tim Whittington 2013-01-10 21:09:19 UTC
The NIO and BIO connectors share (most of) a JSSE based SSLImplementation, but differ in their handling of the ciphers and sslEnabledProtocols attributes. The NIO connector sets the configured values for both attributes directly on the SSLEngine, which will fail immediately if any of them are unsupported. This makes creating a portable/superset collection of ciphers impossible - i.e. IBM JDKs do not support many of the cipher suite names used by JSSE and vice versa (usually TLS_ vs SSL_ prefixes differ) and the supported options differ between Java 6/7 etc. The BIO connector attempts to filter the specified values down to those supported by the SSL implementation, but has issues as well: if none of the specified ciphers/protocols are supported it will silently use the defaults of the SSL implementation, which can lead to unexpectedly (and unwittingly) insecure configurations. I propose to: - modify the NIO connector to use the same logic as the BIO connector to filter requested ciphers/protocols to supported values (by placing these operations on the SSLUtil interface). - modify the ciphers/protocols filtering logic to treat an explicit list of unsupported options as setting no supported ciphers/protocols and warn when this is done (it will also fail visibly with errors if SSL connections are attempted).
Comment 1 Christopher Schultz 2013-01-11 16:55:24 UTC
+1 There was a post to the users' list recently where a user attempted to configure JSSE using OpenSSL-style cipher names. The result was evidently that the Connector used the default list of ciphers. I assert that this is a security problem.
Comment 2 Tim Whittington 2013-01-13 22:10:20 UTC
Fixed in trunk and in 7.0.x and will be included in 7.0.36 onwards. The change involved a modification to the org.apache.tomcat.util.net.SSLUtil interface, which will require updates to custom SSLImplementations.