Попробуйте удалить атрибут always. Итак, сделайте следующее:
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
Вместо этого:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
Другой вариант — установить это только в HTTPS VirtualHost, а не в основной конфигурации верхнего уровня:
Сделай это:
<VirtualHost *:443>
(All other virtual host config)
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>
Вместо этого:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
<VirtualHost *:443>
(All other virtual host config)
</VirtualHost>
Это имеет недостаток (или преимущество, в зависимости от того, как вы на это смотрите!) Необходимость добавления к каждому VirtualHost для вступления в силу, тогда как первый вариант будет автоматически применяться ко всем виртуальным хостам HTTPS.
И пожалуйста, пожалуйста, будьте очень осторожны с предварительной загрузкой. Это не легко обратимо! Я бы настоятельно рекомендовал вам несколько месяцев работать с хорошей (т.е. безошибочной) конфигурацией — чего, похоже, вы еще не делали — перед отправкой в список предварительной загрузки.
Приведем один пример, когда предварительная загрузка может вызвать у вас проблемы: предположим, вы запускаете https://www.example.com и это также отвечает на http://example.com и перенаправляет вас на https://example.com, а затем https://www.example.com (как того требует предварительная загрузка и как настроена ваша конфигурация). Тогда ваш сайт красивый и безопасный. Однако для компаний, которые повторно используют свой домен для внутренних целей (что довольно часто), это может вызвать проблемы, особенно при предварительной загрузке. Например, если вы используете незащищенный сайт, который не находится в открытом доступе по адресу http://intranet.example.com или, возможно, небезопасную разрабатываемую версию вашего сайта по адресу http://dev.example.com, затем вы можете не знать, что этот сайт теперь также должен обслуживаться через HTTPS (поскольку это поддомен example.com). Это редко срабатывает (поскольку большинство людей не посещают http://example.com или https://example.com, поэтому никогда не увидите этот заголовок HSTS в домене верхнего уровня), поэтому вы можете никогда не заметить эту потенциальную проблему во время всего тестирования. Однако, как только предварительная загрузка вступит в силу, ваш браузер узнает о HSTS в домене верхнего уровня, даже не посещая его, и вы мгновенно потеряете доступ к этим HTTP-сайтам и не сможете легко отменить это! Многие компании по-прежнему имеют множество внутренних сайтов и инструментов, обслуживаемых только через HTTP, и обновить их все до HTTPS (что, кстати, нужно сделать в любом случае!) в кратчайшие сроки будет непросто.
Чтобы обойти это, либо используйте другой домен внутри, либо вы можете установить его без includeSubDomain только в домене верхнего уровня:
<VirtualHost *:443>
ServerName example.com
(All other virtual host config)
#Set HSTS at top level without includeSubDomain
Header always set Strict-Transport-Security "max-age=31536000"
</VirtualHost>
<VirtualHost *:443>
ServerName www.example.com
(All other virtual host config)
#Set HSTS at subdomain level
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</VirtualHost>
Это не так безопасно (поскольку кто-то может настроить другие поддомены через HTTP, например http://wwww.example.com (обратите внимание на четыре буквы W) или http://fake.subdomain.com), но, по крайней мере, это не так. сломать эти HTTP-сайты. Эта настройка не будет разрешена в списке предварительной загрузки, поскольку она требует более безопасных includeSubDomains даже в домене верхнего уровня.
Если вы хотите использовать includeSubDomains даже в домене верхнего уровня, я настоятельно рекомендую включить ресурс из домена верхнего уровня в ваш HTML (даже если он перенаправляет на версию с www, поскольку HSTS по-прежнему настроен на 301s/302s). Таким образом, вы убедитесь, что посетители загружают конфигурацию HSTS на верхнем уровне еще до того, как вы предварительно загрузите. Например, вместо этого вы можете заменить свой логотип на вызов домена верхнего уровня:
<img source="https://example.com/logo.png">
Запуск с этим, небольшим сроком действия и отсутствием тега предварительной загрузки на некоторое время. Затем увеличьте срок действия. Затем, если все работает, добавьте тег предварительной загрузки обратно и отправьте в список предварительной загрузки.
Все это может показаться немного болезненным, и, возможно, вы думали обо всем этом, но предварительная загрузка может быть невероятно опасной, если ее не продумать, из-за того, что ее нелегко отменить. На мой взгляд, предварительная загрузка HSTS является излишним для большинства сайтов, хотя я согласен, что это наиболее безопасный вариант.
person
Barry Pollard
schedule
11.07.2017
