Hi Jaikiran,
Thank you very much for the help!
JDK 12 repo (JDK repo):
http://hg.openjdk.java.net/jdk/jdk
JDK 11 repo:
http://hg.openjdk.java.net/jdk/jdk11
The patch should work for both repositories.
Thanks,
Xuelei
On 8/25/2018 7:44 AM, Jaikiran Pai wrote:
Hi Xuelei,
I can definitely build JDK 12 (jdk repo) from source and apply your
attached patch and give it a try. As for JDK 11, I haven't been
following the version control discussions/process, does it have a
separate repo now? Or is it some branch within jdk repo itself? Either
way, once I know the right repo location, I can (and in fact prefer)
building that repo with this patch to give it a try.
-Jaikiran
On 25/08/18 8:10 PM, Xuelei Fan wrote:
Hi Jaikiran,
Could you build JDK 11 or JDK 12 from source code? I had a patch to
tolerate the extension in ServerHello handshake message. Please let
me know if it works or not.
If there are any other JDK 11 TLS problems with Apache Ant project,
I'd like to know as well.
Thanks,
Xuelei
On 8/25/2018 7:04 AM, Jaikiran Pai wrote:
Hi Xuelei,
On 25/08/18 7:20 PM, Xuelei Fan wrote:
Sending "supported_groups" in ServerHello does not comply to the
extension specification.
Agreed. However, given that both the client and server are using TLSv1.2
and this seems to be "working" before the newer TLSv1.3 changes, even in
recent JDK versions, is there a way the implementation could workaround
this so as to allow JDK 11 to communicate with such servers?
Is it possible the HTTPS server fix this problem?
I don't have access or control over that server, so don't really know
how it's configured or whether it can be fixed. It's a pretty frequently
used Maven repository hosted by the JBoss (Red Hat middleware) project
team. I suspect, it's not just limited to this server and could be a
common issue with some other servers too.
I filed a bug in OpenJDK for the tracking:
https://bugs.openjdk.java.net/browse/JDK-8209965
Thank you.
-Jaikiran
Thanks,
Xuelei
On 8/25/2018 5:03 AM, Jaikiran Pai wrote:
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
-Jaikiran
On 25/08/18 11:58 AM, Jaikiran Pai wrote:
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
