Konstantin,
On 11/8/14 8:34 PM, Konstantin Kolinko wrote:
> 2014-11-08 20:07 GMT+03:00 Konstantin Kolinko <knst.koli...@gmail.com>:
>> 2014-11-03 12:52 GMT+03:00 Violeta Georgieva <miles...@gmail.com>:
>>> The proposed Apache Tomcat 7.0.57 release is now available for voting.
>>>
>>
>> Testing on Win7 with 32-bit JDKs
>> 1. All tests are passing with JDK 6u45 + 7u72 combo (compiling with
>> 6u45, all tests are run with 7u72) with all BIO, NIO, APR.
>>
>> 2. If I run the tests with JDK 6u45 only, the following tests are
>> consistently failing with BIO and succeeding with NIO and APR:
>>
>> org.apache.tomcat.util.net.TestClientCert
>> org.apache.tomcat.util.net.TestCustomSsl
>> org.apache.tomcat.util.net.TestSsl
>>
>> The failure in all cases is
>> javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
>>
>>
>> Quick recipe for reproduction is to use the following settings in
>> build.properties:
>> 1) Remove/comment the value for java.7.home if you have set one
>> 2) Set
>> test.name=org/apache/tomcat/util/net/**/Test*.java
>>
>>
>> It is odd that NIO tests do pass.
>> For APR most of those tests are skipped, so no much wonder.
>
> The tests pass if I add the following line to TestCustomSsl.java and
> TesterSupport.java.:
>
> [[[
> connector.setProperty("sslEnabledProtocols", "TLSv1,TLSv1.1,SSLv2Hello");
> ]]]
>
> Patch that I used:
>
> https://people.apache.org/~kkolinko/patches/2014-11-09_tc7_Java6_SSLHello.patch
>
> If I remove "SSLv2Hello" from the above value the tests with BIO fail.
> Why the tests pass with NIO connector is a mystery for me.I agree that BIO failing while NIO works is odd, but I wonder if the problem here is with the unit tests: the client is probably using the default SSL procotols which includes both SSLv3 and SSLv2Hello, probably using SSLv2Hello even if the protocol is higher (e.g. SSLv3, etc.). Without SSLv2Hello enabled on the server at all, the client cannot handshake because I think JSSE always uses SSLv2Hello if it's enabled on the client. Quick fix would be to change the unit tests, but the unit tests do expose a problem likely to be found in the wild: clients who use SSLv2Hello even if they only will use TLS for actual communication. http://stackoverflow.com/questions/26488667/tomcat-7-getting-sslv2hello-is-disabled-error-when-trying-to-make-client-server > I feared that NIO would have SSLv3 enabled by default, but I verified > that SSLv3 is disabled > > a) OpenSSL cannot connect with SSLv3 protocol. I used the followin command: > > openssl s_client -connect localhost:8443 -ssl3 -msg > > WhenIf I explicitly enable "SSLv3" with sslEnabledProtocols attribute, > then OpenSSL can connect with SSLv3. > > Connector configuration: > <Connector > port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" > address="127.0.0.1" > sslProtocol="tls" > keystoreFile="${catalina.base}/conf/localhost.jks" > truststoreFile="${catalina.base}/conf/ca.jks" > secure="true" > SSLEnabled="true" > /> > > The localhost.jks and ca.jks files were copied to conf directory from > /test/org/apache/tomcat/util/net\/ > > b) If I add the following line to logging.properties, > [[[ > org.apache.tomcat.util.net.jsse.JSSESocketFactory.level = FINE > ]]] > then I see log messages that SSLv2Hello and SSLv3 were disabled when > running the tests. > > FINE: The SSL protocol [SSLv2Hello] which is enabled by default in > this JRE was excluded from the defaults used by Tomcat > FINE: The SSL protocol [SSLv3] which is enabled by default in this JRE > was excluded from the defaults used by Tomcat > (...) > FINE: Specified SSL protocols that are supported and enableable are : > [TLSv1, SSLv2Hello] > FINE: Some specified SSL protocols are not supported by the SSL engine > : [TLSv1.1] > > > Smoke testing is OK. > > I think we are OK to release this. > > The test has to be patched to enable SSLv2Hello. (As an alternative > solution, maybe there a way to disable SSLv2Hello at the client side > of the connection ?) If using HttpsURLConnection, then the system property "-Dhttp.protocols=TLSv1,TLSv1.1,TLSv1.2" will make the client work. I think if clients in the wild start failing without SSLv2Hello enabled on the server, the admin can either explicitly enable SSLv2Hello on the server, or instruct their clients to stop using it. For Java clients using HttpsURLConnection (which will be the less-sophisticated clients), using the above system property can fix things up. Anyone using anything more complex is likely to have the ability to tweak the protocols used by the client and so neither case should represent a huge barrier for users. -chris
signature.asc
Description: OpenPGP digital signature
