Назад | Перейти на главную страницу

Почему сервер FIN завершается после запуска сеанса TLS?

Сервер TLS делает что-то, чего я не понимаю.

  1. Рукопожатие TCP выполняется нормально.
  2. SSL-клиент Hello работает нормально.
  3. SSL-сервер Hello кажется нормальным. Предоставляет сертификат, сообщает сервер Hello Done.
  4. Анализ показывает проблемы клиента: «Обмен ключами клиента, изменение спецификации шифра, зашифрованное сообщение установления связи»
  5. Анализ показывает проблемы с сервером: «Изменить спецификацию шифра», затем «Зашифрованное сообщение установления связи».

Теперь клиент принимает ACK, начинает отправлять данные. Но серверные ACK затем отправляют «зашифрованное предупреждение» и FIN.

Это произошло сразу после замены сертификатов. Сертификат, представленный в подтверждении SSL, является новым ключом.

Кому-нибудь?

Вероятно, это связано с проблемой SNI с клиентом или каким-либо устройством посередине, например с балансировщиком нагрузки. Устройство балансировки нагрузки должно иметь возможность передавать имя сервера внутреннему хосту как часть начального приветствия клиента. видеть https://en.m.wikipedia.org/wiki/Server_Name_Indication

Самый важный пакет - это «Зашифрованное предупреждение», поскольку он содержит причину закрытия соединения.

Похоже, это ошибка проверки. Это означает, что сертификат не является доверенным или недействительным. Но настоящая причина - отправлено через Протокол предупреждений TLS

Я столкнулся с аналогичной проблемой с pure-ftpd в явном режиме TLS (сервер FTPS).

Однако в моем случае было нет Encrypted Alert отправлено с сервера; он просто Fin'd сразу после обмена ключами (Change Cipher Spec, Finished сообщение с сервера → FIN с сервера). Следующий, клиент отправил Encrypted alert, код уровня 1 0 Close Notify (что ожидаемо - в отличие от сервера FIN).

Это произошло только с одним конкретным клиентом (прошивкой устройства) и не воспроизводилось с другими клиентами ftps.

Я не раскопал корень проблемы, но подозреваю, что мы столкнулись с ошибка сервера. pure-ftpd использует подобную Apache модель fork-per-connection; и я заметил сбой дочернего процесса в gdb (выход с кодом -1) - что, конечно же, приводит к тому, что ОС закрывает сокет FD и отправляет FIN.

Еще одна причина сказать, что это ошибка сервера в моем случае - поведение перестало воспроизводиться, как только мы заменили ftps-сервер на другую реализацию, proftpd.

Я не думаю, что это соответствует случаю OP - там сервер завершает соединение подходящим для TLS способом, с зашифрованным предупреждением - но, тем не менее, это нужно учитывать для всех, кто попадает на эту страницу.