2

I am trying to connect to a response from a external site

      at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
        at sun.security.ssl.InputRecord.read(InputRecord.java:505)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975)
        ... 56 more
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake

my code:

CloseableHttpClient httpClient2 = null;
        try {
             httpClient2 = (CloseableHttpClient) getTLS();
        } catch (KeyManagementException e1) {
            // TODO Auto-generated catch block
            e1.printStackTrace();
        } catch (UnrecoverableKeyException e1) {
            // TODO Auto-generated catch block
            e1.printStackTrace();
        } catch (NoSuchAlgorithmException e1) {
            // TODO Auto-generated catch block
            e1.printStackTrace();
        } catch (KeyStoreException e1) {
            // TODO Auto-generated catch block
            e1.printStackTrace();
        }
        
        
public HttpClient getTLS() throws KeyManagementException, 
    UnrecoverableKeyException, NoSuchAlgorithmException, KeyStoreException {
        SSLContext sSLContext = SSLContext.getInstance("TLS");
        sSLContext.init(null, null, null);
        SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(
                sSLContext,
                new String[] { "TLS" },
                null,
                SSLConnectionSocketFactory.getDefaultHostnameVerifier());
        CloseableHttpClient httpClient = HttpClients.custom().setSSLSocketFactory(sslsf).build();   
        return httpClient;
    }

I have added the .pem certificte the keystore

 myserverURL.pem /usr/local/openjdk-8/jre/lib/security

I tried to check the following command and see that TLSv1.3 is being used.

curl --insecure -vvI https://myserverURL.com 2>&1 | awk 'BEGIN { cert=0 } /^\* SSL connection/ { cert=1 } /^\*/ { if (cert) print }'

* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server did not agree to a protocol

Client has:

* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1

This was working fine earlier. I guess the protocol has been changed on the server-side to TLSv1.3. Is it possible to connect from 1.2 to 1.3

Nidheesh
  • 4,390
  • 29
  • 87
  • 150

1 Answers1

3

If the server is tagged with -tls1_3 then it will "Only ever talk TLSv1.3". The server would need that to be removed to allow TLSv1.2 compatibility from your client. However, it may be a security architectural design for the server to use TLSv1.3

See this article on ssl.com: TLS 1.3 Is Here to Stay

It states the following: "TLS 1.3 abandons backwards compatibility in favor of a proper security design. It has been designed from scratch to provide functionality similar (yet not compatible) to TLS 1.2, but with significantly improved performance, privacy and security."

Various flavours of OpenJDK 8 backported support for TLS 1.3 at different release points, see below for some examples:

Flavour Release
AdoptOpenJDK 8u272
Azul Zulu JDK 8u262/8u272/8u292
Oracle OpenJDK 8u261
Amazon Corretto 8u272
Red Hat build of OpenJDK 8u292

What you need to check first is whether the flavour and release of your OpenJDK 8 supports TLS 1.3

You can do that by running the following:

public static void main(String[] args) throws NoSuchAlgorithmException, KeyManagementException {
        SSLContext context = SSLContext.getInstance("TLS");
        context.init(null, null, null);
        String[] supportedProtocols = context.getDefaultSSLParameters().getProtocols();
        System.out.println(Arrays.toString(supportedProtocols));
    }

This will print something like [TLSv1.3, TLSv1.2]

If the flavour you have does not return TLSv1.3, then you need to check their releases to see if they backported support for TLSv1.3.
If they did, update to that release, if not you may have to go with another flavour of OpenJDK 8 or better still upgrade to OpenJDK 11 (dependent on the circumstances)

djmonki
  • 3,020
  • 7
  • 18
  • 1
    Thank you! Actually, there was a firewall change that happened recently which was causing this issue. We requested the team to whitelist the URL and now the issue got fixed – Nidheesh Jul 15 '22 at 03:46