Кратко

  • В ранней модели TLS новый handshake мог продолжаться на уже существующем соединении без криптографической связи с предыдущим handshake. RFC 5746 исправил эту границу, добавив передачу данных Finished и механизм первоначального сигнала поддержки защищённой renegotiation: RFC 5246, RFC 5746.
  • Это была ограниченная инъекция префикса в поток приложения, а не доказательство произвольной расшифровки или переписывания всей последующей сессии. TLS 1.3 убрал renegotiation, но сам по себе этот факт не показывает, что все старые пути уже обновлены: RFC 7457, RFC 8446, RFC 9325.

Проблема возникла из-за того, что TLS 1.2 разрешал новый handshake внутри уже установленного соединения, однако не требовал криптографически связать его с предыдущим. В результате транспортное соединение могло сохранять контекст приложения, пока удостоверение и параметры безопасности менялись. Это создавало разрыв между тем, что видел сервер на уровне соединения, и тем, как приложение интерпретировало начало своего протокольного потока. Базовое описание TLS 1.2 находится в RFC 5246.

Сценарий атаки, описанный IETF, был последовательным. Сначала атакующий устанавливал TLS-соединение с сервером. Затем он помещал в начало потока выбранные им байты прикладного протокола. После этого handshake жертвы передавался серверу как renegotiation внутри уже существующего соединения. Сервер мог аутентифицировать жертву в новом handshake, одновременно сохраняя предшествующие байты атакующего в том же потоке. Именно отсутствие связи между двумя handshake делало возможной эту подмену границы; механизм и последствия описаны в RFC 5746 и RFC 7457.

Практический эффект зависел от прикладного протокола. RFC 7457 описывает его как bounded prefix injection: сервер или приложение могли принять начало потока, сформированное атакующим, прежде чем продолжить обработку данных после аутентификации жертвы. Это не является доказательством того, что атакующий расшифровывал защищённый трафик жертвы или произвольно менял все последующие байты. Последствия определялись тем, как конкретное приложение связывало префикс с полномочиями, запросом или состоянием сессии: RFC 7457.

RFC 5746 ввёл два разных элемента защиты. Расширение renegotiation_info переносит verify_data предыдущего handshake, чтобы новый handshake был криптографически связан с завершившимся. Для первоначального handshake предусмотрен TLS_EMPTY_RENEGOTIATION_INFO_SCSV — сигнал того, что клиент поддерживает защищённую renegotiation. Сигнал показывает поддержку механизма, но не заменяет binding через данные Finished. Это различие важно: наличие сигнала и доказательство связи между двумя handshake — разные утверждения, RFC 5746.

Ремонт изменил допустимую границу поведения для обновлённых реализаций. Но он не превратил публикацию RFC в перепись всех работающих конфигураций. Операционные рекомендации сохраняли необходимость безопасно обращаться с более старыми версиями TLS и определять, допускает ли конкретная точка legacy renegotiation, ограничивает её или отклоняет. Эта преемственность видна в RFC 7525 и в более позднем RFC 9325.

TLS 1.3 выбрал иной путь: он исключил renegotiation как общую возможность протокола. Оставшиеся post-handshake функции, включая KeyUpdate и post-handshake authentication, имеют более узкое назначение и не возвращают прежнюю модель смены handshake внутри одного контекста. Это архитектурное удаление уменьшает пространство ошибки, но не доказывает, что клиент, сервер, балансировщик, внутренний переход и приложение в каждом конкретном сервисе используют TLS 1.3 end-to-end, RFC 8446, RFC 9325.

Отсюда следует практическая граница ответственности. IETF определяет wire-level binding, сигнализацию и переходное поведение; доказательством для этой части служит опубликованный текст RFC. Разработчики библиотек и продуктов должны реализовать проверки и безопасные настройки. Операторы должны инвентаризировать компоненты, тестировать внешние endpoint-ы и внутренние hops, определить владельцев исключений и подтвердить их закрытие. Владельцы приложений должны отдельно проверить, может ли управляемый атакующим префикс менять смысл запроса или права доступа.

Открытый вопрос не в том, был ли опубликован правильный стандарт. Источники подтверждают механизм уязвимости, ремонт и удаление renegotiation в TLS 1.3. Они не подтверждают универсальное внедрение RFC 5746, полное прекращение опасного legacy-поведения, состояние какой-либо конкретной компании или работу всех middlebox-ов. Для закрытия риска нужны инвентарь, тесты поведения, список исключений с владельцами и сроками, а также свидетельства того, что старые пути не возвращаются после изменений платформы.