Проблемы с помощью заголовка HSTS в высокоуровневом домене с includeSubdomains

Скажем, я выполняю компанию "Example Inc" и имею веб-сайт в:

https://www.example.com

Теперь, потому что я - совесть безопасности, я использую https и хотел бы установить заголовок HSTS для принуждения его использования. Я был бы также includeSubdomains в течение долгого времени, скажем, год.

Строгая транспортная безопасность: max-age=31536000; includeSubDomains

Теперь я - также хороший владелец веб-сайта, таким образом, я настроил следующее с 301 перенаправлением на вышеупомянутый сайт:

• http://www.example.com
• http://example.com
• https://example.com

Последний также имеет заголовок HSTS, а также это - https сайт.

Это, насколько я понимаю, является рекомендуемым, настроенным для выполнения https веб-сайта (плюс много других настроек, очевидно), и было бы довольно распространено.

Пока все хорошо.

Теперь внутренне, на интранет компании, и не доступный в Интернете, я имею загрузки серверов и использую домен example.com. Таким образом, я имею:

• machine1.example.com
• machine2.example.com... и т.д.

Теперь предположение некоторых из этих машин выполняет веб-серверы, и не все они https.

Разве это не означает, посетил ли какой-либо из моих сотрудников, оказалось, https://example.com затем, их браузер установит заголовок HSTS и откажется переходить к http для каких-либо sub доменов и так больше не может получать доступ к некоторым из тех внутренних http-только веб-серверов?

Каков путь вокруг этого?

Я должен поставить под угрозу свою внешнюю безопасность веб-сайта, не используя установку includeSubDomains? По крайней мере, не на сайте https://example.com? Это кажется неправильным поставить под угрозу внешнюю безопасность для внутренней проблемы.

Я должен вынудить все свои внутренние приложения быть https также? Это легче сказать чем сделать.

Я должен использовать другой домен внутренне? Например, machine1.intraexample.com? Кажется тратой домена, и некоторые объекты (например, Почтовый сервер) должны будут быть на основном домене, хотя возможно они могли быть ограничены https только веб-серверы, если они даже должны выполнить их вообще.

Какие-либо другие мысли?

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

Июнь 2015 редактирования И вот является примером реального мира сайта, понимающего эту самую вещь превратно: https://github.com/NuGet/NuGetGallery/issues/2535

Октябрь 2015 редактирования статья, которая предлагает Вас действительно, должен использовать includeSubDomains в TLD для обращения к дефектам в cookie: http://www.kb.cert.org/vuls/id/804060. Это верно (хакер с доступом DNS мог иначе создать fictious субдомен и использовать это для установки cookie на уровне TLD). Однако выше риска сам DoSing внутренние сайты только для HTTP все еще существуют с этим, и это только обеспечит защиту Вас, переходят к TLD или предварительно загружают HSTS.