SSLHandshakeException in HttpsURLConnection if security providers changed

[Mikhail Gromov]

Hi,

I'm facing weird issue using HttpsURLConnection, and I'm not sure if this is a problem in Conscrypt or JDK.

In short, if we run HTTPS request using new URL("https://mywebsite.com").openConnection(), after that add Conscrypt as most preferred security provider, after that wait some time and execute request again, then SSLHandshakeException is raised.

In details:

Environment:

Ubuntu 16.04.4 LTS, Linux 4.4.0-124-generic

Java(TM) SE Runtime Environment (build 1.8.0_171-b11)

Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)

Conscrypt 1.1.2

What I do:

Reproducer is here https://gist.github.com/mgtriffid/422652d4b5d6ecbbebb540712b66718b

Please note that sometimes (very rarely) this doesn't reproduce the error, so if you wish to reproduce this issue, please retry couple of times if you don't see the exception on first attempt.

What I expect to see:

Both requests finish correctly

What I see instead:

Exception in thread "main" javax.net.ssl.SSLHandshakeException: Unsupported curve: 1.2.840.10045.3.1.7

at sun.security.ssl.HandshakeMessage$ECDH_ServerKeyExchange.<init>(HandshakeMessage.java:1066)

at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:284)

at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)

at sun.security.ssl.Handshaker.process_record(Handshaker.java:987)

at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)

at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)

at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)

at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)

at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)

at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)

at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1564)

at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)

at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:263)

at com.mgtriffid.polygon.conscrypt.UnsupportedCurveReproducer.get(UnsupportedCurveReproducer.java:34)

at com.mgtriffid.polygon.conscrypt.UnsupportedCurveReproducer.getGiphy(UnsupportedCurveReproducer.java:23)

at com.mgtriffid.polygon.conscrypt.UnsupportedCurveReproducer.main(UnsupportedCurveReproducer.java:19)

Notes:

If we insert Conscrypt provider at position 1, run request, remove Conscrypt provider, run request again, like this

    public static void main(String[] args) throws IOException, InterruptedException {

        Security.insertProviderAt(new OpenSSLProvider(), 1);

        getGiphy();

        Security.removeProvider("Conscrypt");

        Thread.sleep(30000);

        getGiphy();

    }

, then both requests run correctly. Also if we add Conscrypt prior to any call, then both requests are executed well.

Again, I'm not sure if this is a bug in Conscrypt or JDK or am I misusing HttpsURLConnection (that's why I'm writing it here and not in Github). If you have an idea on what am I doing wrong, could you please suggest what can be a workaround?

Thanks!

Mikhail Gromov.

[Adam Vartanian]

So, there are a couple things going on here.

First, the JDK sets the default SSLSocketFactory the first time it's
asked for, which means that in the first scenario, both connections
will be using the JDK provider for TLS. The JDK provider uses the
highest-priority security provider for a lot of internal
implementation details, though, which means that in the second
connection you're going to be using the JDK TLS provider but Conscrypt
for various internal crypto operations, which is a weird
configuration, but should in theory work.

However, that configuration ends up failing, and it looks like what's
happening is the JDK TLS provider is asking for EC curve parameters
using an ECGenParameterSpec that has an OID in it. Conscrypt doesn't
support this: ECGenParameterSpec's documentation calls for using a
"standard name", which seems pretty clear to me that it should only be
called with a curve name (eg, "prime256v1") rather than an OID
("1.2.840.10045.3.1.7"), so Conscrypt doesn't accept OIDs. I would
consider this a bug in the JDK TLS provider, but they might argue that
"standard name" includes OIDs. If there's wide demand for this, we
could consider allowing OIDs in Conscrypt as well, but we haven't had
much call for that so far.

In any case, we definitely recommend that if you're going to use
Conscrypt you install it as soon as possible after starting your
program, so that you are sure to get Conscrypt set up properly for
everything you want to do.

- Adam

> --
> You received this message because you are subscribed to the Google Groups
> "conscrypt" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to conscrypt+...@googlegroups.com.
> To post to this group, send email to cons...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/conscrypt/76d0437b-6ea2-4242-9f69-268cf5a696e0%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Mikhail Gromov]

Thanks for such a quick response, appreciate that! Yes, also came to the conclusion that we'd better install Conscrypt as soon as possible.

Have a nice day!

вторник, 22 мая 2018 г., 21:25:40 UTC+7 пользователь Mikhail Gromov написал:

[jhemm...@googlemail.com]

Thank you both for this.  I had managed to pin this down to changing the SSLProvider between different calls to httpsurlconnection.  I have changed the provider as the first process in my system and it all seems to work.  (Although I have only just changed this).  I think there are other methods of other classes that can cause this problem as well as initially when I had the problem I don't think I was doing a urlconnection first.