0

I read Oracle's doc here and have tried to enable TLSv1.2 on Java 7(1.7.0_80-b15) for a few day with no luck.

I wanna enable TLSv1.2 on it, so I can call a web service with https protocol. I use this code which I thought had enabled that already.

SSLContext ctx = SSLContext.getInstance("TLSv1.2");
            ctx.init(null, null, new SecureRandom());
            SSLContext.setDefault(ctx);

URL url = new URL ("https://testotp.ktc.co.th");
            HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
            conn.setSSLSocketFactory(ctx.getSocketFactory());

And I even put jdk.tls.disabledAlgorithms=SSLv2Hello, SSLv3, TLSv1, TLSv1.1 on java.security. Still, I got this error when the web service method was called.

AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode: 
 faultString: java.net.SocketException: Connection reset
 faultActor: 
 faultNode: 
 faultDetail: 
    {http://xml.apache.org/axis/}stackTrace:java.net.SocketException: Connection reset
    ...

So I set these debugger attributes on JVM and this is what I got.

For -Djavax.net.debug=ssl:defaultctx I got.

trigger seeding of SecureRandom
done seeding SecureRandom
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
%% No cached client session
*** ClientHello, TLSv1.2
...
...
main, WRITE: TLSv1.2 Handshake, length = 219
main, handling exception: java.net.SocketException: Connection reset
main, SEND TLSv1 ALERT:  fatal, description = unexpected_message
main, WRITE: TLSv1 Alert, length = 2
main, Exception sending alert: java.net.SocketException: Connection reset by peer: socket write error
main, called closeSocket()

For -Djavax.net.debug=ssl:sslctx I got

trigger seeding of SecureRandom
done seeding SecureRandom
trigger seeding of SecureRandom
done seeding SecureRandom
main, handling exception: java.net.SocketException: Connection reset
main, SEND TLSv1 ALERT:  fatal, description = unexpected_message
main, Exception sending alert: java.net.SocketException: Connection reset by peer: socket write error
main, called closeSocket()

From the first debugger, I assumed I had already enabled TLSv1.2 for it so I got "ClientHello, TLSv1.2", but handshake still failed and the socket got closed. It might have something to do with the face that TLS version in defaultctx is differnet from sslctx, but I don't quite understand what they are.

I also check that the web service has https protocol by running telnet https://thathost.com 443 and it does exist.

This post seems like my case, but there's no answer for it too. What can I try next?

halfer
  • 19,824
  • 17
  • 99
  • 186
KradasA4
  • 165
  • 1
  • 2
  • 11
  • Also, do read about TLS handshake if you haven't already. https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake – Saravana Kumar Sep 08 '20 at 16:41
  • Thanks. The process looks a lot clearer to me. Anyway, I still stuck at the same place. I tried to add certs, even trust all certs in the end, but the handshake still failed after Client Hello. I think it might be because of cipher suites, so I implement JCE Unlimited Strength Jurisdiction Policy and try to add some cipher suites using System.setProperty("https.ciphersuites", ...) and sslSocket.setEnabledCipherSuites( new String[] { *some cipherSuiteIThinkItMightWork}), but I still didn't go anywhere further. – KradasA4 Sep 09 '20 at 15:46
  • Actually, I can't just get cipher suites from Chrome because I did this in a remote desktop which have no internet and can't access https://thathost via browser yet. I can access the host with http protocol anyway since it's their internal server, the site is web service wsdl page. I already telnet to port 443 of that host and it worked just fine. My goal is to call the webservice via https of that host. The client side send client hello with TLS1.2,but I still failed without seeing server hello. Do you have any idea what's wrong here? Did I got something wrong from your comments? – KradasA4 Sep 09 '20 at 15:53
  • Please once try setting the unsafe renegotiation to true. `System.setProperty( "sun.security.ssl.allowUnsafeRenegotiation", "true" );` – Saravana Kumar Sep 09 '20 at 16:19
  • I just tried what you suggested and there's still no luck for me. This is the response I got from debugger. https://ibb.co/1vM8xTG – KradasA4 Sep 09 '20 at 17:35
  • @SaravanaKumar+ your first comment is wrong. `SSLContext.init` 2nd arg null uses the _default_ truststore, which unless overridden is normally the file JRE/lib/security/cacerts, which comes filled with all the 'usual' root CA certs like Digicert, GoDaddy, LetsEncrypt, etc. In any case, a problem with local trust (validation) would cause very a different exception and NEVER connection reset. Kradas: telnet doesn't test the SSL/TLS protocol at all; can you try curl or wget, or powershell get-webrequest, or similar which does do SSL/TLS (and HTTPS, but try a basic request like HEAD /). ... – dave_thompson_085 Sep 12 '20 at 11:58
  • ... Since the server is resetting in response to ClientHello, someone knowledgable looking at the actual contents which you have removed might be able to guess the problem, although it often depends on the server, which you also haven't described at all. Do you still get all the "Ignoring unavailable cipher suite" with unlimited policy in place? You shouldn't. On and @SaravanaKumar: the server cert would be in a separate message _after_ ServerHello. – dave_thompson_085 Sep 12 '20 at 12:00
  • Sorry for the wrong info @KradasA4 . thanks a lot for educating me dave_thompson_085 – Saravana Kumar Sep 12 '20 at 15:01

0 Answers0