Ssl handshake timed out ошибка

System Architecture

We as client can communicate to different devices (servers) with different ip addresses.
All the servers share a common root certificate to expose it as TLS, but unique key/ keystore per device.

Expected Behavior

No Handshake time out should occur.

When making a call to few devices concurrently (let say less than some threshold 4) error will not occur, but if we invoke calls concurrently more than this threshold , getting to see handshake timeout issues.

Debugged with option -Djavax.net.debug=ssl , still no luck on figuring out why the issue is happening.

There is no problem with the server, when we try like one on one with a server, we never encountered handshake timeout issue, but when tried on multiple servers concurrently few error out and few get success in handshake.

I think there is some concurrency issues going on in reactor netty, unable to figure out where.
Please share architecture diagram if there is any for reactory netty .

Any pointers would be helpful to resolve this issue.

Actual Behavior

Getting Below error:

2019-11-20 13:07:22,108 361283 [reactor-http-epoll-8] WARN  r.n.http.client.HttpClientConnect - [id: 0xab3f418a, L:/<ip1>:40554 - R:<ip2>/<ip2>:5000] The connection observed an
 error
javax.net.ssl.SSLException: handshake timed out
        at io.netty.handler.ssl.SslHandler$5.run(SslHandler.java:2011)
        at io.netty.util.concurrent.PromiseTask.runTask(PromiseTask.java:98)
        at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:150)
        at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:510)
        at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)
        at io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1050)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.lang.Thread.run(Thread.java:748)
reactor-http-epoll-8, called closeOutbound()
reactor-http-epoll-8, closeOutboundInternal()
reactor-http-epoll-8, SEND TLSv1.2 ALERT:  warning, description = close_notify
reactor-http-epoll-8, WRITE: TLSv1.2 Alert, length = 26
reactor-http-epoll-8, called closeInbound()
reactor-http-epoll-8, fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack?
javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
%% Invalidated:  [Session-1010, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
reactor-http-epoll-8, SEND TLSv1.2 ALERT:  fatal, description = internal_error
reactor-http-epoll-8, Exception sending alert: java.io.IOException: writer side was already closed.
2019-11-20 13:07:22,110 361285 [org.springframework.kafka.KafkaListenerEndpointContainer#1-1-C-1] ERROR com.bmg.service.HttpService - javax.net.ssl.SSLException: handshake timed out, {}
reactor.core.Exceptions$ReactiveException: javax.net.ssl.SSLException: handshake timed out
        at reactor.core.Exceptions.propagate(Exceptions.java:326)
        at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:91)
        at reactor.core.publisher.Mono.block(Mono.java:1494)

client make a call to server
gets HandshakeTimeout after around 1.15 min to 1.40 min

Since default HandshakeTimeout is 10 secs, also tried setting below system variable property , but still handshake timeout occurs.
-Dreactor.netty.tcp.sshHandshakeTimeout=120000
HandshakeTimeout didn’t occur after 2 minutes are per above config, it occurred around same range 1.15 min to 1.40 min,

Even though error says handshakeTimeout, it feels like this call is being internally queued and tried after certain time and then handshakeTimeout occurs.

Steps to Reproduce

JdkSsl context being used by reactor netty.
Getting HttpClient as below:
Note: getting a newConnection (instead of HttpClient.create() ) else there is weird concurrency problem going on, instead of hitting one server it’s hitting different server and also used to get reactor.netty.http.client.PrematureCloseException (Reference: https://projectreactor.io/docs/netty/release/reference/index.html#_connect) hence using newConnection.

public HttpClient getHttpClient(SslContext sslContext, int connectTimeOutInMilliSeconds,
    int readTimeOutInMilliSeconds) {

  HttpClient httpClient = HttpClient.newConnection().tcpConfiguration(tcpClient ->
      tcpClient
          .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, connectTimeOutInMilliSeconds)
          .doOnConnected(connection -> connection
              .addHandlerLast(new ReadTimeoutHandler(readTimeOutInMilliSeconds,
                  TimeUnit.MILLISECONDS))
              .addHandlerLast((new WriteTimeoutHandler(readTimeOutInMilliSeconds,
                  TimeUnit.MILLISECONDS)))));
  if (sslContext != null) {
    httpClient = httpClient.secure(sslContextSpec -> sslContextSpec.sslContext(sslContext));
  }
  return httpClient;
}

Getting sslContext as below:

  private SslContext getTrustAllSslWebClient() {
    try {
      return SslContextBuilder
          .forClient()
          .trustManager(InsecureTrustManagerFactory.INSTANCE)
          .build();
    } catch (SSLException e) {
//ignore
    }
  }

Minimal yet complete reproducer code (or URL to code)

This is difficult to reproduce without complete production setup.

Possible Solution

Your Environment

• Reactor version(s) used:
  reactor-netty :0.8.13:RELEASE

• Other relevant libraries versions (eg. netty, …):
  netty -> 4.1.43.FINAL
  derived based on spring boot parent version given below

 <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.1.10.RELEASE</version>
    <relativePath/> <!-- lookup parent from repository -->
  </parent>

JVM version (e.g. java -version)

openjdk version «1.8.0_222»
Also tried on java11.

OS version (e.g. uname -a)

4.15.0-66-generic #75-Ubuntu

Зачастую после установки SSL-сертификатов многие пользователи сталкиваются с ошибками, которые препятствуют корректной работе защищенного протокола HTTPS.

Предлагаем разобраться со способами устранения подобных ошибок.

SSL (Secure Socket Layer) — это интернет-протокол для создания зашифрованного соединения между пользователем и сервером, который гарантирует безопасную передачу данных.

Когда пользователь заходит на сайт, браузер запрашивает у сервера информацию о наличии сертификата. Если сертификат установлен, сервер отвечает положительно и отправляет копию SSL-сертификата браузеру. Затем браузер проверяет сертификат, название которого должно совпадать с именем сайта, срок действия сертификата и наличие корневого сертификата, выданного центром сертификации.

Причины возникновения ошибок SSL-соединения

Когда сертификат работает корректно, адресная строка браузера выглядит примерно так:

Но при наличии ошибок она выглядит несколько иначе:

Существует множество причин возникновения таких ошибок. К числу основных можно отнести:

• Некорректную дату и время на устройстве (компьютер, смартфон, планшет и т.д.);
• Ненадежный SSL-сертификат;
• Брандмауэр или антивирус, блокирующие сайт;
• Включенный экспериментальный интернет-протокол QUIC;
• Отсутствие обновлений операционной системы;
• Использование SSL-сертификата устаревшей версии 3.0;
• Появление ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера.

Давайте рассмотрим каждую из них подробнее.

Проблемы с датой и временем

Если на устройстве установлены некорректные дата и время, ошибка SSL-соединения неизбежна, ведь при проверке сертификата происходит проверка срока его действия. Современные браузеры умеют определять такую ошибку самостоятельно и выводят сообщение о неправильно установленной дате или времени.

Для исправления этой ошибки достаточно установить на устройстве актуальное время. После этого необходимо перезагрузить страницу или браузер.

Ненадежный SSL-сертификат

Иногда при переходе на сайт, защищенный протоколом HTTPS, появляется ошибка «SSL-сертификат сайта не заслуживает доверия».

Одной из причин появления такой ошибки, как и в предыдущем случае, может стать неправильное время. Однако есть и вторая причина — браузеру не удается проверить цепочку доверия сертификата, потому что не хватает корневого сертификата. Для избавления от такой ошибки необходимо скачать специальный пакет GeoTrust Primary Certification Authority, содержащий корневые сертификаты. После скачивания переходим к установке. Для этого:

• Нажимаем сочетание клавиш Win+R и вводим команду certmgr.msc, жмем «Ок». В Windows откроется центр сертификатов.
• Раскрываем список «Доверенные корневые центры сертификации» слева, выбираем папку «Сертификаты», кликаем по ней правой кнопкой мышки и выбираем «Все задачи — импорт».

• Запустится мастер импорта сертификатов. Жмем «Далее».

• Нажимаем кнопку «Обзор» и указываем загруженный ранее сертификат. Нажимаем «Далее»:

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

После вышеперечисленных действий можно перезагрузить устройство и проверить отображение сайта в браузере.

Брандмауэр или антивирус, блокирующие сайт

Некоторые сайты блокируются брандмауэром Windows. Для проверки можно отключить брандмауэр и попробовать зайти на нужный сайт. Если SSL-сертификат начал работать корректно, значит дело в брандмауэре. В браузере Internet Explorer вы можете внести некорректно работающий сайт в список надежных и проблема исчезнет. Однако таким образом вы снизите безопасность своего устройства, так как содержимое сайта может быть небезопасным, а контроль сайта теперь отключен.

Также SSL может блокировать антивирусная программа. Попробуйте отключить в антивирусе проверку протоколов SSL и HTTPS и зайти на сайт. При необходимости добавьте сайт в список исключений антивируса.

Включенный экспериментальный протокол QUIC

QUIC — это новый экспериментальный протокол, который нужен для быстрого подключения к интернету. Основная задача протокола QUIC состоит в поддержке нескольких соединений. Вы можете отключить этот протокол в конфигурации вашего браузера.

Показываем как отключить QUIC на примере браузера Google Chrome:

• Откройте браузер и введите команду chrome://flags/#enable-quic;
• В появившемся окне будет выделен параметр: Experimental QUIC protocol (Экспериментальный протокол QUIC). Под названием этого параметра вы увидите выпадающее меню, в котором нужно выбрать опцию: Disable.

• После этого просто перезапустите браузер.

Этот способ работает и в Windows и в Mac OS.

Отсутствие обновлений операционной системы

Проблемы с SSL-сертификатами могут возникать и из-за того, что на вашей операционной системе давно не устанавливались обновлений. Особенно это касается устаревших версий Windows (7, Vista, XP и более ранние). Установите последние обновления и проверьте работу SSL.

Использование SSL-сертификата версии 3.0

Некоторые сайты используют устаревший SSL-протокол версии 3.0, который не поддерживают браузеры. По крайней мере, по умолчанию. Чтобы браузер поддерживал устаревший SSL необходимо сделать следующее (на примере браузера Google Chrome):

• Откройте браузер и перейдите в раздел «Настройки».
• Прокрутите страницу настроек вниз и нажмите «Дополнительные».
• В разделе «Система» найдите параметр «Настройки прокси-сервера» и кликните на него.

• Откроется окно. Перейдите на вкладку «Дополнительно».
• В этой вкладке вы увидите чекбокс «SSL 3.0».

• Поставьте галочку в чекбоксе, нажмите кнопку «Ок» и перезагрузите браузер.

Ошибки «Invalid CSR» при генерации сертификата из панели управления облачного провайдера

В процессе активации сертификата можно столкнуться с ошибкой «Invalid CSR». Такая ошибка возникает по следующим причинам:

• Неправильное имя FQDN (полное имя домена) в качестве Common Name (в некоторых панелях управления это поле может также называться Host Name или Domain Name). В этом поле должно быть указано полное доменное имя вида domain.com или subdomain.domain.com (для субдоменов). Имя домена указывается без https://. В качестве данного значения нельзя использовать интранет-имена (text.local). В запросе для wildcard-сертификатов доменное имя необходимо указывать как *.domain.com.
• В CSR или пароле есть не латинские буквы и цифры. В CSR поддерживаются только латинские буквы и цифры – спецсимволы использовать запрещено. Это правило распространяется и на пароли для пары CSR/RSA: они не должны содержать спецсимволов.
• Неверно указан код страны. Код страны должен быть двухбуквенным ISO 3166-1 кодом (к примеру, RU, US и т.д.). Он указывается в виде двух заглавных букв.
• В управляющей строке не хватает символов. CSR-запрос должен начинаться с управляющей строки ——BEGIN CERTIFICATE REQUEST—— и заканчиваться управляющей строкой ——END CERTIFICATE REQUEST——. С каждой стороны этих строк должно быть по 5 дефисов.
• В конце или начале строки CSR есть пробелы. Пробелы на концах строк в CSR не допускаются.
• Длина ключа меньше 2048 бит. Длина ключа должна быть не менее 2048 бит.
• В CRS-коде для сертификата для одного доменного имени есть SAN-имя. В CSR-коде для сертификата, предназначенного защитить одно доменное имя, не должно быть SAN (Subject Alternative Names). SAN-имена указываются для мультидоменных (UCC) сертификатов.
• При перевыпуске или продлении сертификата изменилось поле Common Name. Это поле не должно меняться.

System Architecture

We as client can communicate to different devices (servers) with different ip addresses.
All the servers share a common root certificate to expose it as TLS, but unique key/ keystore per device.

Expected Behavior

No Handshake time out should occur.

When making a call to few devices concurrently (let say less than some threshold 4) error will not occur, but if we invoke calls concurrently more than this threshold , getting to see handshake timeout issues.

Debugged with option -Djavax.net.debug=ssl , still no luck on figuring out why the issue is happening.

There is no problem with the server, when we try like one on one with a server, we never encountered handshake timeout issue, but when tried on multiple servers concurrently few error out and few get success in handshake.

I think there is some concurrency issues going on in reactor netty, unable to figure out where.
Please share architecture diagram if there is any for reactory netty .

Any pointers would be helpful to resolve this issue.

Actual Behavior

Getting Below error:

2019-11-20 13:07:22,108 361283 [reactor-http-epoll-8] WARN  r.n.http.client.HttpClientConnect - [id: 0xab3f418a, L:/<ip1>:40554 - R:<ip2>/<ip2>:5000] The connection observed an
 error
javax.net.ssl.SSLException: handshake timed out
        at io.netty.handler.ssl.SslHandler$5.run(SslHandler.java:2011)
        at io.netty.util.concurrent.PromiseTask.runTask(PromiseTask.java:98)
        at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:150)
        at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:510)
        at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)
        at io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1050)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
        at java.lang.Thread.run(Thread.java:748)
reactor-http-epoll-8, called closeOutbound()
reactor-http-epoll-8, closeOutboundInternal()
reactor-http-epoll-8, SEND TLSv1.2 ALERT:  warning, description = close_notify
reactor-http-epoll-8, WRITE: TLSv1.2 Alert, length = 26
reactor-http-epoll-8, called closeInbound()
reactor-http-epoll-8, fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack?
javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
%% Invalidated:  [Session-1010, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
reactor-http-epoll-8, SEND TLSv1.2 ALERT:  fatal, description = internal_error
reactor-http-epoll-8, Exception sending alert: java.io.IOException: writer side was already closed.
2019-11-20 13:07:22,110 361285 [org.springframework.kafka.KafkaListenerEndpointContainer#1-1-C-1] ERROR com.bmg.service.HttpService - javax.net.ssl.SSLException: handshake timed out, {}
reactor.core.Exceptions$ReactiveException: javax.net.ssl.SSLException: handshake timed out
        at reactor.core.Exceptions.propagate(Exceptions.java:326)
        at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:91)
        at reactor.core.publisher.Mono.block(Mono.java:1494)

client make a call to server
gets HandshakeTimeout after around 1.15 min to 1.40 min

Since default HandshakeTimeout is 10 secs, also tried setting below system variable property , but still handshake timeout occurs.
-Dreactor.netty.tcp.sshHandshakeTimeout=120000
HandshakeTimeout didn’t occur after 2 minutes are per above config, it occurred around same range 1.15 min to 1.40 min,

Even though error says handshakeTimeout, it feels like this call is being internally queued and tried after certain time and then handshakeTimeout occurs.

Steps to Reproduce

JdkSsl context being used by reactor netty.
Getting HttpClient as below:
Note: getting a newConnection (instead of HttpClient.create() ) else there is weird concurrency problem going on, instead of hitting one server it’s hitting different server and also used to get reactor.netty.http.client.PrematureCloseException (Reference: https://projectreactor.io/docs/netty/release/reference/index.html#_connect) hence using newConnection.

public HttpClient getHttpClient(SslContext sslContext, int connectTimeOutInMilliSeconds,
    int readTimeOutInMilliSeconds) {

  HttpClient httpClient = HttpClient.newConnection().tcpConfiguration(tcpClient ->
      tcpClient
          .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, connectTimeOutInMilliSeconds)
          .doOnConnected(connection -> connection
              .addHandlerLast(new ReadTimeoutHandler(readTimeOutInMilliSeconds,
                  TimeUnit.MILLISECONDS))
              .addHandlerLast((new WriteTimeoutHandler(readTimeOutInMilliSeconds,
                  TimeUnit.MILLISECONDS)))));
  if (sslContext != null) {
    httpClient = httpClient.secure(sslContextSpec -> sslContextSpec.sslContext(sslContext));
  }
  return httpClient;
}

Getting sslContext as below:

  private SslContext getTrustAllSslWebClient() {
    try {
      return SslContextBuilder
          .forClient()
          .trustManager(InsecureTrustManagerFactory.INSTANCE)
          .build();
    } catch (SSLException e) {
//ignore
    }
  }

Minimal yet complete reproducer code (or URL to code)

This is difficult to reproduce without complete production setup.

Possible Solution

Your Environment

• Reactor version(s) used:
  reactor-netty :0.8.13:RELEASE

• Other relevant libraries versions (eg. netty, …):
  netty -> 4.1.43.FINAL
  derived based on spring boot parent version given below

 <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.1.10.RELEASE</version>
    <relativePath/> <!-- lookup parent from repository -->
  </parent>

JVM version (e.g. java -version)

openjdk version «1.8.0_222»
Also tried on java11.

OS version (e.g. uname -a)

4.15.0-66-generic #75-Ubuntu

Add the following piece of code

public Retrofit getRetrofit(Gson gson) {
            return new Retrofit.Builder()
                    .baseUrl(ZoneApplication.getContext().getString(R.string.feed_data_base_url))
                    .client(HttpClientService.getUnsafeOkHttpClient())
                    .addCallAdapterFactory(RxJavaCallAdapterFactory.create())
                    .addConverterFactory(new NullOnEmptyConverterFactory())
                    .addConverterFactory(GsonConverterFactory.create(gson))
                    .build();

        }

or change your code to

public static Retrofit getClient() {

        OkHttpClient okHttpClient = new OkHttpClient.Builder()
                .readTimeout(60, TimeUnit.SECONDS)
                .writeTimeout(60, TimeUnit.SECONDS)
                .connectTimeout(60, TimeUnit.SECONDS)
                .build();

        if (retrofit == null) {
            retrofit = new Retrofit.Builder()
                    .client(HttpClientService.getUnsafeOkHttpClient())
                    .baseUrl(BASE_URL)
                    .addConverterFactory(GsonConverterFactory.create())
                    .build();
        }
        return retrofit;
    }

Create another class called HttpClientService and add the following code

public class HttpClientService {
    public static OkHttpClient getUnsafeOkHttpClient() {

        try {
            final TrustManager[] trustAllCerts = new TrustManager[]{
                    new X509TrustManager() {
                        @SuppressLint("TrustAllX509TrustManager")
                        @Override
                        public void checkClientTrusted(
                                java.security.cert.X509Certificate[] chain,
                                String authType) {
                            //Do nothing
                        }

                        @SuppressLint("TrustAllX509TrustManager")
                        @Override
                        public void checkServerTrusted(
                                java.security.cert.X509Certificate[] chain,
                                String authType) {
                            //Do nothing
                        }

                        @Override
                        public java.security.cert.X509Certificate[] getAcceptedIssuers() {
                            return new java.security.cert.X509Certificate[0];
                        }
                    }};
            final SSLContext sslContext = SSLContext.getInstance("TLS");
            sslContext.init(null, trustAllCerts,
                    new java.security.SecureRandom());

            final SSLSocketFactory sslSocketFactory = sslContext
                    .getSocketFactory();

            OkHttpClient okHttpClient = new OkHttpClient.Builder()
                    .sslSocketFactory(sslSocketFactory)
                    .hostnameVerifier(org.apache.http.conn.ssl.SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER)
                    .build();
            return okHttpClient;
        } catch (Exception e) {
            throw new RuntimeException(e);
        }

    }
}

Здравствуйте, есть сервер Ubuntu 20 на котором присутствуют nginx и php 7.4
Сразу после их установки и настройки, простой тестовый сайт и на html и php запустился без проблем
Но при тесте одиночного php скрипта как из консоли, так и напрямую из браузера всё время появляется ошибка SSL: Handshake timed out и затем Failed to enable crypto
Данные ошибки возникали при использовании базовых функций file(); и file_get_contents();
При использовании curl такой проблемы не было
С чем связанна данная проблема и как её решить?

• 
  Вопрос задан

  более года назад

• 421 просмотр

1. Forum
3. Public
5. Help and Support
7. Can’t connect: SSL handshake timed out

1. Forum
3. Public
5. Help and Support
7. Can’t connect: SSL handshake timed out

Time to create page: 0.167 seconds