|Summary:||Misconfigured SSLProtocol with an AprEndpoint silently falls back to ALL|
|Product:||Tomcat 5||Reporter:||Colin Harrington <colin>|
|Component:||Connector:Coyote||Assignee:||Tomcat Developers Mailing List <dev>|
Description Colin Harrington 2011-04-16 00:20:22 UTC
When configuring tomcat with an SSL Connector with an AprEndpoint (using the Http11AprProtocol) if you misconfigure the SSLProtocol, the it silently falls back to "all" which can be very dangerous. For example this configuration may seem convincing: <Connector protocol="org.apache.coyote.http11.Http11AprProtocol" SSLEnabled="true" port="443" scheme="https" secure="true" ...Other SSL configuration... SSLProtocol="-ALL +SSLv3 +TLSv1" .../> The Documentation states valid values for the SSL protocol, but if the values don't line up exactly it defaults to "ALL" http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL%20Support SSLProtocol: 'Protocol which may be used for communicating with clients. The default is "all", with other acceptable values being "SSLv2", "SSLv3", "TLSv1" and "SSLv2+SSLv3".' Misconfiguration of an SSLProtocol should never silently fall back to enabling all protocols. At minimum, misconfiguration of this value should result in logged error messages. Since SSLv2 is vulnerable to several attacks known to have some serious security flaws even allowing the possibility of man-in-the-middle attacks, I think a misconfiguration should cause the connector to fail. @See http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java I think that "all" should be specifically allowed (along with "" or null), and all other unexpected values should fail loudly.
Comment 1 Mark Thomas 2011-04-17 09:02:13 UTC
Fixed in 7.0.x and will be included in 7.0.13 onwards. Proposed for 5.5.x and 6.0.x.
Comment 2 Mark Thomas 2011-05-18 12:12:19 UTC
Fixed in 6.0.x and will be included in 6.0.33 onwards.
Comment 3 Mark Thomas 2011-08-18 17:05:48 UTC
This has been fixed in 5.5.x and will be included in 5.5.34 onwards.
Comment 4 changyao 2011-11-09 02:12:12 UTC
(In reply to comment #2) > Fixed in 6.0.x and will be included in 6.0.33 onwards.