Can a SSLHandshakeException be a retry-able exception?

Question

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

score 1 · Accepted Answer · edited Oct 07 '21 at 11:06

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.

I think what I was looking for was "It probably will just fail again, but it depends on what is causing the connection to fail." It sounds like there are reasons that the connection could fail beyond incompatible SSL/TLS configurations between client and server. So there is a chance it is something retryable. I will attempt to enable to debug logging as you suggested and see if I can catch what is happening — one stevy boi, Aug 11 '18 at 16:30
Well, the *conceivable* scenarios where "try again" might work involve a transient error in the server and network. You have to weigh the probability of the potentially retryable event versus the non-distinguishable events that we are sure won't work with a retry. — Stephen C, Aug 12 '18 at 00:00
Because I am only seeing this exception thrown for a very, very small percentage of calls, I have assumed that the probability of the error being transient is high. But it sounds like it is also good to recognize that any sudden TLS issue between the client and server would result in many, many retries if I assume that all SSL exceptions are retryable — one stevy boi, Aug 12 '18 at 16:04

Can a SSLHandshakeException be a retry-able exception?

1 Answers1