Назад | Перейти на главную страницу

Заголовок Strict-Transport-Security установлен, но Firefox и Chrome все еще используют HTTP

Мой веб-сайт использует универсальный SSL от CloudFlare, и я хотел бы, чтобы браузер автоматически перенаправлял на HTTPS. Однако, как не все браузеры поддерживают тот тип SSL, который использует облачная вспышка, Я не хочу напрямую использовать SSL. Так что HSTS кажется хорошим вариантом. Однако, когда я тестирую его в своем браузере, похоже, он работает не так, как я ожидал.

В моем файле конфигурации для сайта у меня есть такая строка:

server {
    ...
    listen 443 ssl;
    add_header Strict-Transport-Security max-age=63072000;
    ...
}

И это отображается в заголовках ответов:

Strict-Transport-Security: max-age=63072000

Однако Firefox 35 и Chrome 41 в Windows 10 и OS X 10.10.3 по-прежнему будут перемещаться по сайту по HTTP без перенаправления на HTTPS.

Я использую NGINX версии 1.7.3 под управлением CentOS 7.

Заголовок ответа STS действует только в защищенных схемах. Клиент должен посетить https-страницу хотя бы один раз, чтобы получить запись STS в кеше HSTS.

Спецификация предполагает, что серверы ДОЛЖНЫ перенаправлять на https с HTTP, но это не всегда возможно. Таким образом, вы можете попытаться обнюхать неподдерживаемый User-Agent на сервере и выполнить перенаправление только в том случае, если UA не внесен в черный список.

Видеть раздел 7.2 RFC 6797 для получения дополнительной справочной информации:

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, передаваемые по незащищенному транспорту.

Не ответ сам по себе, но причина, по которой вам не разрешено устанавливать Strict-Transport-Security для небезопасного соединения, заключается в том, что это позволит злоумышленнику MITM - той самой угрозе, для которой был разработан HSTS - заблокировать доступ к любой сайт, который фактически не поддерживает SSL.