1. Введение

HTTP [RFC-2616] может использовать различные виды транспорта, обычно это TCP (Transmission Control Protocol). Однако, TCP не предоставляет сервиса конфиденциальности, защиты и безопасной идентификации компьютера. Таким образом, протокол SSL (Secure Sockets Layer) [RFC-6101] и его приемник, TLS (Transport Layer Security) [RFC-5246] были разработаны для того, чтобы обеспечить канальную безопасность. [RFC-2818] специфицирует то, как HTTP согласуется с TLS и определяет схему URI (Uniform Resource Identifier) "https" (на практике, однако, агенты пользователя HTTP (UA) обычно используют либо TLS, либо SSL3, в зависимости от предпочтений сервера и пользователя).

UA используют различные локальные политики безопасности с учетом характеристик их взаимодействия с WEB-ресурсами, в зависимости от того, взаимодействует ли компьютер данного ресурса с привлечением HTTP или HTTP поверх безопасного тракта. Например, куки ([RFC-6265]) могут быть помечены как безопасные. UA должны посылать такие безопасные куки своему компьютеру-адресату только через безопасный транспортный канал. Напротив, небезопасные куки возвращаются компьютеру по любому транспортному каналу (без учета его безопасности).

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. Обзор

В этом разделе обсуждаются случаи использования, обобщается политика HSTS а также рассматривается модель угроз.

2.1. Случаи использования

Случай использования высокого уровня является комбинацией следующих условий:

• Пользователь Web-браузера хочет взаимодействовать с различными сайтами в безопасном режиме.
• Пользователь Web-сайта хочет предложить свой сайт безопасным образом другим пользователям.

2.2. Последствия политики строго безопасного транспорта HTTP

Эффекты политики HSTS в отношении агента пользователя, взаимодействующего с компьютером web-ресурса, на котором реализована такая политика (известный как HSTS-компьютер), можно обобщить следующим образом:

1. UA преобразует небезопасные URI в компьютере HSTS в безопасные ссылки URI, прежде чем к ним обратиться.
2. UA прерывает любые попытки безопасных соединений в случае каких-либо транспортных ошибок или предупреждений.

2.3. Модель угроз

HSTS касается трех классов угроз: пассивные сетевые атакеры, активные сетевые атакеры и плохие разработчики web. Однако, это не является средством борьбы против двух других классов угроз: phishing и malware.

2.3.1. Адресные угрозы

2.3.1.1. Пассивные сетевые атакеры

Когда пользователь просматривает web в локальной беспроводной сети (напр., беспроводная локальная сеть 802.11), близкий атакер может прослушивать незашифрованное Интернет-соединение пользователя, такое как HTTP, вне зависимости от того, является ли беспроводная локальная сеть безопасной [BeckTews09]. Свободно доступные беспроводные средства прослушивания (напр., [Aircrack-ng]) делают возможными такие атаки пассивного прослушивания, даже если локальная беспроводная сеть работает в безопасном режиме. Пассивный сетевой атакер, использующий такой инструментарий, может украсть параметры доступа к сессии и куки, а также перехватить сессию пользователя путем получения куки, содержащего параметры аутентификации, [ForceHTTPS]. Например, существуют широко доступные средства, такие как Firesheep (расширение web-браузера) [Firesheep], которые позволяют получить куки сессий других пользователей для различных web-приложений.

Чтобы ослабить такие угрозы, некоторые web-сайты поддерживают, но не требуют, доступа с использованием безопасного транспорта точка-точка -- напр., запрашиваемого через URI, сформированного по схеме "https" [RFC-2818]. Это может заставить пользователя поверить, что доступ к таким сервисам с использованием безопасного транспорта защищает их от пассивных сетевых атак. К сожалению, это часто не так, так как идентификаторы сессии оказываются записаны в небезопасных куки, что обеспечивает совместимость с версиями сервиса, предлагаемого через небезопасный транспортный канал ("Secure cookies" - это куки, содержащие атрибут "Secure" [RFC6265]). Например, если идентификатор сессии для web-сайта записан в небезопасном куки, атакер может перехватить сессию пользователя, если агент пользователя сделает один небезопасный HTTP-запрос на сайт.

2.3.1.2. Активные сетевые атакеры

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

2.3.1.3. Ошибки разработки Web-сайта и применения

Безопасность в определенных условиях безопасного сайта (то-есть, такого, где все компоненты доступны через "https" URI) может быть полностью компрометирована активным атакером, использующим простую ошибку, такую как загрузка каскадного стилевого списка или SWF-фильма (Shockwave Flash) через небезопасное соединение (как СSS, так и SWF-фильмы могут при загрузке страницы к удивлению многих разработчиков web использовать скрипты, плюс некоторые браузеры не выдают так называемые предупреждения смешенного контента ("mixed content warnings"), когда SWF-файлы загружены через небезопасное соединение). Даже если разработчики сайта тщательно исследуют свою login-страницу на наличие "mixed content", одно небезопасное вложение где-либо на сайте компрометирует безопасность login-страницы, так как атакер может управлять login-страницей с помощью встраиваемого кода (напр., скрипта).

Замечание: "Смешенное содержимое" как это использовалось выше (смотри также раздел 5.3 [W3C.REC-wsc-ui-20100812]) относится к понятию, называемому в данном документе "mixed security context" (смешенный контекст безопасности) и которое не следует смешивать с понятием "mixed content" (смешенное содержимое), используемым в контексте языков разметки, таких как XML и HTML.

2.3.2. Неадресные угрозы

2.3.2.1. Фишинг

Атаки фишинга происходят, когда атакер просит аутентификационные параметры пользователя с помощью фальшивого сайта, размещенного в другом домене по отношению к реальному сайту, перенаправляя трафик на фальшивый сайт, послав соответствующую ссылку в почтовом сообщении. Атаки фишинга могут быть очень эффективными, так как для пользователей оказывается трудно отличить фальшивый сайт от настоящего. HSTS сама по себе не является защитой против фишинга, скорее она дополняет другие существующие средства защиты, путем подсказки браузеру защитить целостность сессии и использовать долговременные параметры аутентификации [ForceHTTPS].

2.3.2.2. Уязвимости, malware и браузеры

Так как HSTS реализуется как механизм безопасности браузера, он базируется на возможности доверять системе пользователя, чтобы защитить сессию. Вредоносный код, исполняемый в системе пользователя, может компрометировать сессию браузера, вне зависимости от того, используется ли HSTS.

2.4. Требования
2.4.1. Общие требования

Необходимо:

• Минимизировать, для пользователей web-браузеров и разработчиков web-сайтов, риски, которые сопряжены с пассивными и активными сетевыми атакерами, ошибками при разработке web-сайтов и небезопасными действиями пользователя.

2.4.1.1. Базовые требования

Базовые требования вытекают из общих требований спецификации.

1. Web-сайты должны быть способны информировать агентов пользователя о том, что доступ к ним должен осуществляться с использованием строгой политикой безопасности.
2. Web-сайты должны уметь инструктировать UA, которые с ними контактируют, работать в безопасном режиме.
3. Агенты пользователя должны сохранять данные о web-сайтах, которые сигнализируют об установлении строгой политики безопасности, на время, декларированное web-сайтами. Кроме того, агенты пользователя должны кэшировать самую свежую информацию о строгой политике безопасности, для того чтобы позволять web-сайтам обновлять эти данные.
4. Агенты пользователя должны переписывать все небезопасные загрузки агентов пользователя "http" URI, чтобы использовать безопасные схемы "https" для этих web-сайтов, для которых активирована строгая политика безопасности.
5. Администраторы Web-сайтов должны быть способны сообщать о приложениях со строгой политикой безопасности субдоменам доменов высокого уровня, для которых активирована строгая политика безопасности, и обязать агенты пользователя установить такую политику.

Например, как example.com так и foo.example.com могут установить политику для bar.foo.example.com.

6. UA должны запретить приложениям политики безопасности контактировать с доменами и/или доменами высокого уровня, при доменах, для которых разрешена строгая политика безопасности.

Например, ни bar.foo.example.com, ни foo.example.com не могут задать политику для example.com, аналогично bar.foo.example.com не может задавать политику для foo.example.com. Точно также, foo.example.com не может установить политику для sibling.example.com.

7. UA должен препятствовать пользователям "прокликивать" предупреждения безопасности, останавливая попытки соединений перед лицом возможности нарушения безопасности. Смотри также раздел 12.1 ("No User Recourse").

2.4.1.2. Дополнительные требования

Эти дополнительные требования также выводятся из общих требований.

1. Запретить загрузки "mixed security context" (смотри раздел 2.3.1.3).
2. Облегчить декларацию пользователем web-сайтов, для которых действует строгая политика безопасности, вне зависимости от того, анонсирует ли сайты HSTS-политику.

3. Критерии соответствия

Данная спецификация написана для компьютеров и агентов пользователя.

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

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

4. Терминология

Терминология, определенная в данном разделе.

Сравнение ASCII-строк, не чувствительное к регистру:

означает сравнение двух строк, за исключением того, что символы в диапазоне U+0041 .. U+005A (то-есть, от латинской прописной буквы A до латинской прописной буквы Z) и соответствующие символы в диапазоне U+0061 .. U+007A (то-есть, от латинской строчной буквы a до латинской строчной буквы z) рассматриваются идентичными. Смотри [Unicode].

codepoint:

является разговорным сокращением Code Point, которое может соответствовать любому значению из кодового пространства Unicode; то-есть, диапазон целых чисел от 0 до 10FFFF(hex) [Unicode].

Доменное имя:

эквивалентно "DNS-имя", оно определено в [RFC-1035], оно находится вне области действия протокола DNS, представляет собой последовательность меток, разделенных точками, напр., "example.com" или "yet.another.example.org". В контексте данной спецификации доменные имена являются частью URI, удовлетворяющей рекомендациям из "Приложение A. Collected ABNF for URI" в [RFC-3986], а также элементом поля заголовка HTTP, формируемым компьютером, смотри раздел 14.23 [RFC-2616].

Метка доменного имени:

является частью доменного имени, появляющейся "между двумя точками", то-есть, в "foo.example.com": "foo", "example" и "com" все являются метками доменного имени.

Эффективный запрос URI:

URI, идентифицирующий ресурс адресата, который может быть указан HTTP-компьютером для заданного, полученного им HTTP-запроса. Такой интерфейс необходим, так как HTTP-запросы часто не содержат полного, абсолютного URI, идентифицирующего ресурс адресата. Смотри раздел 9 ("Constructing an Effective Request URI").

Строгая транспортная безопасность HTTP:

обобщенное название для комбинации агента пользователя и политики безопасности сервера, описываемой в данной спецификации.

Компьютер со строгой транспортной безопасностью HTTP:

представляет собой компьютер, реализующий принципы политики HSTS для HTTP-сервера. Это означает, что HSTS-компьютер присылает поле заголовка HTTP-отклика "Strict-Transport-Security" в HTTP-сообщении, посланном через безопасный канал.

Политика строгой транспортной безопасности HTTP:

является именем комбинации агента пользователя и аспекта поведения сервера, определяемого данной спецификации.

Компьютер HSTS:

Смотри HTTP компьютер со строгой транспортной политикой безопасности.

Известный компьютер HSTS:

является HSTS-компьютером, для которого агент пользователя, имеет действующую HSTS-политику; то-есть, агент пользователя помечает свой компьютер как известный HSTS-компьютер. Подробности смотри в разделе 8.1.1 ("Noting an HSTS-компьютер - Storage Model").

Локальная политика:

включает в себя правила политики, которые, специфицировал разработчик и которые часто объявляются установками конфигурации.

MITM:

является сокращением для "man in the middle". Смотри "man-in-the-middle attack" в [RFC-4949].

Запрос URI:

является URI, используемым в случае, когда нужно послать HTTP-запрос. Смотри также "Effective Request URI".

UA:

сокращение для "user agent". В данной спецификации агент пользователя является клиентским приложением HTTP, активно манипулируемым пользователем [RFC-2616].

Неизвестный HSTS-компьютер:

является HSTS-компьютером, которого агент пользователя не заметил.

5. Обзор механизма HSTS

Этот раздел представляет собой обзор механизма, с помощью которого HSTS-компьютер передает свою HSTS-политику агентам пользователя, и то, как агенты пользователя работают с политикой HSTS, полученной от HSTS-компьютера. Подробности этого механизма описаны в разделах 6 - 15.

5.1. Декларация компьютера HSTS

Компьютер HTTP анонсирует себя как HSTS-компьютер путем передачи агенту пользователя политики HSTS, которая характеризуется полем заголовка отклика HTTP строгой транспортной безопасности (Strict-Transport-Security), переданным через безопасный транспортный канал (напр., TLS). После безошибочного получения и обработки этого заголовка соответствующим агентом пользователя, агент пользователя воспринимает такой компьютер как известный HSTS-компьютер (Known HSTS-компьютер).

5.2. Политика HSTS

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

Политика HSTS явным образом меняет алгоритм обработки ссылок URI агентами пользователя, ввод пользователя (напр., через "location bar"), или другую информацию, которая в отсутствии политики HSTS, может позволить агенту пользователя взаимодействовать с известным HSTS-компьютером небезопасным образом.

Политика HSTS может содержать опционную директиву -- includeSubDomains -- указывающую, что эта политика HSTS приложима также к любым компьютерам, чье доменное имя соответствует субдомену доменного имени известного HSTS-компьютера.

5.3. Сохранение политики HSTS и управление агентами пользователя

Агент пользователя запоминает и индексирует политики HSTS на основе доменных имен HSTS-компьютеров.

Это означает, что агенты пользователя будут поддерживать политику HSTS любого данного HSTS-компьютера независимо от каких-либо HSTS-политик, сформированных любыми другими HSTS-компьютерами, чьи доменные имена принадлежат субдоменам HSTS-компьютера. Только данный HSTS-компьютер может обновлять или может стимулировать ликвидацию своей политики HSTS. Эта процедура завершается посылкой поля заголовка HTTP-отклика Strict-Transport-Security агенту пользователя с новыми значениями времени применимости политики и субдомена. Таким образом, агент пользователя кэширует для HSTS-компьютера самую свежую версию политики HSTS. Спецификация сигналов нулевой длительности сигнализирует агенту пользователя ликвидировать политику HSTS (включая любые встроенные директивы includeSubDomains) для этого HSTS-компьютера. Смотри также раздел 8.1 ("Strict-Transport-Security Response Header Field Processing"). Кроме того, в разделе 6.2 представлены примеры полей заголовка отклика Strict-Transport-Security HTTP.

5.4. Усиление политики агента пользователя HSTS

Когда устанавливается HTTP-сединение до заданного компьютера, UA просматривает свой кэш известных HSTS-компьютеров, чтобы определить, есть ли там доменные имена, которые являются супердоменами данного доменного имени компьютера. Если таковые обнаружатся, и если там содержится директива includeSubDomains, тогда политика HSTS будет применена к данному компьютеру. В противном случае, политика HSTS реализуется для данного компьютера, только если этот компьютер известен агенту пользователя в качестве HSTS-компьютера. Смотри также раздел 8.3 ("URI Loading and Port Mapping").

6. Синтаксис

В этом разделе определяется синтаксис полей заголовков HTTP-откликов Strict-Transport-Security и их директив, а также представлены некоторые примеры.

6.1. Поле отклика HTTP при строгой транспортной безопасности

Поле заголовка отклика Strict-Transport-Security HTTP (поле заголовка STS) указывает агенту пользователя, что он должен активировать HSTS-политику относительно того, что компьютер отправил отклик, содержащий это поле заголовка.

ABNF (Augmented Backus-Naur Form - расширенная форма Бакуса-Наура) синтаксис для поля заголовка STS представлен ниже. Он базируется на общей грамматике, описанной в разделе 2 [RFC-2616] (где содержится нотация "implied linear whitespace", известная также как "implied *LWS").

Strict-Transport-Security = "Strict-Transport-Security" ":"
                                 [ directive ]  *( ";" [ directive ] )

     directive                 = directive-name [ "=" directive-value ]
     directive-name            = token
     directive-value           = token | quoted-string

где:

token          = <token, defined in [RFC2616], раздел 2.2>
     quoted-string  = <quoted-string, defined in [RFC2616], раздел 2.2>

Ниже рассмотрены две директивы, определенные в данной спецификации. Общие требования для директив:

1. Порядок появления директив не имеет значения.
2. Все директивы в поле заголовка STSдолжны появляться только один раз. Директивы бывают опционными или обязательными, как это диктуется их определениями.
3. Имена директив не чувствительны к регистру.
4. Агенты пользователя должны игнорировать любое поле заголовка STS, содержащее директивы или другие данные поля заголовка, которые не соответствуют синтаксису, описанному в данной спецификации.
5. Если поле заголовка STS, содержащее директиву, не распознано агентом пользователя, агент пользователя должен игнорировать нераспознанные директивы, и если поле заголовка STS удовлетворяет названным выше требованиям (1 - 4), агент пользователя должен обрабатывать распознанные директивы.

6.1.1. Директива max-age

Обязательная директива (REQUIRED) "max-age" специфицирует число секунд, после приема поля заголовка STS, в течение которых агент пользователя воспринимает компьютер, от которого получено сообщение, в качестве известного HSTS-компьютера. Cмотри также раздел 8.1.1 ("Регистрация HSTS-компьютера - Модель запоминания"). Формирование интервала секунд специфицировано в [RFC-2616].

Синтаксис директивы max-age требует значения, определяемого как:

max-age-value = delta-seconds

    delta-seconds = <1*DIGIT, defined in [RFC2616], раздел 3.3.2>

Замечание: Значение max-age нуль (то-есть, "max-age=0") сообщает агенту пользователя, что следует прекратить рассматривать компьютер в качестве известного HSTS-компьютера, включая директиву includeSubDomains (если она была задействована для HSTS-компьютера). Смотри также раздел 8.1 ("Strict-Transport-Security Response Header Field Processing").

6.1.2. Директива includeSubDomains

Опционная директива "includeSubDomains" не содержит значения, и если присутствует (то-есть, она "вставлена"), сигнализирует агенту пользователя, что политика HSTS применима к данному HSTS-компьютеру, а также к любому субдомену доменного имени компьютера.

6.2. Примеры

Поле заголовка HSTS требует, чтобы политика HSTS оставалась активной в течение года (в году около 31536000 секунд), и политика применяется только к домену HSTS-компьютера:

Strict-Transport-Security: max-age=31536000

Поле заголовка HSTS, приведенное ниже, требует, чтобы политика HSTS продолжала действовать примерно 6 месяцев и что политика применима к домену HSTS-компьютера и всем его субдоменам:

Strict-Transport-Security: max-age=15768000 ; includeSubDomains

Значение директивы max-age может быть опционно помещено в кавычки:

Strict-Transport-Security: max-age="31536000"

Поле заголовка HSTS, представленное ниже, указывает, что агент пользователя должен стереть всю политику HSTS, сопряженную с HSTS-компьютером, который послал поле заголовка:

Strict-Transport-Security: max-age=0

Поле заголовка HSTS, представленное ниже, имеет в точности тот же эффект, как и приведенное выше, так как присутствие директивы includeSubDomains в поле заголовка HSTS игнорируется, когда max-age=0:

Strict-Transport-Security: max-age=0; includeSubDomains

7. Модель работы сервера

В этом разделе описывается модель работы HSTS-компьютеров. Модель использует два аспекта: первый сопряжен с правилами обработки запросов HTTP, полученных через безопасный канал (TLS [RFC-5246] или SSL [RFC-6101]; смотри также раздел 14.1 ("Underlying Secure Transport Considerations"), и второй, связанный с правилами обработки сообщений запросов HTTP, полученных через небезопасный канал, такой как TCP.

7.1. Тип запроса HTTP-через-безопасный-транспортный канал

При ответе на HTTP-запрос, который был передан через безопасный канал, HSTS-компьютер должен включить в свой отклик поле заголовка STS, должен удовлетворять грамматике, описанной в разделе 6.1 ("Поле заголовка отклика HTTP Strict-Transport-Security"). Если поле заголовка STS имеется, HSTS-компьютер должен включить в отклик только это поле.

Установление данного компьютера, как известного HSTS-компьютера, в контексте данного агента пользователя, может быть выполнено через HTTP, который в свою очередь работает через безопасный канал, путем правильного возвращения агенту пользователя как минимум одного корректного поля заголовка STS. Может использоваться другой механизм, такой как предварительно загружаемый список известных HSTS-компьютеров; напр., смотри раздел 12 ("User Agent Implementation Advice").

7.2. Тип запроса HTTP

Если HSTS-компьютер получает HTTP-запрос через небезопасный канал, он должен послать HTTP-отклик, содержащий статусный код, индицирующий постоянную переадресацию, такой как статусный код 301 (раздел 10.3.2 [RFC-2616]), и значение поля заголовка Location (положение), содержащий либо HTTP эффективный URI запроса (смотри раздел 9 ("Constructing an Effective Request URI")), измененный в соответствии со схемой URI "https", либо URI, сгенерированный согласно локальной политике по схеме "https".

Замечание: Выше описанное поведение нужно рассматривать скорее, как желательное, а не обязательное:

• Риски переадресаций небезопасной-безопасный для стороны сервера [OWASP-TLSGuide].
• Характеристики размещения сайта. Например, сайт, который содержит компоненты третьей стороны, может не работать корректно, когда осуществляется переадресация небезопасный-безопасный для стороны сервера, в случае доступа через небезопасный канал, но работает корректно, когда доступ осуществляется через безопасный канал. В последнем случае реализуется вариант агента пользователя HSTS, который уже определил сайт, как известный HSTS-компьютер.

HSTS-компьютер не должен включать поле заголовка STS в HTTP-отклики, передаваемые через небезопасный канал.

8. Модель работы агента пользователя

Этот раздел описывает модель обработки строгой транспортной безопасности HTTP для агентов пользователя. Существует несколько аспектов модели, перечисленных в последующих разделах.

Эта модель обработки предполагает, что агент пользователя использует IDNA2008 [RFC-5890], или возможно IDNA2003 [RFC-3490], как это указано в разделе 13 ("Internationalized Domain Names for Applications (IDNA): Dependency and Migration"). Это также предполагает, что все доменные имена, рассматриваемые в данном документе, приведены в соответствие с требованиями IDNA, как это описано 10 ("Domain Name IDNA-Canonicalization").

Вышеприведенные предположения означают, что эта модель обработки подразумевает, что соответствующая валидация IDNA и Unicode выполнена для всех доменных имен, до выполнения операция, описанных в данном разделе. Специфические соображения безопасности IDNA рассмотрены в разделе 14.10 ("Internationalized Domain Names").

8.1. Обработка поля заголовка отклика Strict-Transport-Security

Если отклик HTTP, полученный через безопасный канал, содержит поле заголовка STS, соответствующее грамматике, специфицированной в разделе 6.1 ("Strict-Transport-Security HTTP Response Header Field"), и нет ошибок или предупреждений транспортной безопасности (смотри раздел 8.4), агент пользователя должен либо:

• Пометить компьютер, как известный HSTS-компьютер, если он не был помечен ранее (смотри раздел 8.1.1 ("Noting an HSTS-компьютер - Storage Model")),

либо

• Обновить кэшированную информацию агента пользователя для известного HSTS-компьютера, если значения полей заголовка max-age и includeSubDomains содержат информацию, отличную от той, которую уже имел агент пользователя.

Значение max-age является временем жизни, привязанным к моменту получения поля заголовка STS.

Если значение поле заголовка max-age равно нулю, агент пользователя должен удалить свою кэшированную информацию политики HSTS (включая директиву includeSubDomains, если она специфицирована), если HSTS-компьютер известен, или агент пользователя не должен замечать этот HSTS-компьютер, если он еще не известен.

Если агент пользователя получает в HTTP-отклике через безопасный канал более одного поля заголовка STS, тогда агент пользователя должен обрабатывать только первое из полей заголовка.

В противном случае:

• Если HTTP-отклик получен через небезопасный канал, агент пользователя должен игнорировать любое поле заголовка STS.
• UA должен игнорировать любые поля заголовка STS, не соответствующие грамматике, специфицированной в разделе 6.1 ("Strict-Transport-Security HTTP Response Header Field").

8.1.1. Выявление HSTS-компьютера - Модель запоминания

Если субстрока соответствует компьютеру из Request-URI (отклика компьютера) и синтаксически соответствует символьному IP или IPv4-адресу (см. раздел 3.2.2 of [RFC-3986]), тогда агент пользователя не должен помечать компьютер, как известный HSTS-компьютер.

В противном случае, если субстрока не соответствует доменному имени известного HSTS-компьютера, как это специфицировано в процедуре раздела 8.2 ("Known HSTS-компьютер Domain Name Matching"), агент пользователя должен пометить компьютер как известный HSTS-компьютер, кэшируя доменное имя HSTS-компьютера. Смотри также раздел 11.2 ("политика HSTS Expiration Time Considerations").

Агент пользователя не должен модифицировать время пригодности или директиву includeSubDomains любого супердомена, соответствующего известному HSTS-компьютеру.

Известный HSTS-компьютер перестает быть таковым, если запись в кэше имеет истекшее время пригодности. Агент пользователя должен удалить все известные HSTS-компьютеры из своего кэша, если срок пригодности содержимого истек.

8.2. Сверка имени домена известного HSTS-компьютера

Данное доменное имя может соответствовать доменному имени известного HSTS-компьютера в одном из двух вариантов: конгруэнтное соответствие, или соответствие супердоменов. В противном случае, соответствия не будет.

Последующие шаги определяют, было ли соответствие и, если было, то какое:

Сравнение данного доменного имени с доменным именем каждого известного HSTS-компьютера данного агента пользователя. Для каждого доменного имени HSTS-компьютера сравнение выполняется метка за меткой (сравниваются только метки) используя ASCII-сравнение, чувствительное к регистру, начиная с самого правой метки, и продолжая справа-налево. Смотри также раздел 2.3.2.4 [RFC-5890].

• Сверка супердомена

Если label-for-label соответствие между всем доменном именем известного HSTS-компьютера и правой части данного доменного имени найдено, тогда доменное имя этого известного HSTS-компьютера соответствует супердомену для данного доменного имени. Возможно множественное доменное соответствие для заданного доменного имени.

Например:

• Конгруэнтное соответствие

Если найдено соответствие метка-за-меткой между доменным именем известного HSTS-компьютера и заданным доменным именем -- то-есть, нет больше имен для сравнения -- тогда данное доменное имя полностью соответствует известному HSTS-компьютеру.

Например:

Данное доменное имя:                foo.example.com

            Congruently matched
            Known HSTS-компьютер DN:               foo.example.com

• Иначе, если соответствия не найдено, данное доменное имя не представляет известный HSTS-компьютер.

8.3. Загрузка URI и привязка портов

Когда бы агент пользователя не приготовил "загрузку" (также известна как "разыменование"), любое "http" URI [RFC3986] (включая случай перенаправления HTTP [RFC-2616]), агент пользователя должен сначала определить, является ли доменное имя из URI именем известного HSTS-компьютера, используя следующие шаги:

1. Извлечь из URI субстроку, описывающую компьютерный компонент URI.
2. Если субстрока является нулевой, соответствие с известным HSTS-компьютером отсутствует.
3. Иначе, если субстрока не является нулевой и синтаксически соответствует символьному IP или IPv4-адресу (см. раздел 3.2.2 [RFC-3986]), тогда соответствие какому-либо известному HSTS-компьютер отсутствует.
4. В противном случае, субстрока является доменным именем, которое должно соответствовать известному агенту пользователя HSTS-компьютера (см. раздел 8.2 "Known HSTS-компьютер Domain Name Matching").
5. Если, при выполнении сверки доменного имени оно соответствует какому-то супердомену со вставленной директивой includeSubDomains или, если супердомен соответствует вставленной директиве includeSubDomains и выявлено полное соответствие (с или без встроенной директивой includeSubDomains), тогда перед тем как продолжит загрузку:

Агент пользователя должен заменить URI-схему "https" [RFC-2818], и если URI содержит компонент порта равный "80", тогда агент пользователя должен сделать компонент порта равным "443", или если URI содержит компонент порта не равный "80", содержимое компонента порта должно быть сохранено; в противном случае,

если URI не содержит компонента порта, агент пользователя не должен его добавлять.

Замечание: Эти шаги гарантируют, что политика HSTS реализуется для HTTP через какой-то TCP-порт HSTS-компьютера.

Замечание: В случае, когда имеется код порта, и, вероятно, работает HTTP-сервер в небезопасном режиме, HTTPS-запрос не будет реализован (смотри пункт 6 в Приложение A ("Design Decision Notes")).

8.4. Ошибки установления безопасного канала

При установлении соединения известного HSTS-компьютера, агент пользователя должен прерывать соединение (смотри также раздел 12 ("User Agent Implementation Advice")), если имеются какие-либо ошибки, "warning", "fatal" или любого другого уровня. Например, сюда относятся любые ошибки, выявленные при валидации сертификатоа, используемого агентом пользователя. Это может быть следствием сверки со списком аннулированных сертификатов CRL (Certificate Revocation Lists) [RFC-5280], или результатом работы протокола OCSP (Online Certificate Status Protocol) [RFC-2560], или проверки идентичности TLS-сервером [RFC-6125].

8.5. HTTP-Equiv элемент атрибута <Meta>

Агент пользователя не должен обращать внимание на значение атрибута http-equiv="Strict-Transport-Security" элементов <meta> [W3C.REC-html401-19991224] в полученных данных.

8.6. Отсутствие поля заголовка отклика Strict-Transport-Security

Если агент пользователя получает HTTP-отклики от известного HSTS-компьютера через безопасный канал, но в откликах отсутствует поле заголовка STS, агент пользователя должен продолжать считать компьютер известным HSTS-компьютером, пока значение max-age для данного HSTS-компьютера не достигнет предела. Заметим, что значение max-age может быть бесконечным для данного известного HSTS-компьютера. Например, это может быть в случае, если известный HSTS-компьютер является частью заранее сконфигурированного списка, который реализован так, что срок годности элементов списка никогда не истечет.

9. Формирование URI эффективного запроса

В этом разделе специфицируется то, как HSTS-компьютер должен формировать эффективный URI запроса для полученного HTTP-запроса.

HTTP-запросы часто не содержат абсолютных URI для целевых ресурсов; вместо этого, URI должно быть получено из Request-URI, поля заголовка компьютера (Host), и контекста соединения ([RFC-2616], разделы 3.2.1, 5.1.2, и 5.2). Результат этого процесса называется "эффективным URI запроса (ERU)". "Целевой ресурс" является ресурсом, идентифицируемым эффективным URI запроса.

9.1. Фундаментальные определения ERU

Первая строка сообщения запроса HTTP, Request-Line, специфицируется следующем образом в нотации ABNF из [RFC-2616], раздел 5.1:

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

Request-URI, в Request-Line, специфицируется следующим ABNF-выражением из [RFC-2616], раздел 5.1.2:

Request-URI    = "*" | absoluteURI | abs_path | authority

Поле заголовка компьютера специфицируется следующим ABNF-описанием из [RFC-2616], раздел 14.23:

Host = "Host" ":" host [ ":" port ]

9.2. Определение эффективного URI запроса

Если Request-URI является абсолютным URI, тогда эффективный URI запроса равен Request-URI.

Если Request-URI использует форму abs_path или *-форму и имеется поле заголовка компьютера, тогда эффективный URI запроса формируется объединением:

• имя схемы: "http", если запрос был получен через небезопасное TCP-соединение, или "https", когда получен через безопасное TLS/SSL TCP-соединение, и
• строка октетов "://", и
• компьютер и порт (если имеется), из поля заголовка Host, и
• Request-URI, полученный из Request-Line, если только не является всего лишь звездочкой "*".

Если Request-URI использует форму abs_path form или *-форму, и поле заголовка Host отсутствует, тогда эффективный URI запроса не определен.

В противном случае, когда Request-URI использует адресную форму, эффективный URI запроса не определен.

Эффективные URI запросов сравниваются с использованием правил, описанных в [RFC-2616] раздел 3.2.3, за исключением того, что пустая компонента не должна рассматриваться эквивалентной абсолютному проходу типа "/".

9.2.1. Примеры эффективных запросов URI

Пример 1: эффективный URI запроса для сообщения

GET /pub/WWW/TheProject.html HTTP/1.1
     Host: www.example.org:8080

(полученный через небезопасное TCP-соединение) является "http", плюс "://", плюс адресный компонент типа "www.example.org:8080", плюс адрес запроса "/pub/WWW/TheProject.html". Таким образом, получаем "http://www.example.org:8080/pub/WWW/TheProject.html".

Пример 2: эффективный URI запроса для сообщения

OPTIONS * HTTP/1.1
     Host: www.example.org

   (полученное через безопасное SSL/TLS TCP-соединение) является "https", плюс
   "://", плюс компонент типа "www.example.org".  Таким образом, получено
   "https://www.example.org".

10. IDNA-канонизация доменного имени

IDNA-канонизированное доменное имя является выходной строкой, сформированной в результате следующих шагов. Исходной является строка предполагаемого доменного имени, состоящая из некоторой комбинации "A-меток", "U-меток" и "NR-LDH меток" (смотри раздел 2 [RFC-5890]) объединенных с использованием некоторых символов-сепараторов (обычно ".").

1. Преобразуем входную строку предполагаемого доменного имени в последовательность отдельных меток.
2. Когда используется IDNA2008, преобразуем, валидируем и тестируем каждую A-метку и U-метку, найденную среди последовательности отдельных строк-меток, используя процедуры, определенные в разделах с 5.3 по 5.5 [RFC-5891].

В противном случае, когда используется IDNA2003, преобразуем каждую метку, применяя процедуру преобразования "ToASCII" из раздела 4 [RFC-3490] (смотри также определение "эквивалентности меток" в разделе 2 [RFC-3490]).

3. Если на предыдущем шаге ошибок не произошло, объединяем все метки в последовательность, с символом %x2E (".") между ними. Результирующая строка, известная как канонизированное доменное имя IDNA, пригодна для использования в контексте раздела 8 ("User Agent Processing Model").

В противном случае, происходят ошибки. Входная строка предполагаемого доменного имени не была успешно приведена к виду IDNA. Инициаторы этой процедуры должны попытаться осуществить коррекцию ошибок.

Смотри также разделы 13 ("Internationalized Domain Names for Applications (IDNA): Dependency and Migration") и 14.10 ("Internationalized Domain Names").

11. Реализация сервера и советы по размещению

11.1. Соображения для нестандартного агента пользователя

Агенты пользователя, несоответствующие стандарту, игнорируют поле заголовка Strict-Transport-Security; и пренебрегают угрозами, описанными в разделе 2.3.1 ("Threats Addressed"). Смотрите также раздел 14.2 ("Non-Conformant User Agent Implications").

11.2. Соображения о времени пригодности политики HSTS

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

Подход "фиксированного момента в будущем" можно реализовать путем регулярной посылки агенту пользователя одного и того же значения max-age.

Например, значение max-age в 7776000 секунд соответствует 90 дням:

Strict-Transport-Security: max-age=7776000

Заметим, что каждое получение этого заголовка агентом пользователя потребует обновления своих данных.

Подход "фиксированного момента времени" может быть реализован путем посылки значений max-age, которые представляют время, оставшееся до желательного момента завершения пригодности. Это потребует, чтобы HSTS-компьютер посылал вновь вычисленное значение max-age в каждом HTTP-отклике.

Здесь нужно учесть, хочет ли пользователь получать сигнал о том, что время пригодности политики HSTS соответствует доменному сертификату web-сайта.

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

11.3. Использование HSTS совместно с сертификатом самоподписываемого общедоступного ключа

Если выполнены все четыре следующих условия, то.

• web сайт/организация/предприятие для обеспечения безопасности канала генерируют свои собственные сертификаты открытых ключей для web-сайтов, и
• сертификат корневого центра сертификации организации (CA) обычно не записывается в браузер по-умолчанию и/или в хранилище сертификатов операционной системы CA, и
• политика HSTS на компьютере активна, идентифицирует себя с помощью сертификата, подписанного CA организации (то-есть, "самоподписанный сертификат"), и
• этот сертификат не соответствует используемой ассоциации сертификатов TLS (как это определено в разделе 4 спецификации TLSA-протокола [RFC-6698]),

...далее безопасное соединение с этим сайтом будет разорвано, по инициативе HSTS. Это защищает от различных активных атак, как это было обсуждено выше.

Однако, если оговоренная организация хочет использовать свой собственный CA, и самоподписанные сертификаты, во взаимодействии с HSTS, она может это делать путем использования своего сертификата корневого CA в своих браузерах или в хранилище сертификатов операционной системы. Она может также, кроме того или в дополнение, разослать своим браузерам пользователей последние сертификаты для определенных компьютеров. Существуют разные пути того, как это можно осуществить. Раз сертификат корневого CA установлен в его браузере, его может использовать политика HSTS на своих сайтах.

В противном случае, эта организация может применить TLSA-протокол; все браузеры, которые также используют TLSA смогут доверять сертификатам, идентифицированным ассоциацией TLS-сертификатов, как это задано TLSA.

11.4. Смысл includeSubDomains

Директива includeSubDomains имеет практические последствия, достойные тщательного рассмотрения; ниже предлагаются примеры сценариев:

• HSTS-компьютер предлагает небезопасные HTTP-сервисы на альтернативные порты или при различных субдоменах доменного имени HSTS-компьютера.
• Отдельные web-приложения предлагают отдельные субдомены HSTS-компьютера, такие, что агенты пользователя часто взаимодействуют с этими субдоменными web-приложениями без необходимости взаимодействия с web-приложением, предлагаемым доменным именем HSTS-компьютера.

11.4.1. Соображения о небезопасных HTTP-сервисах на альтернативных портах или субдоменах HSTS-компьютера

Например, центры сертификации часто предлагают свою рассылку списков аннулирования сертификатов и OCSP-сервисы [RFC-2560] через обычный HTTP, и иногда через субдомен публично доступного web-приложения, безопасность которого обеспечивается TLS/SSL. Например, <https://ca.example.com/> является публично доступным web-приложением для сертификационного центра "Example CA". Клиенты используют это web-приложение для регистрации своих общедоступных ключей и для получения сертификатов. "Example CA" генерирует сертификаты для клиентов, содержащих <http://crl-and-ocsp.ca.example.com/> в качестве значения для "CRL Distribution Points" и "Authority Information Access:OCSP" полей сертификата.

Если бы ca.example.com сформулировал политику HSTS с директивой includeSubDomains, тогда агенты пользователя HTTP, использующие HSTS, которые взаимодействуют с web-приложением ca.example.com, не смогли бы получить список CRL и не смогли проверить OCSP для сертификатов, так как эти сервисы предлагаются напрямую через HTTP.

В этом случае, Example CA может либо:

• не использовать директиву includeSubDomains, или
• гарантировать, что сервис на основе HTTP, предлагаемый субдоменами ca.example.com, доступны также через TLS/SSL, или
• предложить HTTP-сервис для альтернативного доменного имени, напр., crl-and-ocsp.ca.example.NET, или
• использовать альтернативный подход для рассылки статусной информации сертификата, исключая необходимость рассылки CRL и OCSP-сервисов через HTTP (напр., "Certificate Status Request" TLS расширений [RFC-6066], часто называемых "OCSP Stapling").

11.4.2. Соображения предложения Web-приложений через субдомены HSTS-компьютера

При этом сценарии, HSTS-компьютер анонсирует политику HSTS с директивой includeSubDomains, и существует также определенные web-приложения, предложенные в определенном субдомене HSTS-компьютера, такие, что агент пользователя, который часто взаимодействует с этими субдоменными web-приложениями, не обязательно взаимодействует с HSTS-компьютером. В таком случае, агенты пользователя не получат или не реализуют HSTS-политику.

Например, HSTS-компьютер является "example.com", и он сконфигурирован для формирования поля заголовка STS с директивой includeSubDomains. Однако, Web-приложение example.com вызывается из "www.example.com", а example.com просто переадресует агента пользователя на "https://www.example.com/".

Если поле заголовка STS сформировано "example.com", а агенты пользователя соединены с -- "www.example.com" и "example.com" и не контактируют непосредственно со всеми агентами пользователя, в некотором ненулевом проценте случаев соединений, тогда некоторое число агентов пользователя не воспримут "example.com" в качестве HSTS-компьютера, а некоторое число пользователей "www.example.com" будут не защищены при политике HSTS.

Чтобы соответствовать таким требованиям, HSTS-компьютеры должны быть сконфигурированы таким образом, что поле заголовка STS формировалось непосредственно в домене HSTS-компьютера или субдомене, который представляет собой хорошо известную "точку входа" для одного из web-приложений, вне зависимости от того используется ли директива includeSubDomains или нет.

Таким образом, в нашем примере, если поле заголовка STS прислано как из "example.com", так и "www.example.com", условия будут выполнены. Если имеются любые другие известные входные точки в web-приложение, предлагаемые "example.com", таким как "foo.example.com", они также должны быть сконфигурированы для эмиссии поля заголовка STS.

12. Рекомендации по реализации агента пользователя

Для того чтобы обеспечить пользователей и web-сайты более эффективной защитой, а также управляемостью кэшерования политики HSTS, разработчики агентов пользователей должны предусмотреть следующие меры:

12.1. Без обращения пользователя

Неудача установления безопасного соединения при любом предупреждении или ошибке (см. раздел 8.4 ("Errors in Secure Transport Establishment")) должна быть осуществлена без возможности обращения к пользователю "no user recourse". Это означает, что пользователь не должен присутствовать в диалоге, дающим ему возможность продолжения. Скорее, это должно восприниматься подобно ошибке сервера, где пользователю не позволяется дальнейшее взаимодействие с web-приложением, кроме ожидания и повторной попытки.

По существу, "любые предупреждения или ошибки" принуждают реализацию агента пользователя объявить, что с установлением соединения что-то не вполне корректно.

Отступление от этого, то-есть, позволение пользователю возможности "прокликивания диалога предупреждения/ошибки", представляет собой рецепт атаки типа человек-по-середине (MITM). Если web-приложение анонсирует политику HSTS, тогда оно входит в режим "никакой помощи пользователю", и в соответствии со всеми ошибками сертификации или предупреждениями разрывает соединение, не оставляя шанса навредить себе неверными действиями.

12.2. Политика HSTS, декларированная пользователем

Объявленная пользователем политика HSTS является возможностью для пользователей декларировать данное доменное имя, как имя HSTS-компьютера, таким образом, объявляя его как известный HSTS-компьютер до каких-либо с ним взаимодействий. Это поможет защититься от угрозы типа MITM, как это рассказано в разделе 14.6 ("Bootstrap MITM Vulnerability").

12.3. Предварительно загруженный список HSTS

Предварительно загруженный список HSTS является возможностью с помощью администраторов web-сайта предварительно сконфигурировать агента пользователя с политикой HSTS. Это поможет защититься от уязвимости загрузки в случае MITM (раздел 14.6).

Замечание: Такая возможность дополнит "политику HSTS, декларированную пользователем" (раздел 12.2).

12.4. Запрещение загрузок со смешенным контекстом безопасности

Загрузки "со смешенным контекстом безопасности" происходят, когда ресурс web-приложения, доставлен агентом пользователя через безопасный канал, а позднее один или более ресурсов доставлено через небезопасный канал (смотри раздел 5.3 ("Mixed Content") в [W3C.REC-wsc-ui-20100812]), но не следует смешивать с термином "смешанный контент", который используется в контексте языков разметки, таких как XML и HTML.

Замечание: Для того чтобы обеспечить поведенческую однородность при реализации агента пользователя, нотация смешанного контекста безопасности потребует дальнейшей стандартизации.

12.5. Удаление политики HSTS

Удаление политики HSTS представляет собой возможность удаления из кэша агента пользователя политики HSTS.

Замечание: добавление такой возможности следует делать очень осторожно, как с точки зрения пользовательского интерфейса, так и безопасности. Удаление записи в кэше для известного HSTS-компьютера должно осуществляться обдумано -- это не должно быть чем-то, что пользователь делает между прочем, напр., простым "прокликиванием". Реализации должны быть защищены и не позволять атакеру инжектировать код, напр., ECMAscript, в агент пользователя, который удаляет записи из кэша агента пользователя известного HSTS-компьютера.

13. Интернационализированные имена доменов для приложений (IDNA): Зависимость и миграция

Текстовые доменные имена современного Интернет могут содержать один или более "интернациональных" меток доменных имен. Такие доменные имена относятся к "интернациональным доменным именам" (IDN). IDN и протоколы для их использования называются "Internationalized Domain Names for Applications (IDNA)". В настоящее время существует два таких объекта: IDNA2008 [RFC-5890] и его предшественник IDNA2003 [RFC-3490].

IDNA2008 делает устаревшим IDNA2003, но существует отличие между этими двумя спецификациями, и таким образом, могут быть отличия в обработке (напр., преобразовании) меток доменных имен. Будет иметь место некоторый переходной период, в течение которого будут существовать метки доменных имен, базирующиеся на IDNA2003. Для того чтобы облегчить переход для IDNA, агенты пользователя должны использовать IDNA2008 [RFC-5890], а могут использовать [RFC-5895] (смотри также раздел 7 [RFC-5894]) или [UTS46]. Если агент пользователя не работает с IDNA2008, он должен работать с IDNA2003.

14. Соображения безопасности

14.1. Базовые соображения о транспортной безопасности

Эта спецификация приспособлена для независимого безопасного транспорта HTTP. Однако, анализ угроз и требования в разделе 2 ("Overview") в действительности подразумевает TLS или SSL в качестве базового безопасного транспорта. Таким образом, использование HSTS в контексте HTTP, работающего поверх некоторых других транспортных протоколов потребует оценки модели безопасности этих протоколов в сочетании со спецификой того, как с ними взаимодействует HTTP.

14.2. Использование несовместимых агентов пользователя

Несовместимые агенты пользователя игнорируют поле заголовка Strict-Transport-Security; таким образом, к несовместимым агентам пользователя не имеют отношение угрозы, описанные в разделе 2.3.1 ("Threats Addressed").

Это означает, что web-приложение и их пользователи умеющие взаимодействовать с несовместимыми агентами пользователя, будут уязвимы перед лицом следующих угроз:

• Пассивные сетевые атаки, связанные с разработкой web-сайта и ошибками эксплуатации:

Например, если web-приложение содержит какие-то небезопасные ссылки (напр., "http") на сервер web-приложений, и если не все его куки помечены как безопасные, тогда его куки будут уязвимы для пассивной атаки прослушивания с последующим перехватом параметров доступа пользователя.

• Активные сетевые атаки:

Например, если атакер может позиционироваться как "человек-по-середине", попытки безопасного транспортного соединения вызовут предупреждения пользователю, но без требований политики HSTS, существующая практика позволяет пользователю "прокликать" и продолжить. Это открывает возможность для пользователя и для web-приложения подвергнуться атаке такого хакера.

Таково положение для всех web-приложений и их пользователей в отсутствии политики HSTS. Так как провайдеры web-приложений обычно не контролируют тип или версию агента пользователя и web-приложений, с которыми они взаимодействуют, в результате ясно, что создатели HSTS-компьютера должны проявлять такую же тщательность, чтобы избежать ошибок при разработке web-сайта (смотри раздел 2.3.1.3), какый бы они реализовали, в отсутствии политики HSTS.

14.3. Разветвления установления политики HSTS только для безопасных каналов без ошибок

Модель работы агента пользователя, описанная в разделе 8 ("User Agent Processing Model") предполагает, что компьютер в исходном состоянии помечен, как известный HSTS-компьютер, или, что выполнены обновления кэшированной информации, где указано что компьютер известен как HSTS-компьютер, только если агент пользователя получает поле заголовка STS через безопасное транспортное соединение, которое не имеет ошибок или предупреждений.

Обоснование этого заключается в том, что, если присутствует "человек-по-середине" (MITM) -- официально используемый прокси, или нелегальный объект -- он может вызвать различный ущерб (смотри также Приложение A ("Design Decision Notes") пункт 3, а также раздел 14.6 ("Bootstrap MITM Vulnerability")); например:

• Неавторизованное присвоение компьютеру значения известного HSTS-компьютера, потенциально ведет к ситуации отказа обслуживания, если компьютер предлагает свои сервисы непостоянно через безопасный канал (смотри также раздел 14.5 ("Denial of Service")).
• Сброс времени жизни для присвоения компьютеру названия известный HSTS-компьютер путем манипулирования агентом пользователя значением поля заголовка max-аge. Если значение max-age =0, то компьютер перестанет считаться агентом пользователя известным, приводя, либо к небезопасному соединению с компьютером, или возможно к отказу обслуживания, если компьютер предоставляет услуги только через безопасные каналы.

Однако, это означает, что, если агент пользователя находится за MITM непрозрачным TLS-прокси -- внутри корпоративного Интранет, и взаимодействует с неизвестным HSTS-компьютером, размещенным за прокси, пользователь может столкнуться с ошибкой безопасности соединения. Даже если риск приемлем и пользователь "прокликает" это состояние, компьютер не будет считаться HSTS-компьютером. Таким образом, пока агент пользователя находится за таким прокси, пользователь будет уязвим и столкнется с диалогом, сопряженным с ошибкой безопасности соединения для неизвестного HSTS-компьютера.

Раз агент пользователя установил соединение с неизвестным HSTS-компьютером через безопасный канал, не допускающий ошибок, компьютер будет помечен как известный HSTS-компьютер. Это вызовет неудачи для последующих попыток установления соединений для объектов позади прокси.

Выше приведенные рассуждения относятся к рекомендации в разделе 12 ("User Agent Implementation Advice"), так что безопасное соединение следует разорвать всякий раз при получении предупреждения или при ошибке, когда компьютер является известным HSTS-компьютером. Такое состояние защищает пользователей от "прокликивания" предупреждений безопасности и подвергания себя риску.

14.4. Необходимость includeSubDomains

Без директивы includeSubDomains web-приложение не сможет адекватно защитить так называемые "доменные куки" (даже если эти куки имеют флаг "Secure" и, таким образом, пересылаются только по безопасным каналам). Это куки, которые должны быть присланы агентом пользователя всем субдоменам web-приложения.

Например, предположим, что example.com представляет собой DNS-имя верхнего уровня для web-приложения. Далее, предположим, что это куки установлено для всего домена example.com, то-есть, это "доменное куки", и оно имеет флаг Secure=1. Предположим example.com является известным HSTS-компьютером для этого агента пользователя, но директива includeSubDomains не установлена.

Теперь, если атакер вынуждает агента пользователя направить запрос субдоменного имени, которое вряд ли имеется в web-приложении, например, "https://uxdhbpahpdsf.example.com/", но которое атакер ухитрился зарегистрировать в DNS и которое указывает на HTTP-сервер, управляемый атакером, то:

1. Агент пользователя вряд ли уже имеет установленную политику HSTS для "uxdhbpahpdsf.example.com".
2. HTTP-запрос, посланный uxdhbpahpdsf.example.com, будет включать куки домена, помеченное как безопасное.
3. Если "uxdhbpahpdsf.example.com" возвращает сертификат во время установления TLS, а пользователь "прокликивает" любое предупреждение, которое может присутствовать (это возможно, но не обязательно, может быть получен необходимый сертификат для такого доменного имени такой, что предупреждение может появиться, а может и нет), тогда атакер может получить доменное куки с флагом Secure, которое якобы защищено.

Без директивы "includeSubDomains", HSTS не может защитить доменное куки, помеченное как безопасное.

14.5. Отказ обслуживания

HSTS может использоваться для формирования определенных форм атак отказа обслуживания (DoS) против web-сайтов. DoS-атакой является такая атака, когда один или более сетевых объектов-мишеней не могут выполнять полезную работу. Смотри также [RFC-4732].

• Web-приложения доступные через HTTP

Имеется возможность для осуществления DoS-атак с web-приложениями (или критической частью их), которые доступны только через HTTP через небезопасный канал, если атакер может вынудить агента пользователя установить политику HSTS для компьютера такого web-приложения.

Это происходит потому, что раз политика HSTS установлена для машины web-приложения в агенте пользователя, агент пользователя будет использовать только безопасный канал для взаимодействия с этим компьютером. Если машина не использует безопасный канал или не использует его для критической доли своих web-приложений, тогда web-приложение будет считаться не реализуемым для агента пользователя.

Политика HSTS может быть определена для машины-жертвы различными способами:

• Если web-приложение содержит уязвимость расщепления HTTP-отклика [CWE-113] (которое может быть использовано, чтобы реализовать "HTTP header injection").
• Если атакер может фальсифицировать переадресацию с небезопасного сайта жертвы, напр., <http://example.com/> на <https://example.com/>, где последний сайт полностью контролируется атакером и имеет корректный сертификат. В этой ситуации, атакер может установить политику HSTS для example.com, а также для всех доменов example.com.
• Если атакер может убедить пользователей вручную сконфигурировать политику HSTS для машины-жертвы. Это предполагает, что агенты пользователя предлагают такую возможность (смотри раздел 12 ("User Agent Implementation Advice")). Напротив, если конфигурация агента пользователя реализуется с привлечением скрипта, тогда атакер может вынудить агента пользователя исполнить скрипт и установить HSTS-политики для каких угодно доменов.

• Непреднамеренное (некорректное) использование includeSubDomains

Директива includeSubDomains инструктирует агента пользователя связать автоматически все субдомены данного HSTS-компьютера в качестве известных HSTS-компьютеров. Если какие-то из этих субдоменов не поддерживают корректно сконфигурированные безопасные каналы, тогда для таких агентов пользователя они объявляются недостижимыми.

14.6. Уязвимость Bootstrap MITM (человек посередине)

Уязвимость начальной загрузки MITM (man-in-the-middle) является уязвимостью, с которой пользователи и HSTS-компьютеры сталкиваются в ситуации, где пользователь входит вручную или следует связи с неизвестным HSTS-компьютером, используя "http" URI, а не "https" URI. Так как агент пользователя использует небезопасный канал при начальной попытке связаться с определенным сервером, такое начальное взаимодействие является уязвимым для разнообразных атак (смотри раздел 5.3 [ForceHTTPS]).

Замечание: Существуют различные возможности, которые агент пользователя может использовать, для того чтобы ослабить эту уязвимость. Смотри раздел 12 ("User Agent Implementation Advice").

14.7. Атаки против сетевого времени

Активные сетевые атаки могут нарушать сетевые протоколы времени (такие как NTP (Network Time Protocol) [RFC-5905]) -- делая HSTS менее эффективным для клиентов, которые доверяют NTP. Заметим, что современные ОС используют NTP по-умолчанию. Смотри также раздел 2.10 [RFC-4732].

14.8. Поддельные корневые сертификаты и атаки с отравлением кэша DNS

Атакер может получить параметры доступа пользователя, принадлежащие web-приложению жертвы, защищенной HSTS через фальсифицированный корневой сертификат CA в сочетании с атакой отравления кэша DNS.

Например, атакер может сначала убедить пользователей web-приложения жертвы (которое защищено политикой HSTS), установить версию корневого CA-сертификата атакера имеющего целью ложно представлять СА web-приложения жертвы. Это может быть выполнено путем посылки пользователям фишинг-сообщения с таким сертификатом, который их браузеры могут предложить установить, если они были кликнуты.

Затем, если атакер может осуществить атаку на DNS-серверы пользователей, (напр., путем отравления кэша) и включить политику HSTS для своего фальшивого web-приложения, в результате браузеры пользователей воспримут web-приложение атакера вместо легального web-приложения.

Этот вид атаки использует векторы, которые находятся вне сферы ответственности HSTS. Однако, эффективность таких угроз может быть ослаблена путем включения в дополнение к HSTS, средств безопасности таких как расширение безопасности DNS [RFC-4033], плюс методик блокировки фишинга и ввода фальсифицированных сертификатов.

14.9. Креативное манипулирование запоминанием политики HSTS

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

14.10. Интернационализированные имена доменов

Интернет безопасность базируется отчасти на DNS. Доменные имена используют пользователями для идентификации и подключения к Интернет-компьютерам и другим сетевым ресурсам. Например, Интернет безопасность оказывается скомпрометированной, если пользователь вводящий интернациональное доменное имя (IDN) соединен с различными машинами, использующими разные интерпретации IDN.

Рассматриваемые модели обработки предполагают, что доменные имена, которыми они манипулируют, являются канонизированными IDNA, и что процесс канонизации корректно реализует все соответствующие валидации IDNA и Unicode (напр., как это отмечено в разделе 10 ("Domain Name IDNA-Canonicalization")). Эти шаги необходимы для того чтобы избежать различных потенциально компрометирующих ситуаций.

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

Кроме того, IDNA2008 [RFC-5890] отличается от IDNA2003 [RFC-3490] в терминах запрещенных символов и соответствия символов. Эта ситуация может также вести к ложно позитивной и/или ложно негативной идентификации доменных имен, что может привести, например, к тому, что пользователи могут обмениваться данными с непредусмотренными машинами или не иметь возможности связаться с нужными компьютерами.

16. Ссылки

16.1. Нормативные ссылки

16.2. Информационные ссылки

Приложение A. Устройство узлов принятия решений

В этом приложении рассмотрены документы для различных системных решений.

1. Куки не подходят для выражения политики HSTS, так как они являются переменными (из-за записи в агенте пользователя); следовательно, поле заголовка HTTP должно использоваться.
2. Мы решили не пытаться специфицировать то, как "mixed security context loads" (известный также как "mixed content loads") обрабатываются, из-за соображений реализации агента пользователя, а также из-за трудностей классификации.
3. HSTS-компьютер может обновить нотации политики HSTS агента пользователя с помощью значений поля заголовка HSTS. Мы выбираем вариант, когда агенты пользователя получают самую свежую информацию от сервера, так как имеется шанс для web-сайта послать некорректную политику HSTS, такую как многолетнее значение max-age, и/или некорректную директиву includeSubDomains. Если HSTS-компьютер не может скорректировать эти ошибки в рамках протокола, это потребует некоторого вмешательства в пользовательскую часть программы, которое может оказаться нетривиальной проблемой для провайдеров web-приложения и их пользователей.
4. HSTS-компьютеры идентифицируются с помощью доменных имен -- идентификация по IP-адресам в любой форме исключена. Это сделано для простоты, а также для распознавания различных проблем при использовании прямой идентификации по IP-адресу в концепции безопасности, основанной на PKI.
5. Подход max-age, когда HSTS-компьютер предоставляет простое целое число секунд для времени жизни кэшированной политики HSTS, в отличие от подхода с абсолютныи моментом истечения пригодности в будущем, был выбран по разным причинам. Среди причин можно назвать отсутствие необходимости синхронизации часов, отсутствие требования определения синтаксиса даты и времени (простота спецификации), и простота реализации.
6. При выборе привязки портов, рассматривается опция полного отказа разыменования любых URL с портом. Создается ощущение, что возможность разыменования URI не является корректной.

Приложение B. Отличия обычной политики и политики HSTS

Политика HSTS имеет следующие исходные характеристики:

Политика HSTS обуславливает требования для характеристик соединения агента пользователя и компьютера.

Компьютеры декларируют политику HSTS агентам пользователя. Стандартные агенты пользователя обязаны выполнять объявленную компьютером HSTS-политику.

Политика HSTS передается через протокол от компьютера к агенту пользователя.

Агент пользователя поддерживает кэш известных HSTS-компьютеров.

Агенты пользователя применяют политику HSTS всякий раз, осуществляя HTTP-соединение с известным HSTS-компьютером, вне зависимости от номера порта; то-есть, политика применяется ко всем портам известного HSTS-компьютера. Компьютеры не могут влиять на этот аспект политики HSTS.

Компьютеры могут опционно декларировать, что их политика HSTS относится ко всем субдоменам доменного имени компьютера.

Напротив, Same-Origin Policy (SOP - правило ограничения домена) [RFC-6454] имеет следующие базовые характеристики:

Источником (отправителем) может являться схема, компьютер и порт URI, идентифицирующий ресурс.

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

SOP относится к совокупности принципов, используемых в агентах пользователя, и управляющих изоляцией и коммуникациями между представлениями ресурса для данного агента пользователя, а также доступом представлений ресурса в отношении сетевых ресурсов.

Таким образом, хотя как политика HSTS, так и SOP задаются агентами пользователя, политика HSTS опционно декларируется компьютерами и не базируется на источнике (не origin-based), в то время как SOP приложима ко всем ресурсам, загруженным со всех компьютеров стандартными агентами пользователя.

Previous: 4.5.6.3 Балансировка нагрузки серверов    UP: 4.5.6 WWW     Next: 4.5.6.5 Протокол HTTP/2 (RFC-7540, Hypertext Transfer Protocol Version 2 (M. Belshe, R. Peon, M. Thomson, Ed.)