JDK-8209965 : The "supported_groups" extension in ServerHellos
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-08-25
  • Updated: 2020-11-23
  • Resolved: 2018-08-27
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 11 JDK 12 JDK 8 Other
11.0.2Fixed 12 b09Fixed 8u261Fixed openjdk8u272Fixed
Related Reports
Duplicate :  
JDK-8209982 - SSL handshake fails on an (apparently) correct certificate, working in jdk10
Relates :  
JDK-8202625 - TLS 1.3 Implementation
Relates :  
JDK-8210974 - No extensions debug log for ClientHello
Sub Tasks
JDK-8210070 :  
Release Note: supported_groups Extension Should Not be Present in ServerHello Handshake Message - Closed
Description
Reported in OpenJDK:
http://mail.openjdk.java.net/pipermail/security-dev/2018-August/018005.html
----------
While testing the recently released RC of JDK11 against the Apache Ant
project, I happened to run into an odd error. I have now been able to
reproduce this using the following, pretty trivial code:

import java.net.URL;
import java.io.InputStream;

public class Fetch {
     public static void main(final String[] args) throws Exception {
         final URL targetURL = new
URL("https://repository.jboss.org/nexus/content/groups/public/javax/media/jai-core/1.1.3/jai-core-1.1.3.pom");
         try (final InputStream is =
targetURL.openConnection().getInputStream()) {
             is.read();
         }
         System.out.println("Done");
     }
}

All it does is opens a (HTTPS) connection against an endpoint to read
some content. This code works fine in Java 8 and even Java 10. I'm
pretty sure this was working fine even in Java 11 early access builds,
but I don't have any such build/binary at hand to be certain.

However, using the latest (OpenJDK) RC of Java 11 (both on Mac OS and
Linux) downloaded from[1]:

openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)

it fails with:


Exception in thread "main" javax.net.ssl.SSLHandshakeException:
extension (10) should not be presented in server_hello
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
    at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
    at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
    at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:255)
    at
java.base/sun.security.ssl.SSLExtensions.<init>(SSLExtensions.java:71)
    at
java.base/sun.security.ssl.ServerHello$ServerHelloMessage.<init>(ServerHello.java:173)
    at
java.base/sun.security.ssl.ServerHello$ServerHelloConsumer.consume(ServerHello.java:864)
    at
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
    at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
    at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
    at
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
    at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
    at
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
    at
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
    at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
    at
java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
    at
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
    at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581)
    at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)
    at
java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245)
    at Fetch.main(Fetch.java:7)


[1] http://jdk.java.net/11/

-Jaikiran


http://mail.openjdk.java.net/pipermail/security-dev/2018-August/018006.html
-------------
As noted in that exception message, it appears that the server is
sending a "supported_groups" extension in its ServerHello message
(TLSv1.2). Reading about it, this seems to be a common issue with
certain servers and certain SSL implementations have added support to be
lenient with such servers https://github.com/openssl/openssl/pull/4463/files
Comments
Backport request: http://mail.openjdk.java.net/pipermail/security-dev/2018-November/018777.html
16-11-2018
Another sighting here: https://stackoverflow.com/questions/52414255/maven-with-jdk-11-fails-when-downloading-a-wrong-dependency-with-extension-10
23-09-2018
Per the extension specification, the supported_groups extension should not be present in the ServerHello handshake message. However, some third part's implementation wraps the extension in ServerHello, which is illegal. As the buggy implementation have been deployed already, we may want to tolerate this issue. Otherwise, there are interop issues with these deployed TLS implementation. The fix is straightforward and the bug reporter had verified the fix. The risk should be very low. No dependence on other fixes.
19-09-2018
URL: http://hg.openjdk.java.net/jdk/jdk/rev/a8cf90dc8782 User: xuelei Date: 2018-08-27 16:46:39 +0000
27-08-2018
No new regression test, noreg-external. The patch was tested by the bug reporter (http://mail.openjdk.java.net/pipermail/security-dev/2018-August/018013.html)
26-08-2018