RFC 6797 | Строгая транспортная безопасность HTTP (HSTS)

Аннотация

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

Скачать оригинальный документ на английском языке RFC 6797 PDF

 

Оглавление

1. Введение
1.1. Организация этой спецификации
1.2. Соглашения о документе
2. Обзор
2.1. Случаи применения
2.2. Строгий транспортный эффект безопасности HTTP
2.3. Модель угрозы
2.3.1. Обращенные угрозы
2.3.1.1. Пассивные сетевые злоумышленники
2.3.1.2. Активные сетевые злоумышленники
2.3.1.3. Ошибки разработки и развертывания веб-сайтов
2.3.2. Угрозы не устранены
2.3.2.1. Фишинг
2.3.2.2. Уязвимости в вредоносных программах и браузерах
2.4. Требования
2.4.1. Общее требование
2.4.1.1. Подробные основные требования
2.4.1.2. Подробные вспомогательные требования
3. Критерии соответствия
4. Терминология
5. Обзор механизма HSTS
5.1. Декларация принимающей стороны HSTS
5.2. Политика HSTS
5.3. Хранение и обслуживание политик HSTS агентами пользователей
5.4. Агент пользователя HSTS Политика применения
6. Синтаксис
6.1. Поле заголовка ответа HTTP Strict-Transport-Security
6.1.1. Директива max-age
6.1.2. Директива includeSubDomains
6.2. Примеры
7. Модель обработки сервера
7.1. Тип запроса HTTP-over-Secure-Transport
7.2. Тип запроса HTTP
8. Модель обработки агента пользователя
8.1. Обработка поля заголовка ответа Strict-Transport-Security
8.1.1. Запись узла HSTS — модель хранилища
8.2. Известное соответствие имени домена хоста HSTS
8.3. Загрузка URI и сопоставление портов
8.4. Ошибки в безопасном транспортном учреждении
8.5. HTTP-Equiv <Meta> Элемент Атрибут
8.6. Отсутствует поле заголовка ответа Strict-Transport-Security
9. Построение эффективного URI запроса
9.1. Основные определения ERU
9.2. Определение эффективного URI запроса
9.2.1. Примеры эффективного URI запроса
10. Доменное имя IDNA-канонизация
11. Рекомендации по внедрению и развертыванию сервера
11.1. Несоответствующие соображения агента пользователя
11.2. Время истечения срока действия политики HSTS
11.3. Использование HSTS в сочетании с само-подписанными сертификатами открытых ключей
11.4. Последствия includeSubDomains
11.4.1. Особенности предложения незащищенных HTTP-сервисов на альтернативных портах или поддоменах хоста HSTS
11.4.2. Рекомендации по предложению веб-приложений на поддоменах хоста HSTS
12. Рекомендации по внедрению агента пользователя
12.1. Нет ресурсов пользователя
12.2. Заявленная пользователем политика HSTS
12.3. Предварительно загруженный список HSTS
12.4. Запретить загрузку смешанного контекста безопасности
12.5. Удаление политики HSTS
13. Интернационализированные доменные имена для приложений (IDNA): зависимость и миграция
14. Вопросы безопасности
14.1. Основные соображения безопасного транспорта
14.2. Неподходящие последствия для агента пользователя
14.3. Последствия установления политики HSTS только через безошибочный безопасный транспорт
14.4. Необходимость включения доменов
14.5. Отказ в обслуживании
14.6. Уязвимость Bootstrap MITM
14.7. Сетевые временные атаки
14.8. Поддельный корневой сертификат CA Атака на фиш с DNS-кешем
14.9. Креативное управление хранилищем политик HSTS
14.10. Интернационализированные доменные имена
15. Соображения IANA
16. Ссылки
16.1. Нормативные ссылки
16.2. Информационные ссылки
Приложение А. Примечания к проектному решению
Приложение B. Различия между политикой HSTS и политикой того же происхождения
Приложение C. Благодарности

 

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественную рецензию и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 5741.

Информацию о текущем статусе этого документа, любых ошибках и о том, как предоставить отзыв о нем, можно получить по адресу http://www.rfc-editor.org/info/rfc6797.

 

Уведомление об авторских правах

Copyright (c) 2012 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ППГ 78 и Правовые положения IETF Trust, касающиеся документов IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны содержать текст Упрощенной лицензии BSD, как описано в Разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в Упрощенной лицензии BSD.

 

1. Введение

HTTP [RFC2616] может использоваться для различных транспортов, обычно протокола управления передачей (TCP). Однако TCP не обеспечивает защиту целостности канала, конфиденциальность или безопасную идентификацию хоста. Таким образом, протокол Secure Sockets Layer (SSL) [RFC6101] и его преемник, Transport Layer Security (TLS) [RFC5246] были разработаны для обеспечения канальной безопасности и, как правило, распределены между прикладными протоколами и TCP. [RFC2818] определяет, как HTTP наслоен на TLS, и определяет схему «https» для универсального идентификатора ресурса (URI) (на практике, однако, пользовательские агенты HTTP (UA) обычно используют либо TLS, либо SSL3, в зависимости от сочетания согласования с сервер и пользовательские настройки).

Агенты UA используют различные локальные политики безопасности в отношении характеристик своего взаимодействия с веб-ресурсами, в зависимости от (частично) того, осуществляют ли они связь с хостом данного веб-ресурса с использованием HTTP или HTTP-over-Secure-Transport. Например, куки ([RFC6265]) могут быть помечены как безопасные. UA должны отправлять такие безопасные куки-файлы своему адресуемому хосту только через безопасный транспорт. Это отличается от небезопасных файлов cookie, которые возвращаются хосту независимо от транспорта (хотя и подчиняются другим правилам).

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

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

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

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

Эта спецификация также включает в себя понятия из [JacksonBarth2008] в том смысле, что политика применяется на основе «всего хоста»: она применяется к HTTP (только) через любой порт TCP хоста-эмитента.

Обратите внимание, что политика, определенная в этой спецификации, явно отличается от «политики того же происхождения», определенной в «Концепции веб-происхождения» [RFC6454]. Эти различия суммированы в Приложении B.

 

1.1. Организация этой спецификации

Эта спецификация начинается с обзора вариантов использования, эффектов политики, моделей угроз и требований для HSTS (в Разделе 2). Затем в разделе 3 определяются требования к соответствию. Раздел 4 определяет терминологию, относящуюся к этому документу. Сам механизм HSTS формально указан в разделах с 5 по 15.

 

1.2. Соглашения о документе

ПРИМЕЧАНИЕ. Это примечание для читателя. Это моменты, которые следует четко учитывать и / или учитывать.

 

2. Обзор

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

2.1. Случаи применения

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

o Пользователь веб-браузера хочет защищенным образом взаимодействовать с различными веб-сайтами (некоторые произвольные, некоторые известные).
o Разработчик веб-сайта хочет предложить свой сайт в явно защищенной форме для своей выгоды, а также для пользы своих пользователей.

2.2. Строгий транспортный эффект безопасности HTTP

Эффекты Политики HSTS, применяемой совместимым UA при взаимодействии с хостом веб-ресурса, использующим такую политику (известный как Хост HSTS), суммируются следующим образом:

1. UA преобразуют небезопасные ссылки URI на хост HSTS в защищенные ссылки URI перед их разыменованием.
2. Агент UA прекращает любые попытки безопасного транспортного соединения при любых и всех безопасных транспортных ошибках или предупреждениях.

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

HSTS занимается тремя классами угроз: пассивными сетевыми злоумышленниками, активными сетевыми злоумышленниками и несовершенными веб-разработчиками. Однако это явно не средство против двух других классов угроз: фишинга и вредоносных программ. Рассматриваемые угрозы, а также угрозы, которые не рассматриваются, кратко обсуждаются ниже.

Читатели могут обратиться к Разделу 2 [ForceHTTPS] за подробностями, а также соответствующими цитатами.

2.3.1. Обращенные угрозы

2.3.1.1. Пассивные сетевые злоумышленники

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

Чтобы смягчить такие угрозы, некоторые веб-сайты поддерживают, но обычно не принудительно, доступ с использованием сквозного безопасного транспорта — например, сигнализируемого через URI, построенные по схеме «https» [RFC2818]. Это может заставить пользователей поверить, что доступ к таким службам с использованием безопасного транспорта защищает их от атак пассивной сети. К сожалению, это часто не так в реальных развертываниях, так как идентификаторы сеансов часто хранятся в небезопасных файлах cookie, чтобы обеспечить возможность взаимодействия с версиями службы, предлагаемой через незащищенный транспорт («Безопасные файлы cookie» — это файлы cookie, содержащие «Безопасный»). атрибут [RFC6265]). Например, если идентификатор сеанса для веб-сайта (скажем, службы электронной почты) хранится в незащищенном файле cookie, он позволяет злоумышленнику перехватить сеанс пользователя, если пользовательский агент пользователя отправляет на сайт один небезопасный HTTP-запрос.

2.3.1.2. Активные сетевые злоумышленники

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

2.3.1.3. Ошибки разработки и развертывания веб-сайтов

Безопасность в противном случае равномерно защищенного сайта (т. Е. Весь его контент материализуется через URI «https») может быть полностью скомпрометирован активным злоумышленником, который использует простую ошибку, такую ​​как загрузка каскадной таблицы стилей или SWF (Shockwave). Flash) по небезопасному соединению (и каскадные таблицы стилей, и фильмы SWF могут удивить многих пользователей веб-страниц сценарием встраивания, плюс некоторые браузеры не выдают так называемые «предупреждения о смешанном содержимом», когда SWF-файлы внедряются через небезопасные соединения). Даже если разработчики сайта тщательно изучают свою страницу входа на предмет «смешанного контента», одиночное небезопасное встраивание в любое место на общем сайте ставит под угрозу безопасность их страницы входа, потому что злоумышленник может выполнить сценарий (то есть контролировать) страницу входа, введя код (например, скрипт) на другую, небезопасно загруженную страницу сайта.

ПРИМЕЧАНИЕ. «Смешанный контент», используемый выше (см. Также раздел 5.3 в [W3C.REC-wsc-ui-20100812]), относится к понятию «смешанный контекст безопасности» в этой спецификации и его не следует путать с тем же «смешанным». «контент» термин, используемый в контексте языков разметки, таких как XML и HTML.

2.3.2. Угрозы не устранены

2.3.2.1. Фишинг

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

2.3.2.2. Уязвимости в вредоносных программах и браузерах

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

 

2.4. Требования

В этом разделе определяются и перечисляются различные требования, вытекающие из описанных выше вариантов использования и угроз, а также перечисляются подробные основные требования, которые адресованы HTTP Strict Transport Security, а также вспомогательные требования, которые непосредственно не рассматриваются.

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

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

2.4.1.1. Подробные основные требования

Эти основные требования вытекают из общего требования и рассматриваются в этой спецификации.

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

2. Веб-сайты должны быть в состоянии проинструктировать UA, которые небезопасно связываются с ними, делать это безопасно.

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

4. UA должны переписать все незащищенные загрузки URI «http» UA, чтобы использовать безопасную схему «https» для тех веб-сайтов, для которых включена безопасная политика.

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

Например, как 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 («Нет обращения к пользователю»).

ПРИМЕЧАНИЕ: средство для равномерного безопасного удовлетворения первого основного требования, указанного выше, конкретно не рассматривается в данной спецификации (см. Раздел 14.6 («Уязвимость Bootstrap MITM»)). Это может быть решено в будущем пересмотре этой спецификации или какой-либо другой спецификации. Отметим также, что существуют средства, с помощью которых реализации UA могут более полно соответствовать первому основному требованию; см. Раздел 12 («Рекомендации по внедрению пользовательского агента»).

2.4.1.2. Подробные вспомогательные требования

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

1. Запретить загрузки «смешанного контекста безопасности» (см. Раздел 2.3.1.3).

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

 

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

Эта спецификация написана для хостов и пользовательских агентов.

Соответствующий хост — это тот, который реализует все требования, перечисленные в этой спецификации, которые применимы к хостам.

Соответствующий пользовательский агент — это тот, который реализует все требования, перечисленные в этой спецификации, которые применимы к пользовательским агентам.

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].

 

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

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

Сравнение ASCII без учета регистра:
означает точное сравнение двух строк, кодовой точки для кодовой точки, за исключением того, что символы в диапазоне U + 0041 .. U + 005A (т.е. LATIN CAPITAL LETTER A — LATIN CAPITAL LETTER Z) и соответствующие символы в диапазоне U + 0061 .. U + 007A (т. Е. От LATIN SMALL LETTER A до LATIN SMALL LETTER Z) также считаются совпадающими. Смотрите [Unicode] для деталей.

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

доменное имя (domain name):
также называется «DNS-именем» и определено в [RFC1035] для представления вне самого протокола DNS (и его реализаций) в виде серии меток, разделенных точками, например, «example.com» или «пока». another.example.org». В контексте данной спецификации доменные имена появляются в той части URI, которая удовлетворяет правилам создания reg-name в «Приложении A. Собранный ABNF для URI» в [RFC3986], и компоненту хоста из получения поля заголовка HTTP узла в разделе 14.23 из [RFC2616].

ПРИМЕЧАНИЕ. Доменные имена, встречающиеся в реальных экземплярах URI и соответствующие вышеупомянутым производственным компонентам, могут быть или не быть полностью квалифицированным доменным именем.

метка доменного имени (domain name label):
является той частью доменного имени, которая появляется «между точками», то есть рассмотрим «foo.example.com»: «foo», «example» и «com» — все метки доменного имени.

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

HTTP Строгая Транспортная Безопасность (HTTP Strict Transport Security):
это общее имя для объединенной политики безопасности на стороне UA и сервера, определенной в этой спецификации.

Хост строгой транспортной безопасности HTTP (HTTP Strict Transport Security Host):
является совместимым хостом, реализующим HTTP-аспекты политики HSTS. Это означает, что узел HSTS возвращает поле заголовка ответа HTTP «Strict-Transport-Security» в своих ответных сообщениях HTTP, отправляемых по защищенному транспорту.

Строгая политика безопасности транспорта HTTP (HTTP Strict Transport Security Policy):
имя объединенного общего UA- и серверного аспектов поведения, определенного в данной спецификации.

HSTS:
См. HTTP Strict Transport Security.

Хост HSTS:
См. HTTP-сервер строгой безопасности транспорта.

Политика HSTS:
См. HTTP Strict Transport Security Policy.

Известный хост HSTS:
является хостом HSTS, для которого UA имеет действующую политику HSTS; то есть UA отметил этот хост как известный хост HSTS. Подробности см. В разделе 8.1.1 («Замечание о HSTS Host — Storage Model»).

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

MITM:
это сокращение от «человек посередине». См. «Атака человека посередине» в [RFC4949].

URI запроса:
URI, используемый для того, чтобы агент UA выдал сообщение HTTP-запроса. Смотрите также «Эффективный URI запроса».

UA:
это аббревиатура от «пользовательский агент». Для целей данной спецификации UA — это клиентское приложение HTTP, обычно активно управляемое пользователем [RFC2616].

неизвестный хост HSTS:
хост HSTS, которого пользовательский агент не заметил

 

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

В этом разделе представлен обзор механизма, с помощью которого хост HSTS передает свою политику HSTS агентам UA и как UA обрабатывают политики HSTS, полученные от хостов HSTS. Детали механизма указаны в разделах с 6 по 15.

5.1. Декларация принимающей стороны HSTS

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

5.2. Политика HSTS

Политика HSTS предписывает агентам UA взаимодействовать с известным хостом HSTS только по защищенному транспорту и указывает продолжительность времени хранения политики.

Политика HSTS явно переопределяет обработку UA ссылок URI, пользовательский ввод (например, через «адресную строку») или другую информацию, которая в отсутствие политики HSTS могла бы иначе заставить небезопасную связь UA с известным хостом HSTS.

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

5.3. Хранение и обслуживание политик HSTS агентами пользователей

UA хранят и индексируют Политики HSTS, основанные строго на доменных именах хостов, выдающих HSTS.

Это означает, что UA будут поддерживать Политику HSTS любого данного хоста HSTS отдельно от любых политик HSTS, выпущенных любыми другими хостами HSTS, чьи доменные имена являются супердоменами или поддоменами доменного имени данного хоста HSTS. Только данный хост HSTS может обновлять или может вызвать удаление своей выданной политики HSTS. Это достигается путем отправки полей заголовка HTTP-ответа Strict-Transport-Security агентам UA с новыми значениями продолжительности политики и применимости поддоменов. Таким образом, UA кэшируют «самую свежую» информацию о политике HSTS от имени хоста HSTS. Указание нулевой длительности сигнализирует UA об удалении политики HSTS (включая любую утвержденную директиву includeSubDomains) для этого хоста HSTS. Подробнее см. В разделе 8.1 («Обработка поля заголовка ответа Strict-Transport-Security»). Кроме того, в разделе 6.2 представлены примеры полей заголовка ответа HTTP Strict-Transport-Security.

5.4. Агент пользователя HSTS Политика применения

При установлении соединения HTTP с данным хостом, каким бы спровоцированным он ни был, UA проверяет свой кэш известных хостов HSTS, чтобы определить, есть ли какие-либо с доменными именами, которые являются супердоменами доменного имени данного хоста. Если они найдены, и из них, если таковые имеются, утверждена директива includeSubDomains, то политика HSTS применяется к данному хосту. В противном случае политика HSTS применяется к данному хосту, только если данный хост сам известен UA как хост HSTS. См. Раздел 8.3 («Загрузка URI и сопоставление портов») для получения подробной информации.

 

6. Синтаксис

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

Затем в разделе 7 («Модель обработки сервера») подробно описано, как хосты используют это поле заголовка для объявления своей политики HSTS, а в разделе 8 («Модель обработки агента пользователя») подробно описано, как пользовательские агенты обрабатывают поле заголовка и применяют политику HSTS.

6.1. Поле заголовка ответа HTTP Strict-Transport-Security

Поле заголовка ответа HTTP Strict-Transport-Security (поле заголовка STS) указывает агенту UA, что он ДОЛЖЕН применять Политику HSTS в отношении хоста, отправляющего ответное сообщение, содержащее это поле заголовка.

Синтаксис ABNF (расширенная форма Бэкуса-Наура) для поля заголовка STS приведен ниже. Он основан на Общей грамматике, определенной в Разделе 2 [RFC2616] (которая включает понятие «подразумеваемый линейный пробел», также известный как «подразумеваемый * LWS»).

Strict-Transport-Security = «Strict-Transport-Security» «:»
[ directive ] *( «;» [ directive ] )
directive = directive-name [ «=» directive-value ]
directive-name = token
directive-value = token | quoted-string

где:

token = <токен, определенный в [RFC2616], раздел 2.2>

quoted-string = <цитата-строка, определенная в [RFC2616], раздел 2.2>

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

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

Дополнительные директивы, расширяющие семантическую функциональность поля заголовка STS, могут быть определены в других спецификациях, причем для них в это время определен реестр (имеющий определение политики IANA в IETF Review [RFC5226]).

ПРИМЕЧАНИЕ. Такие будущие директивы будут игнорироваться агентами UA, реализующими только эту спецификацию, а также обычно несоответствующими агентами UA. См. Раздел 14.2 («Несоответствующие последствия для агента пользователя») для дальнейшего обсуждения.

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

ТРЕБУЕМАЯ директива «max-age» указывает количество секунд после приема поля заголовка STS, в течение которого агент UA рассматривает хост (от которого было получено сообщение) как известный хост HSTS. См. Также Раздел 8.1.1 («Замечание о HSTS Host — Storage Model»). Производство дельта-секунд указано в [RFC2616].

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

max-age-value = дельта-секунды
delta-seconds = <1 * DIGIT, определено в [RFC2616], раздел 3.3.2>

ПРИМЕЧАНИЕ. Значение max-age, равное нулю (т. Е. «Max-age = 0»), сигнализирует UA о прекращении рассмотрения хоста в качестве известного хоста HSTS, включая директиву includeSubDomains (если заявлено для этого хоста HSTS). См. Также Раздел 8.1 («Обработка поля заголовка ответа Strict-Transport-Security»).

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

НЕОБЯЗАТЕЛЬНАЯ директива includeSubDomains — это бесполезная директива, которая, если она существует (то есть она «утверждена»), сигнализирует UA о том, что политика HSTS применяется к этому хосту HSTS, а также к любым поддоменам доменного имени хоста.

6.2. Примеры

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

Strict-Transport-Security: max-age=31536000

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

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

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

Strict-Transport-Security: max-age=»31536000″

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

Strict-Transport-Security: max-age=0

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

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

 

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

В этом разделе описывается модель обработки, которую реализуют HSTS Hosts. Модель состоит из двух аспектов: первый — это правила обработки сообщений HTTP-запросов, полученных по защищенному транспорту (TLS [RFC5246] или SSL [RFC6101]; см. Также раздел 14.1 («Основные соображения безопасного транспорта»)), а второй — правила обработки сообщений HTTP-запросов, полученных через незащищенные транспорты, такие как TCP.

7.1. Тип запроса HTTP-over-Secure-Transport

При ответе на запрос HTTP, который был передан по защищенному транспорту, хосту HSTS СЛЕДУЕТ включить в свое ответное сообщение поле заголовка STS, которое ДОЛЖНО соответствовать грамматике, указанной выше в разделе 6.1 («Поле заголовка ответа HTTP Strict-Transport-Security») , Если поле заголовка STS включено, хост HSTS ДОЛЖЕН включать только одно такое поле заголовка.

Установление данного хоста в качестве известного хоста HSTS в контексте данного UA МОЖЕТ быть выполнено по HTTP, который, в свою очередь, работает по защищенному транспорту, путем правильного возврата (согласно этой спецификации) по меньшей мере одного действительного поля заголовка STS в UA. МОГУТ также использоваться другие механизмы, такие как предварительно загруженный список известных хостов HSTS на стороне клиента; например, см. Раздел 12 («Рекомендации по внедрению пользовательского агента»).

ПРИМЕЧАНИЕ. Включение поля заголовка STS указано как «СЛЕДУЕТ» для размещения различных кэшей на стороне сервера и сети и конфигураций балансировки нагрузки, где может быть затруднительно равномерно генерировать поля заголовка STS от имени данного хоста HSTS.

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

Если узел HSTS получает сообщение HTTP-запроса по незащищенному транспортному средству, он ДОЛЖЕН отправить ответное сообщение HTTP, содержащее код состояния, указывающий на постоянное перенаправление, такое как код состояния 301 (раздел 10.3.2 из [RFC2616]), и Значение поля заголовка местоположения, содержащее либо исходный URI эффективного запроса HTTP-запроса (см. Раздел 9 («Создание URI действующего запроса»)), измененное при необходимости, чтобы иметь схему URI «https», либо URI, сгенерированный в соответствии с локальной политикой с Схема URI «https».

ПРИМЕЧАНИЕ. Вышеуказанное поведение является «ДОЛЖНЫМ», а не «ДОЛЖНЫМ» из-за:

* Риски при перенаправлении с небезопасных на защищенные стороны сервера [OWASP-TLSGuide].

* Характеристики развертывания сайта. Например, сайт, который включает сторонние компоненты, может работать некорректно при выполнении перенаправлений с небезопасной на защищенную сторону на стороне сервера в случае доступа через незащищенный транспорт, но при правильном доступе при равномерном доступе через безопасный транспорт может работать правильно.

В последнем случае используется UA с поддержкой HSTS, который уже отметил сайт как известный хост HSTS (какими бы то ни было средствами, например, перед взаимодействием или конфигурацией UA).

Хост HSTS НЕ ДОЛЖЕН включать поле заголовка STS в ответы HTTP, передаваемые по незащищенному транспорту.

 

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

В этом разделе описывается модель обработки HTTP Strict Transport Security для UA. У модели есть несколько аспектов, перечисленных в следующих подразделах.

Эта модель обработки предполагает, что UA реализует IDNA2008 [RFC5890] или, возможно, IDNA2003 [RFC3490], как отмечено в разделе 13 («Интернационализированные доменные имена для приложений (IDNA): зависимость и миграция»). Также предполагается, что все доменные имена, с которыми манипулируют в контексте данной спецификации, уже канонизированы IDNA, как описано в Разделе 10 («Идентификация канонизации доменных имен») до обработки, указанной в этом разделе.

ПРИМЕЧАНИЕ. Ссылка на [RFC3490] связана с его текущей актуальностью для фактических развертываний в обозримом будущем.

Приведенные выше допущения означают, что эта модель обработки также конкретно предполагает, что соответствующие проверки IDNA и Unicode и тестирование списка символов выполнялись для доменных имен в сочетании с их IDNA-канонизацией до обработки, указанной в этом разделе. См. Специфические для IDNA соображения безопасности в Разделе 14.10 («Интернационализированные доменные имена») для обоснования и дополнительных деталей.

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

Если ответ HTTP, полученный по защищенному транспорту, включает поле заголовка STS, соответствующее грамматике, указанной в разделе 6.1 («Поле заголовка ответа HTTP Strict-Transport-Security»), и нет никаких ошибок или предупреждений безопасного транспорта ( см. раздел 8.4), UA ДОЛЖЕН также:

o Отметьте хост как известный хост HSTS, если он еще не отмечен (см. раздел 8.1.1 («Замечание о хосте HSTS — модель хранилища»)),
или же

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

Значение максимального возраста по существу является значением времени жизни относительно времени приема поля заголовка STS.

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

Если агент UA получает более одного поля заголовка STS в ответном сообщении HTTP по защищенному транспорту, агент UA ДОЛЖЕН обработать только первое такое поле заголовка.

Иначе:

o Если HTTP-ответ получен по небезопасной транспортировке, UA ДОЛЖЕН игнорировать любые существующие поля заголовка STS.

o UA ДОЛЖЕН игнорировать любые поля заголовка STS, не соответствующие грамматике, указанной в разделе 6.1 («Поле заголовка ответа HTTP Strict-Transport-Security»).

8.1.1. Запись узла HSTS — модель хранилища

Если подстрока, соответствующая продукции хоста из Request-URI (сообщения, на которое ответил хост), синтаксически совпадает с продукцией IP-литерала или IPv4-адреса из Раздела 3.2.2 [RFC3986], то UA НЕ ДОЛЖЕН отмечать этот хост как Известный хост HSTS.

В противном случае, если подстрока не совпадает совпадает с именем домена известного хоста HSTS в соответствии с процедурой сопоставления, указанной в разделе 8.2 («Сопоставление имен доменов известного хоста HSTS»), то UA ДОЛЖЕН отметить этот хост как известный хост HSTS, кэшируя Доменное имя хоста HSTS и, вместе с ним, время истечения срока действия этой информации, которое эффективно определяется для данного максимального значения, а также указывается, указана ли директива includeSubDomains или нет. См. Также раздел 11.2 («Вопросы времени истечения срока действия политики HSTS»).

UA НЕ ДОЛЖЕН изменять время истечения срока действия или директиву includeSubDomains для любого известного хоста HSTS, соответствующего супердомену.

Известный хост HSTS «просрочен», если его запись в кэше имеет дату истечения в прошлом. UA ДОЛЖЕН изгнать из своего кеша все известные HSTS-хосты с истекшим сроком действия, если в любой момент в кеше существует известный HSTS-хост с истекшим сроком действия.

8.2. Известное соответствие имени домена хоста HSTS

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

Шаги ниже определяют, есть ли какие-либо совпадения, и если да, то каким образом:

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

* Superdomain Match

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

Например:

Given domain name (DN): qaz.bar.foo.example.com
Superdomain matched Known HSTS Host DN: bar.foo.example.com
Superdomain matched Known HSTS Host DN: foo.example.com

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

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

Например:

Given domain name: foo.example.com
Congruently matched Known HSTS Host DN: foo.example.com

* В противном случае, если совпадений не найдено, данное доменное имя не представляет известный хост HSTS.

8.3. Загрузка URI и сопоставление портов

Всякий раз, когда агент UA готовится «загрузить» (также известный как «разыменование») любой «http» URI [RFC3986] (в том числе при выполнении HTTP-перенаправлений [RFC2616]), агент UA должен сначала определить, задано ли имя домена в URI, и соответствует ли он Известному хосту HSTS, используя эти шаги:

1. Извлеките из URI любую подстроку, описанную компонентом хоста компонента полномочий URI.

2. Если подстрока пуста, то нет совпадений ни с одним известным хостом HSTS.

3. Иначе, если подстрока не равна нулю и синтаксически совпадает с продукцией IP-литерала или IPv4-адреса из Раздела 3.2.2 [RFC3986], то нет совпадения ни с одним известным хостом HSTS.

4. В противном случае подстрока — это заданное доменное имя, которое ДОЛЖНО сопоставляться с известными хостами HSTS UA, используя процедуру, описанную в разделе 8.2 («Сопоставление известных имен доменов хоста HSTS»).

5. Если при выполнении сопоставления имени домена обнаруживается какое-либо совпадение супердомена с утвержденной директивой includeSubDomains, или если супердомен не совпадает с утвержденными директивами includeSubDomains и найдено конгруэнтное совпадение (с утвержденной директивой includeSubDomains или без нее), то перед исходя из нагрузки:

UA ДОЛЖЕН заменить схему URI на «https» [RFC2818], и
если URI содержит явный компонент порта «80», то UA ДОЛЖЕН преобразовать компонент порта в «443», или
если URI содержит явный компонент порта, который не равен «80», значение компонента порта ДОЛЖНО быть сохранено; иначе,
если URI не содержит явного компонента порта, UA НЕ ДОЛЖЕН добавлять его.
ПРИМЕЧАНИЕ. Эти шаги гарантируют, что политика HSTS применяется к HTTP через любой порт TCP хоста HSTS.

ПРИМЕЧАНИЕ. В случае, если указан явный порт (и в меньшей степени с поддоменами), вполне вероятно, что на указанном порту работает HTTP-сервер (т. Е. Незащищенный) и что запрос HTTPS будет таким образом, происходит сбой (см. пункт 6 в Приложении A («Примечания к решению по проекту»))

8.4. Ошибки в безопасном транспортном учреждении

При подключении к известному хосту HSTS агент UA ДОЛЖЕН разорвать соединение (см. Также раздел 12 («Рекомендации по реализации пользовательского агента»)), если есть какие-либо ошибки, будь то «предупреждение», «фатальная» или любой другой уровень ошибки, с базовый безопасный транспорт. Например, это включает любые ошибки, обнаруженные при проверке достоверности сертификата, которую используют UA, например, через списки отзыва сертификатов (CRL) [RFC5280] или через сетевой протокол статуса сертификата (OCSP) [RFC2560], а также через идентификацию сервера TLS. проверка [RFC6125].

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

Агенты UA НЕ ДОЛЖНЫ учитывать параметры атрибута http-equ = «Strict-Transport-Security» для элементов <meta> [W3C.REC-html401-19991224] в полученном контенте.

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

Если UA получает ответы HTTP от известного хоста HSTS по безопасному каналу, но в ответах отсутствует поле заголовка STS, агент UA ДОЛЖЕН продолжать обрабатывать хост как известный хост HSTS до достижения максимального значения возраста для знания этого известного Хост HSTS достигнут. Обратите внимание, что значение максимального возраста может быть фактически бесконечным для данного известного хоста HSTS. Например, это может быть в том случае, если известный узел HSTS является частью предварительно настроенного списка, который реализован так, что записи списка никогда не «устаревают».

 

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

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

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

9.1. Основные определения ERU

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

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

Request-URI в строке запроса определяется следующим ABNF из [RFC2616], раздел 5.1.2:

Request-URI = «*» | absoluteURI | abs_path | authority

Поле заголовка запроса хоста определяется следующей ABNF из [RFC2616], раздел 14.23:

Host = «Host» «:» host [ «:» port ]

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

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

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

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

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

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

Эффективные URI запроса сравниваются с использованием правил, описанных в разделе 3.2.3 [RFC2616], за исключением того, что пустые компоненты пути НЕ ДОЛЖНЫ рассматриваться как эквивалент абсолютного пути «/».

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

(получено по защищенному соединению TCP / SSL): «https», плюс «: //», плюс компонент полномочий «www.example.org». Таким образом, это «https://www.example.org».

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

IDNA-канонизированное имя домена — это выходная строка, сгенерированная следующими шагами. Входные данные являются предполагаемой строкой доменного имени, якобы составленной из любой комбинации «A-меток», «U-меток» и «NR-LDH меток» (см. Раздел 2 [RFC5890]), конкатенированных с использованием некоторого символа-разделителя (обычно « «.).

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

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

В противном случае при реализации IDNA2003 преобразуйте каждую метку, используя преобразование «ToASCII» в Разделе 4 [RFC3490] (см. Также определение «эквивалентности меток» в Разделе 2 в [RFC3490]).

3. Если в ходе предыдущего шага не было ошибок, объедините все метки в последовательности по порядку в строку, отделяя каждую метку от следующей с помощью символа% x2E («.»). Результирующая строка, известная как IDNA-канонизированное доменное имя, подходит для использования в контексте Раздела 8 («Модель обработки агента пользователя»).

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

См. Также разделы 13 («Интернационализированные доменные имена для приложений (IDNA): зависимость и миграция») и 14.10 («Интернационализированные доменные имена») этой спецификации для получения более подробной информации и соображений.

11. Рекомендации по внедрению и развертыванию сервера

Этот раздел не является нормативным.

11.1. Несоответствующие соображения агента пользователя

Несоответствующие UA игнорируют поле заголовка Strict-Transport-Security; таким образом, несовместимые пользовательские агенты не обращаются к угрозам, описанным в Разделе 2.3.1 («Устранение угроз»). Пожалуйста, обратитесь к Разделу 14.2 («Несоответствующие последствия для агента пользователя») для дальнейшего обсуждения.

11.2. Время истечения срока действия политики HSTS

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

Подход «постоянное значение в будущее» может быть достигнут путем постоянной отправки одного и того же максимального значения в UA.

Например, максимальное значение возраста 7776000 секунд составляет 90 дней:

Strict-Transport-Security: max-age=7776000

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

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

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

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

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

Если все четыре из следующих условий выполняются …

• веб-сайт / организация / предприятие генерирует собственные сертификаты открытого ключа безопасного транспорта для веб-сайтов, и
• сертификат корневого центра сертификации (ЦС) этой организации обычно не внедряется по умолчанию в хранилища сертификатов ЦС браузера и / или операционной системы, и
• Политика HSTS включена на хосте, идентифицирующем себя с помощью сертификата, подписанного центром сертификации организации (то есть, «самоподписанный сертификат»), и
• этот сертификат не соответствует используемой ассоциации сертификатов TLS (как определено в разделе 4 спецификации протокола TLSA [RFC6698]),

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

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

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

ПРИМЕЧАНИЕ. Интерактивное распространение сертификатов корневого ЦС среди пользователей, например, по электронной почте, и установление пользователями их, вероятно, обучает пользователей восприимчивости к возможной форме фишинг-атаки. См. Раздел 14.8 («Фальшивый корневой сертификат CA Фиш плюс атака отравления кешем DNS»). Таким образом, необходимо соблюдать осторожность при распределении и установке таких сертификатов в пользовательских системах и браузерах.

11.4. Последствия includeSubDomains

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

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

Разделы ниже обсуждают каждый из этих сценариев по очереди.

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

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

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

В этом случае Пример CA может:

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

ПРИМЕЧАНИЕ. Вышеуказанные пункты являются всего лишь примером и не имеют целью решить все связанные с этим сложности. Например, существует множество соображений — со стороны ЦС, развертывателей сертификатов и приложений (например, браузеров) — связанных с развертыванием такого подхода, как «Сшивание OCSP». Такие проблемы выходят за рамки данной спецификации.

11.4.2. Рекомендации по предложению веб-приложений на поддоменах хоста HSTS

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

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

Если поле заголовка STS отправляется только «example.com», но UA обычно устанавливают закладки, а ссылки (из любого места в Интернете) обычно устанавливаются на «www.example.com», а «example.com» если с каким-либо ненулевым процентом взаимодействий не связываются напрямую все пользовательские агенты, то некоторое количество UA не будет отмечать «example.com» в качестве хоста HSTS, а некоторое количество пользователей «www.example.com» будет незащищенным по политике HSTS.

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

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

 

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

Этот раздел не является нормативным.

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

 

12.1. Нет ресурсов пользователя

Неудачное установление безопасного соединения с любыми предупреждениями или ошибками (согласно Разделу 8.4 («Ошибки в безопасном установлении транспорта»)) должно быть сделано «без обращения пользователя». Это означает, что пользователю не должно быть представлено диалоговое окно, дающее ему возможность продолжить. Скорее, его следует рассматривать аналогично ошибке сервера, когда пользователь ничего не может сделать в отношении взаимодействия с целевым веб-приложением, кроме ожидания и повторных попыток.

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

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

12.2. Заявленная пользователем политика HSTS

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

ПРИМЕЧАНИЕ. Подобную функцию сложно получить для отдельных сайтов. Смотрите обсуждение «правил перезаписи» в Разделе 5.5 [ForceHTTPS]. Например, произвольные веб-сайты могут не материализовать все свои URI, используя схему «https», и, таким образом, могут «сломаться», если агент UA попытается получить доступ к сайту исключительно с использованием таких URI. Также обратите внимание, что эта функция будет дополнять, но не зависит от функции «Предварительно загруженный список HSTS» (см. Раздел 12.3).

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

Предварительно загруженный список HSTS — это средство, с помощью которого администраторы веб-сайтов могут иметь предварительно настроенные UA с политикой HSTS для своих сайтов поставщиком (ами) UA — так называемый «предварительно загруженный список» — в способ, аналогичный тому, как сертификаты корневого CA встраиваются в браузеры «на заводе». Это поможет защитить от уязвимости начальной загрузки MITM (раздел 14.6).

ПРИМЕЧАНИЕ. Такое средство будет дополнять функцию «Объявленная пользователем политика HSTS» (раздел 12.2).

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

Загрузка «смешанного контекста безопасности» происходит, когда ресурс веб-приложения, выбираемый агентом UA по безопасному транспорту, впоследствии вызывает выборку одного или нескольких других ресурсов без использования безопасного транспорта. Обычно это также называется загрузкой «смешанного содержимого» (см. Раздел 5.3 («Смешанное содержимое») в [W3C.REC-wsc-ui-20100812]), но его не следует путать с тем же термином «смешанное содержимое», которое также используется в контексте языков разметки, таких как XML и HTML.

ПРИМЕЧАНИЕ. Чтобы обеспечить единообразие поведения в реализациях UA, понятие смешанного контекста безопасности потребует дальнейшей работы по стандартизации, например, для более четкого определения термина (ов) и определения конкретного поведения по отношению к нему.

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

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

ПРИМЕЧАНИЕ. Добавление такой функции должно выполняться очень аккуратно как в пользовательском интерфейсе, так и с точки зрения безопасности. Удаление записи в кэше для известного хоста HSTS должно быть очень обдуманным и продуманным действием — это не должно быть чем-то, к чему пользователи привыкли делать, как само собой разумеющееся: например, просто «нажимая», чтобы получить работа сделана. Кроме того, реализации должны быть защищены от того, чтобы злоумышленник мог ввести код, например ECMAscript, в UA, который автоматически и программно удаляет записи из кэша UA известных хостов HSTS.

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

Текстовые доменные имена в современном Интернете могут содержать одну или несколько «интернационализированных» меток доменных имен. Такие доменные имена называются «интернационализированными доменными именами» (IDN). Наборы спецификаций, определяющие IDN и протоколы для их использования, называются «Интернационализированные доменные имена для приложений (IDNA)». В настоящее время существует два таких комплекта спецификаций: IDNA2008 [RFC5890] и его предшественник IDNA2003 [RFC3490].

IDNA2008 устаревает IDNA2003, но между этими двумя спецификациями есть различия, и, таким образом, могут быть различия в обработке (например, преобразовании) меток доменных имен, которые были зарегистрированы под одной из тех, которые зарегистрированы под другой. Будет некоторый переходный период, в течение которого метки доменных имен на основе IDNA2003 будут существовать в свободном доступе. Чтобы упростить переход IDNA, пользовательские агенты ДОЛЖНЫ внедрить IDNA2008 [RFC5890] и МОГУТ реализовать [RFC5895] (см. Также Раздел 7 [RFC5894]) или [UTS46]. Если пользовательский агент не реализует IDNA2008, пользовательский агент ДОЛЖЕН реализовывать IDNA2003.

14. Вопросы безопасности

Эта спецификация касается выражения, передачи и применения Политики HSTS. Общая модель угроз политики HSTS, включая адресные и неадресованные угрозы, приведена в разделе 2.3 («Модель угроз»).

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

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

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

14.2. Неподходящие последствия для агента пользователя

Несоответствующие пользовательские агенты игнорируют поле заголовка Strict-Transport-Security; таким образом, несовместимые пользовательские агенты не обращаются к угрозам, описанным в Разделе 2.3.1 («Устранение угроз»).

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

o Пассивные сетевые атаки из-за ошибок в разработке и развертывании веб-сайтов:

Например, если веб-приложение содержит какие-либо небезопасные ссылки (например, «http») на сервер веб-приложений, и если не все его файлы cookie помечены как «Защищенные», то эти файлы cookie будут уязвимы для пассивного прослушивания сети и, потенциально, последующее неправильное использование учетных данных пользователя.

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

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

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

14.3. Последствия установления политики HSTS только через безошибочный безопасный транспорт

Модель обработки пользовательского агента, определенная в Разделе 8 («Модель обработки пользовательского агента»), предусматривает, что хост первоначально помечается как Известный хост HSTS или что обновления производятся для кэшированной информации Известного хоста HSTS, только если UA получает STS поле заголовка над безопасным транспортным соединением, не содержащее ошибок и предупреждений безопасного транспорта.

Обоснование этого заключается в том, что если есть «человек посередине» (MITM) — будь то законно развернутый прокси или нелегитимная сущность — это может привести к различным неприятностям (см. Также пункт «Приложение A» («Примечания относительно решения о разработке»)) 3, а также раздел 14.6 («Уязвимость Bootstrap MITM»); например:

• Несанкционированное обозначение хоста как известного хоста HSTS, что может привести к ситуации отказа в обслуживании, если хост не будет предлагать свои услуги единообразно по защищенному транспорту (см. также раздел 14.5 («Отказ в обслуживании»)).
• Сброс времени жизни для назначения хоста в качестве известного хоста HSTS путем манипулирования значением параметра поля заголовка max-age, которое возвращается в UA. Если max-age возвращается как ноль, это приведет к тому, что UA перестанет рассматривать хост как известный хост HSTS, что приведет либо к небезопасным соединениям с хостом, либо к возможному отказу в обслуживании, если хост предоставляет свои услуги только по безопасной передаче.

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

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

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

14.4. Необходимость включения доменов

Без директивы includeSubDomains веб-приложение не сможет адекватно защитить так называемые «доменные куки» (даже если для этих куки установлен флаг «Безопасный» и, следовательно, они передаются только по защищенным каналам). Это файлы cookie, которые веб-приложение ожидает от UA, чтобы они вернулись ко всем поддоменам веб-приложения.

Например, предположим, что example.com представляет имя DNS верхнего уровня для веб-приложения. Предположим также, что этот файл cookie установлен для всего домена example.com, то есть это «файл cookie домена», и для него установлен флаг Secure. Предположим, example.com является известным хостом HSTS для этого UA, но директива includeSubDomains не задана.

Теперь, если злоумышленник заставляет UA запросить имя субдомена, которое вряд ли уже существует в веб-приложении, например «https://uxdhbpahpdsf.example.com/», но злоумышленнику удалось зарегистрироваться в DNS и укажите на HTTP-сервер под контролем злоумышленника, затем:

• 1. Скорее всего, UA уже имеет политику HSTS, установленную для «uxdhbpahpdsf.example.com».
• 2. HTTP-запрос, отправляемый на uxdhbpahpdsf.example.com, будет включать куки-файл домена с защищенным флагом.
• 3. Если «uxdhbpahpdsf.example.com» возвращает сертификат во время установления TLS, и пользователь «щелкает» любое предупреждение, которое может быть выдано (возможно, но не уверен, что можно получить необходимый сертификат для такого домена назовите его так, чтобы предупреждение могло появляться, а может и не появляться), тогда злоумышленник может получить cookie-файл домена с защищенным флагом, который якобы защищен.

Без директивы includeSubDomains HSTS не сможет защитить такие cookie-файлы домена, помеченные Безопасным.

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

HSTS может использоваться для установки определенных форм атак типа «отказ в обслуживании» (DoS) на веб-сайты. DoS-атака — это атака, при которой один или несколько сетевых объектов нацеливаются на объект-жертву и пытаются помешать жертве выполнять полезную работу. В этом разделе обсуждаются такие сценарии с точки зрения HSTS, хотя этот список не является исчерпывающим. См. Также [RFC4732] для обсуждения общих аспектов DoS в Интернете.

o Веб-приложения доступны через HTTP

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

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

ПРИМЕЧАНИЕ. Это вариант использования для UA, чтобы предложить функцию «Удаление политики HSTS», как отмечено в Разделе 12.5 («Удаление политики HSTS»).

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

* Если веб-приложение имеет уязвимость разделения HTTP-ответов [CWE-113] (которая может использоваться для упрощения «внедрения заголовка HTTP»).

* Если злоумышленник может подделать перенаправление с незащищенного сайта жертвы, например, с <http://example.com/> на <https://example.com/>, где последний контролируется злоумышленником и имеет явно действительный сертификат. В этом случае злоумышленник может установить политику HSTS для example.com, а также для всех поддоменов example.com.

* Если злоумышленник может убедить пользователей вручную настроить политику HSTS для хоста жертвы. Это предполагает, что их UA предлагают такую ​​возможность (см. Раздел 12 («Рекомендации по внедрению пользовательского агента»)). В качестве альтернативы, если такая конфигурация UA является сценарием, то злоумышленник может заставить UA выполнить свой сценарий и установить политики HSTS для любого желаемого домена.

o непреднамеренное использование includeSubDomains

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

14.6. Уязвимость Bootstrap MITM

Уязвимость Bootstrap MITM (человек-посредник) — это уязвимость, с которой пользователи и хосты HSTS сталкиваются в ситуации, когда пользователь вручную вводит или переходит по ссылке на неизвестный хост HSTS, используя URI «http» вместо «» https «URI. Поскольку UA использует небезопасный канал при первоначальной попытке взаимодействия с указанным сервером, такое начальное взаимодействие уязвимо для различных атак (см. Раздел 5.3 [ForceHTTPS]).

ПРИМЕЧАНИЕ. Существуют различные функции / возможности, которые могут использовать реализации UA для снижения этой уязвимости. Пожалуйста, смотрите раздел 12 («Рекомендации по внедрению пользовательского агента»).

14.7. Сетевые временные атаки

Активные сетевые атаки могут подорвать сетевые протоколы времени (такие как Сетевой протокол времени (NTP) [RFC5905]) — делая HSTS менее эффективным по отношению к клиентам, которые доверяют NTP или испытывают недостаток в часах реального времени. Сетевые временные атаки выходят за рамки данной спецификации. Обратите внимание, что современные операционные системы по умолчанию используют NTP. См. Также раздел 2.10 [RFC4732].

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

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

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

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

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

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

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

Такая техника потенциально может быть использована как еще одна форма «веб-отслеживания» [WebTracking].

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

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

Модели обработки, указанные в этой спецификации, предполагают, что доменные имена, которыми они манипулируют, являются канонизированными IDNA, и что процесс канонизации правильно выполнил все соответствующие проверки IDNA и Unicode и тестирование списка символов в соответствии с требуемыми спецификациями (например, как отмечено в Разделе 10 (» Доменное имя IDNACanonicalization «)). Эти шаги необходимы для того, чтобы избежать различных потенциально опасных ситуаций.

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

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

Подробнее см. Разделы «Вопросы безопасности» [RFC5890], [RFC5891] и [RFC3490], а также спецификации, на которые они нормативно ссылаются. Кроме того, [RFC5894] предоставляет подробную справочную информацию и обоснование для IDNA2008 в частности, а также для IDNA и ее проблем в целом, и к ним следует обращаться в связи с предыдущими спецификациями.

15. Соображения IANA

Ниже приведена информация о регистрации поля постоянного заголовка сообщения Управления по присвоению номеров (IANA) в Интернете согласно [RFC3864].

Имя поля заголовка: Strict-Transport-Security
Применимый протокол: http
Статус: стандарт
Автор / Смена контроллера: IETF
Спецификационный документ (ы): этот

16. Ссылки

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[RFC2818] Rescorla, E., «HTTP Over TLS», RFC 2818, May 2000.

[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, «Internationalizing Domain Names in Applications (IDNA)», RFC 3490, March 2003.

[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, «Registration Procedures for Message Header Fields», BCP 90, RFC 3864, September 2004.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, August 2008.

[RFC5890] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, August 2010.

[RFC5891] Klensin, J., «Internationalized Domain Names in Applications (IDNA): Protocol», RFC 5891, August 2010.

[RFC5895] Resnick, P. and P. Hoffman, «Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008», RFC 5895, September 2010.

[RFC6698] Hoffman, P. and J. Schlyter, «The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA», RFC 6698, August 2012.

[UTS46] Davis, M. and M. Suignard, «Unicode IDNA Compatibility Processing», Unicode Technical Standard #46, <http://unicode.org/reports/tr46/>.

[Unicode] The Unicode Consortium, «The Unicode Standard», <http://www.unicode.org/versions/latest/>.

[W3C.REC-html401-19991224] Raggett, D., Le Hors, A., and I. Jacobs, «HTML 4.01 Specification», World Wide Web Consortium Recommendation REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224/>.

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

[Aircrack-ng] d’Otreppe, T., «Aircrack-ng», Accessed: 11-Jul-2010, <http://www.aircrack-ng.org/>.

[BeckTews09] Beck, M. and E. Tews, «Practical Attacks Against WEP and WPA», Second ACM Conference on Wireless Network Security Zurich, Switzerland, 2009, <http://dl.acm.org/citation.cfm?id=1514286>.

[CWE-113] «CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers (’HTTP Response Splitting’)», Common Weakness Enumeration <http://cwe.mitre.org/>, The Mitre
Corporation <http://www.mitre.org/>, <http://cwe.mitre.org/data/definitions/113.html>.

[Firesheep] Various, «Firesheep», Wikipedia Online, ongoing, <https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Firesheep&oldid=517474182>.

[ForceHTTPS] Jackson, C. and A. Barth, «ForceHTTPS: Protecting High-Security Web Sites from Network Attacks», In Proceedings of the 17th International World Wide Web Conference
(WWW2008) , 2008, <https://crypto.stanford.edu/forcehttps/>.

[GoodDhamijaEtAl05] Good, N., Dhamija, R., Grossklags, J., Thaw, D., Aronowitz, S., Mulligan, D., and J. Konstan, «Stopping Spyware at the Gate: A User Study of Privacy, Notice and Spyware», In Proceedings of Symposium On Usable Privacy and Security (SOUPS) Pittsburgh, PA, USA, July 2005, <http://www.law.berkeley.edu/files/Spyware_at_the_Gate.pdf>.

[HTTP1_1-UPD] Fielding, R., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», Work in Progress, October 2012.

[JacksonBarth2008] Jackson, C. and A. Barth, «Beware of Finer-Grained Origins», Web 2.0 Security and Privacy Workshop, Oakland, CA, USA, 2008,
<http://seclab.stanford.edu/websec/origins/fgo.pdf>.

[OWASP-TLSGuide] Coates, M., Wichers, D., Boberski, M., and T. Reguly, «Transport Layer Protection Cheat Sheet», Accessed: 11-Jul-2010, <http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet>.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, «X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP», RFC 2560, June 1999.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, March 2005.

[RFC4732] Handley, M., Rescorla, E., and IAB, «Internet Denial-of-Service Considerations», RFC 4732, December 2006.

[RFC4949] Shirey, R., «Internet Security Glossary, Version 2», RFC 4949, August 2007.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, May 2008.

[RFC5894] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale», RFC 5894, August 2010.

[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, June 2010.

[RFC6066] Eastlake, D., «Transport Layer Security (TLS) Extensions: Extension Definitions», RFC 6066, January 2011.

[RFC6101] Freier, A., Karlton, P., and P. Kocher, «The Secure Sockets Layer (SSL) Protocol Version 3.0», RFC 6101, August 2011.

[RFC6125] Saint-Andre, P. and J. Hodges, «Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer Security (TLS)», RFC 6125, March 2011.[RFC6265] Barth, A., «HTTP State Management Mechanism», RFC 6265, April 2011.

[RFC6454] Barth, A., «The Web Origin Concept», RFC 6454, December 2011.

[SunshineEgelmanEtAl09] Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and L. Cranor, «Crying Wolf: An Empirical Study of SSL Warning Effectiveness», In Proceedings of 18th USENIX Security Symposium Montreal, Canada, August 2009, <http://www.usenix.org/events/sec09/tech/full_papers/sunshine.pdf>.

[W3C.REC-wsc-ui-20100812] Roessler, T. and A. Saldhana, «Web Security Context: User Interface Guidelines», World Wide Web Consortium Recommendation REC-wsc-ui-20100812, August 2010, <http://www.w3.org/TR/2010/REC-wsc-ui-20100812>.

[WebTracking] Schmucker, N., «Web Tracking», SNET2 Seminar Paper — Summer Term, 2011, <http://www.snet.tu-berlin.de/fileadmin/fg220/courses/SS11/snet-project/
web-tracking_schmuecker.pdf>.

Приложение А. Примечания к проектному решению

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

1. Файлы cookie не подходят для выражения политики HSTS, поскольку они могут быть изменяемыми (при хранении в UA); поэтому используется поле заголовка HTTP.

2. Мы решили не пытаться указать, как обрабатываются «смешанные загрузки контекста безопасности» (также известные как «смешанные загрузки контента»), из-за соображений реализации UA, а также из-за трудностей классификации.

3. Хост HSTS может обновлять представления UA о политике HSTS с помощью новых значений параметров поля заголовка HSTS. Мы решили, что UA должны учитывать «самую свежую» информацию, полученную с сервера, поскольку существует вероятность того, что веб-сайт отправит ошибочную политику HSTS, такую ​​как многолетнее значение максимального возраста и / или неправильная директива includeSubDomains. Если узел HSTS не может исправить такие ошибки по протоколу, это потребует некоторой формы оповещения пользователей и ручного вмешательства со стороны пользователей, что может быть нетривиальной проблемой как для поставщиков веб-приложений, так и для их пользователей.

4. HSTS Хосты идентифицируются только по доменным именам — явная идентификация IP-адреса всех форм исключена. Это для упрощения, а также для распознавания различных проблем с использованием прямой идентификации IP-адреса в сочетании с безопасностью на основе PKI.

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

6. При определении необходимости использования сопоставления портов был рассмотрен вариант простого отказа в разыменовании любого URL-адреса с явным портом. Однако считалось, что вероятность того, что разыменованный URI неверен (и на этом порту действительно имеется действующий HTTPS-сервер), стоит небольших затрат, которые могут быть потрачены впустую на HTTPS-выборки для HTTP-серверов.

Приложение B. Различия между политикой HSTS и политикой того же происхождения

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

• Политика HSTS устанавливает требования к характеристикам безопасности установления соединения UA-to-host для каждого хоста.
• Хосты явно декларируют Политику HSTS для UA. Соответствующие UA обязаны применять декларируемые HSTS Политики хостов.
• Политика HSTS передается по протоколу от хоста к UA.
• UA поддерживает кеш известных хостов HSTS.
• UA применяют политику HSTS всякий раз, когда устанавливают HTTP-соединение с известным хостом HSTS, независимо от номера порта хоста; то есть он применяется ко всем портам на известном хосте HSTS. Хозяева не могут повлиять на этот аспект политики HSTS.
• Хосты могут по желанию заявить, что их Политика HSTS применяется ко всем поддоменам их доменного имени хоста.

Напротив, Политика одного и того же происхождения (SOP) [RFC6454] имеет следующие основные характеристики:

• Источник — это схема, хост и порт URI, идентифицирующего ресурс.
• UA может разыменовать URI, таким образом загружая представление ресурса, который идентифицирует URI. UA помечают представления ресурсов своими источниками, которые являются производными от их URI.
• SOP относится к совокупности принципов, реализованных в UA, управляющих изоляцией и связью между представлениями ресурсов в UA, а также доступом представительств ресурсов к сетевым ресурсам.

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

Приложение C. Благодарности

Авторы благодарят Девдатту Ахаве, Майкла Барретта, Бена Кэмпбелла, Тобиаса Гондрома, Пола Хоффмана, Мюррея Кучерови, Барри Лейбу, Джеймса Мангера, Алексея Мельникова, Хеварда Молланда, Йоава Нира, Ингве Н. Петтерсена, Лакша Рагхавана, Марш Рэя, Джулиана Решке, Эрик Рескорла, Том Риттер, Питер Сен-Андре, Брайан Смит, Роберт Спаркс, Мачей Стаховяк, Сид Стамм, Энди Стейнгрубл, Брэндон Стерн, Мартин Томсон, Даниэль Ведитц и Ян Вробель, а также все участники рабочей группы websec и другие за их различные отзывы и полезные вклады.

Спасибо Джулиану Решке за элегантное переписывание текста URI эффективного запроса, который он сделал, включив понятие ERU в обновления HTTP / 1.1 [HTTP1_1-UPD]. Впоследствии текст ЕСВ в этой спецификации был взят из работы Джулиана в обновленной спецификации HTTP / 1.1 (часть 1) и адаптирован к ABNF [RFC2616].

Адрес автора

Jeff Hodges
PayPal
2211 North First Street
San Jose, California 95131
US
EMail: Jeff.Hodges@PayPal.com

Collin Jackson
Carnegie Mellon University
EMail: collin.jackson@sv.cmu.edu

Adam Barth
Google, Inc.
EMail: ietf@adambarth.com
URI: http://www.adambarth.com/