Even after setting jsse.enableSNIExtension to true, enableSNIExtension in ClientHandshaker has value false

Question

I am trying to enable the SNI extension in my project. I set jsse.enableSNIExtension property by following ways: 1. Writing System.setProperty("jsse.enableSNIExtension", "true"); 2. Passing -Djsse.enableSNIExtension=true as VM argument

I printed the value of above property after application is started and the value printed is true however when the tlsv1.2 tries to establish the handshake with the server, the field in sun.security.ssl.ClientHandshaker.java private static final boolean enableSNIExtension = Debug.getBooleanProperty("jsse.enableSNIExtension", true); has value false which ultimately results in SNI header not being included in the extensions

The logs print this:

http-nio-9113-exec-2, setSoTimeout(60000) called
http-nio-9113-exec-2, the previous server name in SNI (type=host_name (0), value=xxx.yyy.zzz.com) was replaced with (type=host_name (0), value=xxx.yyy.zzz.com)
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
.
.
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
%% No cached client session
update handshake state: client_hello[1]
upcoming handshake states: server_hello[2]
*** ClientHello, TLSv1.2
RandomCookie:  GMT: 1558202243 bytes = { 110, 67, 239, 138, 239, 2, 107, 13, 194, 64, 33, 49, 50, 105, 199, 255, 255, 238, 186, 205, 18, 178, 196, 116, 148, 207, 115, 200 }
Session ID:  {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, .... TLS_DHE_DSS_WITH_AES_128_GCM_SHA256]
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, SHA224withECDSA, SHA224withRSA, SHA224withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
Extension extended_master_secret
Extension renegotiation_info, renegotiated_connection: <empty>
***

When getKickstartMessage() method is called in ClientHandshake.java, enableSNIExtension is set to false and hence serverNames is not set and requestedServerNames remains null.
                if (enableSNIExtension) {
                    if (this.session != null) {
                        this.requestedServerNames = this.session.getRequestedServerNames();
                    } else {
                        this.requestedServerNames = this.serverNames;
                    }

                    if (!this.requestedServerNames.isEmpty()) {
                        var11.addSNIExtension(this.requestedServerNames);
                    }
                }

Please help to solve this problem. Any leads are appreciated.

Phlegm

which Java version are you using ? – Soapy

Java 1.8. As I mentioned in the question I have tried all the options to enable SNI extension – Phlegm

Maybe duplicate of this question as there is a known bug with Java 8 (until 8u141 but you didn't give your exact version). If so, please close your question. – Soapy

Java 8u181 is the version – Phlegm

Not actually duplicate. I had tried the solution still does not work because problem is in ClientHandshaker.java. – Phlegm

ClientHandshaker is a child class of Handshaker which defines setSNIServerNames() method which is never called. Try calling this method to override the default behavior although the code comments are ambiguous. If OK, please post an answer to your question. – Soapy

I had a similar issue, where I would set jsse.enableSNIExtension to true, either using System.setProperty or the -D flag, but later I would find that jsse.enableSNIExtension had reverted to false and outbound Client Hello packets were not including the server_name extension. Ultimately, I found that that system property only persists once used, so I was able to resolve this by setting that property to true and making an outbound HTTPS call immediately afterwards, all on application start. Hacky, but it'll do until I find the library that's setting it to false. – Bedwarmer