Успешное рукопожатие, несмотря на плохой сертификат в Netty 4.1.36 и JDK 11 - PullRequest
Новая
       26

Успешное рукопожатие, несмотря на плохой сертификат в Netty 4.1.36 и JDK 11

1 голос
/ 05 мая 2019

У меня есть клиент и сервер, настроенный для использования TLS и самозаверяющего сертификата.

Клиентский SSL Engine настроен на использование фиктивного диспетчера доверия, который никогда не генерирует CertificateException и пустой массив KeyManager.

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

Когда я запускаю его с JDK 8, я получаю следующий результат рукопожатия:

  • Сбой серверадля проверки сертификата
  • В потоке клиента я вижу, что io.netty.handler.ssl.SslHandler#setHandshakeFailure вызывается и io.netty.handler.ssl.SslHandler#setHandshakeSuccess никогда не вызывается.

Что является ожидаемым поведением.

КогдаЯ запускаю его с JDK 11 и получаю следующее:

  • сервер не работает с той же ошибкой (пустая цепочка сертификатов), но в клиентском потоке я вижу следующее:
  • io.netty.handler.ssl.SslHandler#setHandshakeSuccess isсначала называется
  • io.netty.handler.ssl.SslHandler#setHandshakeFailure вызывается после

Я новичок в TLS 1.3 и, возможно, что-то пропустил в конфигурации.В то же время в документации говорится, что обновлять клиенты API Java TLS для переключения на TLS 1.3 не нужно.

Такое поведение сбивает с толку и нарушает дальнейшую логику, основанную на handshakePromise.

Полный код для воспроизведения проблемы доступен по ссылке: https://gist.github.com/kiturutin/ccb710f67ccfb0a7a7de1fb3b3099b60

Это отличный сценарий, который сначала запускает сервер, а затем клиента.

1 Ответ

3 голосов
/ 05 мая 2019

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

Если это так, то похоже, что подобная проблема имеет причину (?) - см. Пятый пост в https://github.com/eclipse/jetty.project/issues/2711 - и мне кажется, это потому, что клиент TLS 1.3 считает, что рукопожатие завершено при отправке «Завершено» (потому что сервер 1.3 переводит сервер «Завершено в первый полет»), и это до получения оповещения сервера о сбое аутентификации клиента.(Принимая во внимание, что в 1.2 и ранее сервер Finished и, возможно, Ticket в основном является вторым полетом, вызывая дополнительный RTT для протоколов клиентских приложений - например, HTTP.)

Это также допринимающий сервер NewSessionTicket (измененный для 1.3 «возобновление»), если используется;см. Проблема OpenJDK 11 - клиент завершил рукопожатие перед последней UNWRAP .

Я думаю, для 1.3 вы должны принять «сбой» после «успеха», если только люди Java не могут думать о некоторых действительно умныхисправить это.

...