Кратко

  • Действительная метка показывает, что отправитель наблюдал Initial клиента и что проверяемые байты Retry не были случайно повреждены.
  • Она не аутентифицирует названный сервер, не доказывает принятие токена и не означает, что сервер уже проверил адрес клиента.
  • Проверку метки, возврат токена, решение сервера и аутентифицированный результат TLS следует хранить как отдельные события.

В трассировке виден QUIC Retry с действительной меткой целостности. Панель называет его «аутентифицированным запросом сервера» и отмечает адрес клиента как проверенный. Пакет не даёт оснований ни для одного из этих выводов.

RFC 9001 §5.8 устанавливает узкую гарантию. 128-битная метка вычисляется с AEAD_AES_128_GCM, пустым открытым текстом и псевдопакетом Retry в качестве связанных данных. Псевдопакет состоит из переданного Retry без метки, перед которым помещены длина и значение Original Destination Connection ID — ODCID. Для QUIC v1 ключ и nonce приведены в стандарте. Поскольку ODCID взят из Initial клиента, действительная метка подтверждает, что отправитель видел этот Initial, и позволяет отсечь случайное повреждение.

Это не аутентификация узла. Фиксированные параметры расчёта QUIC v1 опубликованы, а защищённых полей в Retry нет. Метка не заменяет сертификат TLS и проверку Finished. Она не определяет экземпляр сервера, не подтверждает его полномочия на имя сервиса и не исключает отправку системой на сетевом пути.

RFC 9000 §17.2.5 задаёт следующий механический шаг клиента. Retry с непроверяемой меткой или пустым токеном нужно отбросить; за одну попытку соединения обрабатывается не более одного Retry. Приняв его, клиент отправляет новый Initial, использует SCID из Retry как DCID и копирует токен. Наблюдаемый Retry запрашивает доказательство обратного пути, но ещё не является завершённым доказательством.

Граница на стороне сервера описана в RFC 9000 §8.1.2. Если клиент возвращает токен, который атакующий не может создать для собственного адреса, сервер может установить, что клиент получил токен. Но сервер всё равно должен проверить его и отказать в соединении либо продолжить его. Трассировка, заканчивающаяся исходящим Retry, не доказывает ни принятия токена, ни завершённой проверки адреса клиента.

Операционный чек должен связывать версию QUIC, пятёрку адресов и время исходного Initial, ODCID, DCID и SCID Retry, точные байты, результат проверки метки, отпечаток токена, пятёрку и время следующего Initial, возвращённый отпечаток, решение сервера, домен или экземпляр проверки, сертификат и Finished TLS и итог соединения. Такой набор отличает рассинхронизацию секретов anycast, истечение срока, смену пути и ошибочную маршрутизацию от подтверждения подлинности сервера.