SNI Support in Quarkus's Undertow websocket

[gorshkov-leonid]

Hello, I am not a specialist in this question, but It seemed I have a problem because Quarkus does not support SNI extension in SSL. Although I tested it with HTTP rest-client and there were no problems.

Details:
*I have a the same problem, the same message and the same difference between rest's logs and websocket's logs:

• Problem: https://stackoverflow.com/questions/30817934/extended-server-name-sni-extension-not-sent-with-jdk1-8-0-but-send-with-jdk1-7
• The same problem: https://stackoverflow.com/questions/29714455/got-handshake-failure-using-java-netty-but-succeeded-with-curl-for-the-same-htt

*** ClientHello, TLSv1.2
RandomCookie:  GMT: 1571238552 bytes = { 125, 241, 169, 6, 39, 103, 208, 112, 16, 73, 146, 115, 185, 122, 155, 35, 69, 225, 103, 209, 161, 159, 5, 137, 54, 165, 78, 99 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
***

vs

*** ClientHello, TLSv1.2
RandomCookie:  GMT: 1571238202 bytes = { 191, 255, 75, 40, 82, 20, 198, 108, 27, 89, 101, 152, 184, 97, 12, 203, 201, 86, 244, 33, 33, 22, 183, 124, 59, 107, 104, 109 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods:  { 0 }
Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
Extension server_name, server_name: [type=host_name (0), value=myhost.com]
***

I decided to find where this extension is set in vertex (because HTTP rest-client works):

• https://github.com/eclipse-vertx/vert.x/blob/3.8.5/src/main/java/io/vertx/core/http/impl/HttpServerChannelInitializer.java#L102

But in websockets-jsr I can't see any mentions of SNI and SSLEngine is created without host and port:

• https://github.com/quarkusio/quarkus-http/blob/3.0.4.Final/websockets-jsr/src/main/java/io/undertow/websockets/jsr/WebsocketConnectionBuilder.java#L189

But I decided to check how things are going here: https://github.com/undertow-io/undertow/
And found that they suggest some SNISSLContextSpi

Could you help with an answer if it is a bug, or not?

[stuartwdouglas]

I think this should fix it: b2ea4eb I will try and get this into the next 1.4 release. Stuart

…

On Tue, 28 Apr 2020 at 07:11, Leonid Gorshkov ***@***.***> wrote: Hello, I am not a specialist in this question, but It seemed I have a problem because Quarkus does not support SNI extension in SSL. Although I tested it with HTTP rest client and there were no problems. Details: *I have a problem, stack trace and so one as here:* https://stackoverflow.com/questions/2804551/tls-with-sni-in-java-clients So, as I found out that it is related on changes in java https://stackoverflow.com/questions/30817934/extended-server-name-sni-extension-not-sent-with-jdk1-8-0-but-send-with-jdk1-7 I decided to find where this extension is set in vertx: - https://github.com/eclipse-vertx/vert.x/blob/3.8.5/src/main/java/io/vertx/core/http/impl/HttpServerChannelInitializer.java#L102 But in websockets-jsr I can't see any mentions of SNI and SSLEngine is create without host and port: - https://github.com/quarkusio/quarkus-http/blob/3.0.4.Final/websockets-jsr/src/main/java/io/undertow/websockets/jsr/WebsocketConnectionBuilder.java#L189 But I decided to check how things are going here: https://github.com/undertow-io/undertow/ And found that they suggest some SNISSLContextSpi Could you help with an answer if it is a bug, or not? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#23>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQG67PJ3Z5JXYK54HP6NLROXYHBANCNFSM4MSISFWA> .

[gorshkov-leonid]

@stuartwdouglas , thank you. I checked the fix via java hot swap. Although a test failed It is working in my case. About releases how long does it take usually to prepare release? And while it is preparing, maybe you know any WA. I tried solution from this, but it is not working:

        URI uri = URI.create(webSocketUrl);
        SSLParameters sslParameters = new SSLParameters();
        sslParameters.setServerNames(singletonList(new SNIHostName(uri.getHost())));
        HttpsURLConnection.setDefaultSSLSocketFactory(
                new SSLSocketFactoryWrapper(
                        WebSocketClientSslProviderImpl.getSystemSslContext().getSocketFactory(),
                        sslParameters
                )
        );

Apparently factory is not used... Are you aware of something about it?

[stuartwdouglas]

We don't use HttpsURLConnection

[gorshkov-leonid]

@stuartwdouglas , sorry for the bother. As I understand you do not know a workaround, are you? And when the next release is planned?