Bug ID: JDK-8167472 Chrome interop regression with JDK-8148516

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 6	JDK 7	JDK 8	JDK 9	Other
6u141Fixed	7u131Fixed	8u121Fixed	9 b141Fixed	openjdk7uFixed

Bug report:
=========
There are issues with Chrome browser and Java9 ea+138 SSL. While I have investigated what could cause the issue I found following. When I disable following ciphers
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
then Chrome begins to work as expected.

Under other browsers like FireFox or Internet Explorer everything is fine.

One thing to mention, Java9 ea+121 worked fine even with Chrome, so I assume there was regression in one of following versions, but unsure in which one exactly.

In fact all Java SSL based servers are affected, Chrome refuses to run. I get something like that
Caused by: java.lang.NullPointerException
    at sun.security.ssl.EllipticCurvesExtension.getECGenParamSpec(java.base@9-ea/EllipticCurvesExtension.java:374)
    at sun.security.ssl.ECDHCrypt.<init>(java.base@9-ea/ECDHCrypt.java:63)
    at sun.security.ssl.ServerHandshaker.setupEphemeralECDHKeys(java.base@9-ea/ServerHandshaker.java:1584)
    at sun.security.ssl.ServerHandshaker.trySetCipherSuite(java.base@9-ea/ServerHandshaker.java:1368)
    at sun.security.ssl.ServerHandshaker.chooseCipherSuite(java.base@9-ea/ServerHandshaker.java:1172)
    at sun.security.ssl.ServerHandshaker.clientHello(java.base@9-ea/ServerHandshaker.java:800)
    at sun.security.ssl.ServerHandshaker.processMessage(java.base@9-ea/ServerHandshaker.java:237)
    at sun.security.ssl.Handshaker.processLoop(java.base@9-ea/Handshaker.java:1061)
    at sun.security.ssl.Handshaker$1.run(java.base@9-ea/Handshaker.java:1000)
    at sun.security.ssl.Handshaker$1.run(java.base@9-ea/Handshaker.java:997)
    at java.security.AccessController.doPrivileged(java.base@9-ea/Native Method)
    at sun.security.ssl.Handshaker$DelegatedTask.run(java.base@9-ea/Handshaker.java:1476)
    at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1189)
    at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1041)
    ... 26 more

As far as we have an automated tests for the fix, UR SQE OK to take it in CPU17_01

14-11-2016

Cause of the issue: In the past code, we ignore unknown curves. With the updated of JDK-8167472, there is a bug that for a unknown curves, a null reference will be returned. That's to say, JDK cannot work with unknown curves any more. For Chrome, it uses the extension which prefers a curve unknown/unsupported to our implementation. As results in failures. While the curves for Firefox and IE are also supported by JDK. Further more, the preferred 'curve' in Chrome browser is not actually a curve of EC algorithms, the extension is used for purpose other than EC curves by Google. If disabling the EC cipher suites, the EC curves will not be used any more. So the issue disappears.

07-11-2016

Simple and straightforward fix, no new regression test. I had tested with Chrome, the fix works as expected.

11-10-2016

Relates :	JDK-8167547 - Test that unsupported EC curves should not be selected during TLS handshaking
Relates :	JDK-8148516 - Increase the minimum strength of EC keys