Code review request, JDK-8052406, SSLv2Hello protocol may be filter out unexpectedly

[Wang Weijun]

On Jul 31, 2014, at 8:54, Xuelei Fan <xuelei.fan at 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.fan at 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
>> 
>