On Jul 31, 2014, at 8:54, Xuelei Fan <xuelei....@oracle.com> wrote: > On 7/31/2014 8:14 AM, Wang Weijun wrote: >> The fix looks harmless, but I don't understand the test. What happens if >> SSLv2Hello is filtered out? >> > If SSLv2Hello is filtered out, this side would not support SSLv2Hello > any more.
The server side now only enables TLS_RSA_WITH_AES_128_CBC_SHA256. If other protocols are enabled, what will be the difference? You mean TLS 1.0 and 1.1 has built-in support for SSLv2Hello but TLS 1.2 does not? --Max > If SSLv2Hello format client hello requested, the server would > reject the connection. In the test case, before the fix, the connection > cannot be established as server side filters out SSLv2Hello protocol. > > Thanks, > Xuelei > >> --Max >> >> On Jul 30, 2014, at 20:56, Xuelei Fan <xuelei....@oracle.com> wrote: >> >>> Hi, >>> >>> Please review this fix for JDK-8052406: >>> >>> Webrev: http://cr.openjdk.java.net/~xuelei/8052406/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8049321 >>> >>> For TLS connections, if no suitable cipher suite available for a >>> particular TLS protocol, such protocol should not be negotiated. For >>> example, if only "TLS_RSA_WITH_AES_128_CBC_SHA256" enabled, as it is >>> only supported by TLS version 1.2, the connection should be negotiated >>> TLS version 1 and 1.1. >>> >>> In SunJSSE implementation, we check the binding of enabled protocols and >>> enabled cipher suites. SSLv2Hello may be improperly filter out when >>> making the checking above. Actually, SSLv2Hello is not a real SSL/TLS >>> protocol, it is only used as the format of ClientHello message. If >>> SSLv2Hello is enabled, it should not be filter out. >>> >>> This fix address the SunJSSE problem implementation above. >>> >>> Thanks, >>> Xuelei >> >
