Может ли исключение sslhandshakeexception быть исключением с возможностью повторной попытки?

У меня есть соединение между сервисами, которое периодически выбрасывает SSLHandshakeExceptions из клиента jersey.

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
            }
        }
    }
}

Тот факт, что это происходит периодически (очень редко), говорит мне, что мои сертификаты и TLS настроены правильно. В моем клиенте я пытаюсь повторить попытки подключения, если они не работают из-за исключений подключения или сокетов. Я рассматриваю возможность создания исключения SSLHandshakeException также как исключение с возможностью повторной попытки, потому что в моем случае кажется, что так и должно быть, но мне интересно, может ли исключение SSLHandshakeException быть вызвано проблемой соединения или сокета, и, если да, есть ли способ определить ?

Обновлять:

Сообщение об исключении, похоже, указывает на то, что это может быть проблема с подключением, не связанная с конфигурацией SSL:

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
0
0
360
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Can a SSLHandshakeException be a retry-able exception?

Не совсем понятно, о чем вы спрашиваете:

  • SSLHandshakeException повторяет попытку? Нет, конечно нет.
  • Разрешено ли вам повторить попытку подключения после SSLHandshakeException? Да, вам разрешено повторить попытку.
  • Желательно повторить попытку? Вероятно, он снова выйдет из строя, но это зависит от того, что является причиной сбоя соединения.
  • Желательно ли повторить попытку повторно? Точно нет.

На самом деле это сводится к диагностике причины сбоев соединения. Для этого вам необходимо включить ведение журнала отладки на стороне клиента для SSL-соединений.

Распространенной причиной такого рода проблем является то, что клиент и сервер не могут согласовать взаимоприемлемую версию протокола SSL / TLS или криптографический набор. Обычно это происходит, когда на одном конце используется старый стек SSL / TLS, который (по текущим стандартам) небезопасен. Если это основная причина, повторная попытка не поможет.

Также возможно ... но крайне маловероятно ... что сервер или сеть "дали сбой" в самый неподходящий момент.


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

На самом деле, я в этом сомневаюсь. Стандартное поведение сервера - просто закрыть соединение, если согласование не удалось; подробности см. в RFC 8446, раздел 4.1. Клиент увидит в этом разорванное соединение.

Я думаю, что я искал: «Вероятно, он снова выйдет из строя, но это зависит от того, что вызывает сбой соединения». Похоже, что есть причины, по которым соединение может выйти из строя, помимо несовместимых конфигураций SSL / TLS между клиентом и сервером. Так что есть шанс, что это что-то повторное. Я попытаюсь включить отладку журнала, как вы предложили, и посмотрю, смогу ли я уловить, что происходит

one stevy boi 11.08.2018 18:30

Что ж, сценарии мыслимый, где «попробуйте еще раз» могут сработать, включают временную ошибку на сервере и в сети. Вы должны взвесить вероятность потенциально повторяющегося события по сравнению с неотличимыми событиями, которые, как мы уверены, не сработают при повторной попытке.

Stephen C 12.08.2018 02:00

Поскольку я вижу это исключение только для очень и очень небольшого процента вызовов, я предположил, что вероятность того, что ошибка является временной, высока. Но похоже, что это также хорошо осознавать, что любая внезапная проблема TLS между клиентом и сервером приведет к множеству повторных попыток, если я предполагаю, что все исключения SSL можно повторить.

one stevy boi 12.08.2018 18:04

Другие вопросы по теме