CODEWITHSUNDEEP
javasslexceptionjerseyretry-logic
one stevy boi
one stevy boi

Reputation: 576

Can a SSLHandshakeException be a retry-able exception?

I have a service-to-service connection that is intermittently throwing SSLHandshakeExceptions from a jersey client.

public static class MyClientFilter extends ClientFilter{
    @Override
    public ClientResponse handle(ClientRequest cr) throws ClientHandlerException {
        try {
            return getNext().handle(cr);
        } catch (ClientHandlerException e) {
            Throwable rootCause = e.getCause() != null ? e.getCause() : e;
            if (ConnectException.class.isInstance(rootCause) ||
                        SocketException.class.isInstance(rootCause) ||
                        SSLHandshakeException.class.isInstance(rootCause) //maybe?
                ) {
                //do some retry logic
            }
        }
    }
}

The fact that it is only happening intermittently (very rarely) says to me that my certificates and TLS are all configured correctly. In my client I am attempting to retry connections if they fail due to connection or socket exceptions. I am considering making an SSLHandshakeException also a retry-able exception because in my case it seems like it should be, but I am wondering if an SSLHandshakeException could be caused by a connection or socket issue and, if so, is there a way to tell?

Update:

The message of the exception seems to indicate that it could be a connection issue that is not related to SSL configuration:

Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1002)
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 java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:347)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:249)
at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:149)
... 44 common frames omitted

Upvotes: 0

Views: 1048

Answers (1)

Stephen C
Stephen C

Reputation: 718768

Can a SSLHandshakeException be a retry-able exception?

It is not entirely clear what you are asking:

  • Does SSLHandshakeException itself retry? No. Of course not.
  • Are you permitted to retry a connection attempt following a SSLHandshakeException? Yes, you are permitted to retry.
  • Is advisable to retry? It probably will just fail again, but it depends on what is causing the connection to fail.
  • Is advisable to retry repeatedly? Definitely not.

Really what this boils down to is diagnosing the cause of the connection failures. To do this you will need to enable client-side debug logging for the SSL connections.

A common cause for this kind of problem is that the client and server cannot negotiate a mutually acceptable SSL/TLS protocol version or cryptographic suite. This typically happens when one end is using an old SSL / TLS stack that is (by current standards) insecure. If this is the root cause then retrying won't help.

It is also possible ... but extremely unlikely ... that the server or the network "glitched" at just the wrong time.

The message of the exception seems to indicate that it could be a connection issue that is not related to SSL configuration.

Actually, I doubt it. It is standard behavior for a server to simply close the connection if the negotiation has failed; see RFC 8446 Section 4.1 for the details. The client will see that as a broken connection.

Upvotes: 1

Related Questions