Аннотация
В данном документе определяется механизм, который позволяет WEB-сайту анонсировать доступ только через безопасные соединения и/или для пользователей, способных указать своим агентам пользователя устанавливать соединение с данными сайтами только через безопасные каналы. Эта политика называется строгой транспортной безопасностью HTTP (HSTS — HTTP Strict Transport Security). Политика декларируется WEB-сайтами через поле заголовка отклика HSTS и/или другими способами, такими, например, как конфигурация агента пользователя.
Оглавление
- 1. Введение
- 2. Обзор
- 2.1. Случаи использования
- 2.2. Последствия политики строго безопасного транспорта HTTP
- 2.3. Модель угроз
- 2.3.1. Адресные угрозы
- 2.3.1.1. Пассивные сетевые атакеры
- 2.3.1.2. Активные сетевые атакеры
- 2.3.1.3. Ошибки разработки Web-сайта и применения
- 2.3.2. Неадресные угрозы
- 2.3.2.1. Фишинг
- 2.3.2.2. Уязвимости, malware и браузеры
- 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 при строгой транспортной безопасности
- 6.1.1. Директива max-age
- 6.1.2. Директива includeSubDomains
- 6.2. Примеры
- 7. Модель работы сервера
- 7.1. Тип запроса HTTP-через-безопасный-транспортный канал
- 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. Соображения предложения Web-приложений через субдомены 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. Необходимость includeSubDomains
- 14.5. Отказ обслуживания
- 14.6. Уязвимость Bootstrap MITM (человек посередине)
- 14.7. Атаки против сетевого времени
- 14.8. Поддельные корневые сертификаты и атаки с отравлением кэша DNS
- 14.9. Креативное манипулирование запоминанием политики HSTS
- 14.10. Интернационализированные имена доменов
- 16. Ссылки
- 16.1. Нормативные ссылки
- 16.2. Информационные ссылки
- Приложение A. Устройство узлов принятия решений
- Приложение B. Отличия обычной политики и политики HSTS
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) "http" (на практике, однако, агенты пользователя HTTP (UA) обычно используют либо TLS, либо SSL3, в зависимости от предпочтений сервера и пользователя).
UA используют различные локальные политики безопасности с учетом характеристик их взаимодействия с WEB-ресурсами, в зависимости от того, взаимодействует ли компьютер данного ресурса с привлечением HTTP или HTTP поверх безопасного тракта. Например, куки ([RFC-6265]) могут быть помечены как безопасные. UA должны посылать такие безопасные куки своему компьютеру-адресату только через безопасный транспортный канал. Напротив, небезопасные куки возвращаются компьютеру по любому транспортному каналу (без учета его безопасности).