Допустим, я управляю компанией Example Inc и имею веб-сайт по адресу:
Теперь, поскольку я озабочен безопасностью, я использую https и хотел бы установить заголовок HSTS, чтобы принудительно использовать его. Еще я бы включил поддомены на долгое время, скажем год.
Строгая транспортная безопасность: максимальный возраст = 31536000; includeSubDomains
Теперь я также хороший владелец веб-сайта, поэтому установил следующее с 301 редиректом на указанный выше сайт:
Последний также имеет заголовок HSTS, а также его сайт https.
Насколько я понимаю, это рекомендуемая настройка для работы с https-сайтом (плюс, очевидно, множество других настроек), и она будет довольно распространенной.
Все идет нормально.
Теперь внутри компании, в интрасети компании, а не в Интернете, у меня есть множество серверов и я использую домен example.com. Так что я:
Теперь предположим, что на некоторых из этих машин работают веб-серверы, и не все из них работают по протоколу https.
Разве это не означает, что кто-то из моих сотрудников случайно навещал https://example.com тогда их браузер установит заголовок HSTS и откажется переходить на http для любых поддоменов и больше не сможет получить доступ к некоторым из этих внутренних веб-серверов только для http?
Что с этим делать?
Должен ли я поставить под угрозу безопасность моего внешнего веб-сайта, не используя параметр includeSubDomains? По крайней мере, не на https://example.com сайт? Кажется неправильным ставить под угрозу внешнюю безопасность из-за внутренней проблемы.
Должен ли я заставить все мои внутренние приложения тоже быть https? Легче сказать, чем сделать.
Стоит ли использовать для внутренних целей другой домен? Например. machine1.intraexample.com? Кажется, пустая трата домена, и некоторые элементы (например, сервер электронной почты) должны быть в основном домене, хотя, возможно, они могут быть ограничены только веб-серверами https, если им вообще нужно их запускать.
Есть другие мысли?
Кроме того, подумайте, что это может вызвать большие проблемы для компании и, возможно, должно быть выделено больше в спецификации и в других местах. Многие владельцы веб-сайтов не имеют отдельной конфигурации для версии без www и поэтому могут случайно установить флаг includeSubDomain в домене верхнего уровня. Я избежал этого, только думая об этом сценарии перед реализацией. Сначала я установлю очень низкий срок действия (один день), чтобы сгладить эти проблемы, которые также можно было бы предложить более решительно ИМХО. Это легко могло быть упущено и вызвало странные проблемы для потенциально большого количества пользователей.
Редактировать июнь 2015 А вот реальный пример того, как сайт ошибается: https://github.com/NuGet/NuGetGallery/issues/2535
Редактировать октябрь 2015 г. Статья, в которой предлагается использовать includeSubDomains в TLD для устранения недостатков файлов cookie: http://www.kb.cert.org/vuls/id/804060. Это правда (в противном случае хакер с доступом к DNS мог бы создать фиктивный субдомен и использовать его для установки cookie на уровне TLD). Однако вышеупомянутый риск самостоятельного DoSing-атаки на внутренние HTTP-сайты все еще существует, и это обеспечит защиту только при переходе к TLD или предварительной загрузке HSTS.
подход, не обслуживающий includeSubDomains - флаг означает немного больше работы и дисциплины, но не считается вредным, особенно когда у вас есть причина для этого.
Вы можете установить заголовок HSTS явно на каждом внешнем HTTPS-сервере без includeSubDomains.
кроме того, убедитесь, что на каждом HTTPS-сервере есть дополнительный HTTP-> HTTPS-перенаправление.
но лучше всего использовать https-трафик и для внутренних веб-сайтов. вы можете использовать свой собственный CA или wildcard-cert, который больше не так дорог