Кратко

  • Завершение QUIC-handshake является локальным и зависит от точки зрения конкретного endpoint; одновременно у обоих сторон оно не обязано происходить.
  • HANDSHAKE_DONE, либо подходящий ACK с ключами 1-RTT на клиенте, подтверждает состояние протокола и требует удаления Handshake-ключей.
  • Перед объявлением готовности подтверждение нужно связать с решением по 0-RTT и с результатом работы приложения.

Проблема часто начинается с зелёного индикатора. Приходит HANDSHAKE_DONE, панель объявляет сервис готовым, и узкий транспортный сигнал превращается в утверждение о бизнес-результате. Но сервер мог отклонить ранние данные. В таком случае клиент обязан сбросить все связанные потоки и состояние приложения, привязанное к ним. Сигнал не является ошибочным; ошибочной может быть только слишком широкая трактовка.

RFC 9001 определяет завершение с локальной точки зрения. Локальный TLS-стек должен отправить сообщение Finished и проверить сообщение Finished от другой стороны. Это не обязательно происходит одновременно на обоих endpoint. Поэтому журнал должен сохранять, кто наблюдал переход и на основании какого свидетельства, а не изображать одну общую синхронную отметку времени.

Правила подтверждения зависят от роли. На сервере handshake подтверждён, когда он завершается, и сервер должен сразу отправить HANDSHAKE_DONE. На клиенте подтверждением служит получение HANDSHAKE_DONE. Клиент также может вывести подтверждение из ACK, покрывающего пакет, отправленный с ключами 1-RTT. Отправлять HANDSHAKE_DONE может только сервер. Этот frame сообщает клиенту, что сервер получил и обработал его Handshake-пакет; ответом приложения он не является.

Главное следствие относится к жизненному циклу ключей. После подтверждения endpoint обязан удалить Handshake-ключи, и криптографическая эпоха Handshake завершается. Это не означает, что переговоры прикладного протокола закончились, запрос достиг кода приложения, backend здоров или бизнес-операция надёжно сохранена.

Initial-ключи удаляются по другому правилу. Клиент удаляет их при первой отправке Handshake-пакета. Сервер удаляет их после первой успешной обработки Handshake-пакета. Эти события основаны на другом свидетельстве и не должны объединяться ни с подтверждением handshake, ни с удалением Handshake-ключей. Сводная отметка в единственном поле скрывает важные границы состояния.

Решение по 0-RTT также принимается отдельно. Сервер принимает 0-RTT, включая расширение early_data в EncryptedExtensions, и отклоняет его, если расширение отсутствует. При отклонении сервер не должен обрабатывать 0-RTT-пакеты, а клиент должен сбросить все потоки, включая связанное с ними состояние приложения. Последующее HANDSHAKE_DONE не превращает отклонённые данные в принятые.

Ответственность за безопасность от повторного воспроизведения лежит на прикладном протоколе. Данные приложения в 0-RTT могут быть обработаны несколько раз из-за replay. Клиент не должен использовать 0-RTT для прикладных данных, если приложение специально этого не запросило; сам протокол должен определить допустимое применение. Подтверждённый handshake поэтому не доказывает безопасность от replay, выполнение ровно один раз, долговременный commit или принятие раннего запроса.

Даже альтернативный ACK 1-RTT сохраняет транспортную область действия. Если он покрывает наименьший номер пакета 1-RTT, отправленного клиентом, он выполняет условие подтверждения из RFC 9001. Он не доказывает, что приложение потребило данные, записало их надёжно, выполнило авторизацию или завершило бизнес-операцию. Это свидетельство криптографического состояния, а не квитанция о бизнес-результате.