RFC: 6797
Оригинал: HTTP Strict Transport Security (HSTS)
Категория: Предложенный стандарт
Дата публикации:
Авторы: , ,
Перевод: Семенов Юрий Алексеевич

RFC 6797, Страница 2 из 42

UA обычно уведомляют своих пользователей о любых аспектах безопасности устанавливаемого соединения, таких как невозможность валидации цепочки сертификации TLS, или истечение срока действия TLS сертификата сервера, или если доменное имя компьютера TLS в сертификате некорректно (смотри раздел 3.1 [RFC-2818]). Часто UA позволяют пользователям выбор продолжения или прерывания взаимодействия с WEB-ресурсом при возникновении соответствующих обстоятельств. Такое поведение иногда называется "click(ing) through" ("прокликивание") безопасности [GoodDhamijaEtAl05] [SunshineEgelmanEtAl09]; таким образом, это можно также назвать "прокликиваемой опасностью".

Ключевой уязвимостью, допускаемой прокликиваемой опасностью, является утечка любых куки web-ресурса, которые могут использоваться для управления сессией пользователя. Угроза здесь заключается в том, что атакер может получить куки и затем взаимодействовать с легальным web-ресурсом не персонифицируя себя.

Jackson и Barth предложили в [ForceHTTPS] подход, который позволяет web-ресурсу декларировать, что любые взаимодействия UA с web-ресурсом должны проводиться безопасным способом и что любые последствия установления безопасной транспортной сессии должны рассматриваться фатальными без прямой просьбы пользователя. Целью является предотвращение прокликиваемой опасности и других потенциальных угроз.

Эта спецификация усовершенствует подход, сформулированный в [ForceHTTPS]. Например, вместо использования куки для передачи политики от компьютера web-ресурса к UA, для этой цели определяется поле HTTP-заголовка отклика. Кроме того, машина web-ресурса может декларировать свою политику в отношении всего субдерева доменных имен (корнем которого является его компьютер). Это делает возможным строгую транспортную безопасность HTTP (HSTS), чтобы защитить так называемые "доменные куки", которые приложимы ко всем субдоменам данного имени компьютера web-ресурса.

Заметим, что политика, определяемая в этой спецификации, является совершенно другой по отношению к "same-origin policy" (правило ограничения домена), определенной в "The Web Origin Concept" [RFC-6454]. Эти отличия собраны в приложении B.

Страница 2 из 42

2007 - 2022 © Русские переводы RFC, IETF, ISOC.