


30 октября AWS объявила два новых заголовка CloudFront для передачи сведений о клиентском соединении на исходный сервер: CloudFront-Viewer-ISP и CloudFront-Viewer-TLS-Details. Они помогают анализировать сеть пользователя и согласованные параметры TLS. На Mentoring.digital объясняем, как читать эти данные без лишних выводов.
CloudFront-Viewer-ISP содержит имя интернет-провайдера клиента. Это позволяет сопоставлять наблюдения о работе приложения с сетью, из которой приходят запросы. Если CloudFront не определил провайдера, заголовок не добавляется. Его отсутствие само по себе ещё не доказывает потерю записи в журнале.
Документация разрешает включать ISP-заголовок в origin request policy, но не в cache policy или прежние настройки кеша. Значение передаётся без percent-encoding. При обработке следует сохранять его как значение отдельного поля, не предполагая, что оно всегда является коротким идентификатором.
Второй заголовок содержит JSON с версией TLS, набором шифров, типом рукопожатия, алгоритмом обмена ключами, схемой подписи и типом публичного ключа сертификата. Поле keyExchange позволяет увидеть, использовался ли постквантовый обмен ключами в конкретном соединении.
Для возобновлённой TLS 1.3 сессии обмен ключами указывается, а поля signatureScheme и signaturePublicKeyType принимают NONE. В возобновлённой TLS 1.2 сессии NONE получает также keyExchange. Это предусмотренное представление данных, а не автоматический признак сбоя. Если значение определить нельзя, поле может быть пустым.
Нужные заголовки включаются через политику запросов к origin. После настройки в тестовой конфигурации проверьте получение полей, разбор JSON, отсутствие ISP и обработку NONE. Не связывайте диагностику с одним примером полного рукопожатия.
Новые поля дают наблюдаемость, но сами не включают постквантовую защиту для всех клиентов и не заменяют аутентификацию пользователя. Анализ соединения и выбор политики безопасности решают разные задачи. Разобрать настройку CDN, журналирование и проверку TLS можно с наставником по DevOps.