Code review request, JDK-8052406, SSLv2Hello protocol may be filter out unexpectedly
Wang Weijun
weijun.wang at oracle.com
Thu Jul 31 01:11:05 UTC 2014
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
>>
>
More information about the security-dev
mailing list