Кратко

  • Изначально TLS проводил второе рукопожатие внутри зашифрованного канала, но криптографически не связывал две процедуры.
  • RFC 5746 заставил новое рукопожатие предъявлять доказательство из предыдущих Finished; TLS 1.3 затем удалил повторное согласование.

Один поток с двумя авторами

Сначала атакующий устанавливает собственное корректное TLS-соединение с сервером и посылает выбранный префикс прикладного протокола. Это может быть начало запроса, смысл которого завершат последующие байты. Затем атакующий пропускает новое TLS-рукопожатие жертвы через уже защищённое соединение с сервером.

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

Схема RFC 5746 разделила непрерывность транспорта, непрерывность шифрования и непрерывность прикладного transcript. Открытый TCP-сокет не доказывает, что байты до и после смены криптографической личности принадлежат одному отправителю.

Память о предыдущем Finished

Исправление хранит для каждого соединения флаг безопасного повторного согласования и значения verify_data, которые клиент и сервер отправили в сообщениях Finished непосредственно предыдущего рукопожатия. Эти значения подтверждают, что оба конца видели именно тот предыдущий обмен.

Расширение renegotiation_info имеет тип 0xff01. В первом рукопожатии поле привязки пусто: стороны объявляют поддержку, не выдумывая предшественника. При повторном согласовании ClientHello содержит сохранённое значение клиента, а ServerHello — соединённые значения клиента и сервера. Отсутствие расширения или несовпадение требует прервать рукопожатие.

Атакующий способен переслать рукопожатие жертвы, но не способен вложить в него правильное доказательство своей предыдущей серверной связи. Новому обмену доверяют не потому, что он прошёл под старым шифрованием, а потому, что он аутентифицированно называет свою предысторию.

Цена совместимости

Некоторые старые реализации завершали соединение при неизвестном расширении ClientHello, хотя должны были его игнорировать. Поэтому RFC 5746 ввёл также TLS_EMPTY_RENEGOTIATION_INFO_SCSV. Значение расположено среди наборов шифров, но не описывает алгоритмы и не может быть выбрано; оно лишь передаёт тот же сигнал, что пустое начальное расширение.

Переход сохранил неопределённость. Сервер без подтверждения мог разрешать опасное повторное согласование либо полностью запрещать его и потому не быть уязвимым. Клиент не мог отличить эти варианты средствами TLS. Разрыв давал строгую гарантию, продолжение сохраняло совместимость. Отсутствие доказательства стало явным операционным выбором.

TLS 1.3 устраняет переход

RFC 8446 запрещает повторное согласование в TLS 1.3: ClientHello в неподходящий момент требует завершения соединения. Обновление ключей и аутентификация после рукопожатия существуют отдельно и не возвращают универсальную старую процедуру.

RFC 9325 требует от клиентов и серверов TLS 1.2 реализации renegotiation_info, а от клиента — разрыва при отсутствии подтверждения. Источники не подсчитывают жертв 2009 года или нынешние развёртывания. Они точно фиксируют дефект, исправленную привязку и последующее удаление. Урок таков: смена ключей или личности обязана доказать наследуемое состояние. Сам зашифрованный канал этого не доказывает.

Источники