Вопросы Теги

openssl secure renegotiation (не поддерживается)

Я запускаю веб-службу, реализованную на сервере Ubuntu 14.04 LTS. Я отлаживаю TLSv1 разрыв соединения через некоторое время между клиентом, использующим openssl версии 0.9.7m , и сервером, использующим openssl 1.0.1f . У меня нет доступа к клиентской стороне, только к серверу и роутеру. Когда я запускаю openssl s_server вместо сервера, я вижу сообщение безопасное повторное согласование не поддерживается при подключении клиента. Повторное согласование не обязательно имеет какое-либо отношение к проблемам с подключением, но я пытаюсь понять повторное согласование. Пока мне не удалось найти ответы на следующие вопросы:

  1. Каковы типичные триггеры для повторного согласования? Это делается небезопасно, если безопасное согласование не поддерживается?
  2. Инициируется ли повторное согласование кодом клиента или сервера или может ли openssl инициировать его в определенный момент?
  3. Есть ли способ принудительного повторного согласования с openssl s_server ] и / или openssl s_client , чтобы поэкспериментировать с ним?
3
задан 23 December 2016 в 13:58
1 ответ

Существует четыре возможных типа повторного согласования :

  • Безопасное повторное согласование, инициированное клиентом
  • Небезопасное повторное согласование, инициированное клиентом
  • Безопасное повторное согласование, инициированное сервером
  • Инициированное сервером небезопасное повторное согласование

С момента обнаружения возможности выполнения атак повторного согласования ( CVE-2009-3555 ), уязвимость существует «во всех текущих версиях TLS» , можно с уверенностью предположить, что повторное согласование не будет выполнено безопасно, если и клиент, и сервер не реализуют расширение индикации повторного согласования TLS .

Первой реакцией OpenSSL было отключить повторное согласование с безопасным повторным согласованием внедряется в более позднем выпуске .

Клиент, использующий 0.9.7m, по определению, предшествует CVE-2009-3555 и одновременно подвержен этой атаке, а также не может выполнять безопасное повторное согласование.

Что касается того, что может вызвать повторное согласование, вы можете отслеживать это по-разному Ent RFC: TLS v1.0 , TLS v1.1 , TLS v1.2 . Различные сообщения в блогах , анализирующие CVE-2009-3555, также содержат подробную информацию о том, когда это происходит.

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

ПОДКЛЮЧЕННЫЕ КОМАНДЫ
Если соединение установлено с сервером SSL, то отображаются любые данные, полученные от сервера, и любые нажатия клавиш будут отправлены на сервер. При интерактивном использовании (что означает, что ни -quiet, ни -ign_eof не заданы), сеанс будет повторно согласован, если строка начинается с R [...]

Это также можно сделать программно ].

3
ответ дан 3 December 2019 в 06:28

Теги

Похожие вопросы