假设我经营一家公司“Example Inc”，其网站地址为：
现在，由于我注重安全，我正在使用 https，并希望设置 HSTS 标头以强制使用它。我还会长期包含子域，比如说一年。
严格传输安全：max-age=31536000；includeSubDomains
现在我也是一个很好的网站所有者，因此我设置了以下内容并使用 301 重定向到上述网站：
最后一个也有 HSTS 标头以及 https 站点。
据我了解，这是运行 https 网站的推荐设置（显然还有很多其他设置），并且相当常见。
到目前为止，一切都很好。
现在，在公司内部网中，无法在互联网上使用，我拥有大量服务器并使用 example.com 域。所以我有：
- machine1.example.com
- machine2.example.com ...等等
现在假设其中一些机器运行 Web 服务器，但并非所有机器都是 https。
这是否意味着如果我的任何员工碰巧来访https://example.com那么他们的浏览器将设置 HSTS 标头并拒绝访问任何子域的 http，因此无法再访问某些内部仅 http 网络服务器？
有什么办法可以解决这个问题？
我是否应该通过不使用includeSubDomains设置来损害我的外部网站安全？至少不是在https://example.com网站？为了内部问题而损害外部安全似乎是错误的。
我是否也应该强制所有内部应用都使用 https？这说起来容易做起来难。
我应该在内部使用不同的域名吗？例如 machine1.intraexample.com？这似乎浪费了一个域名，并且有些项目（例如电子邮件服务器）需要放在主域上，尽管如果他们甚至需要运行它们，可能它们可能会被限制在仅限 https 的 Web 服务器上。
还有其他想法吗？
此外，我认为这可能会给公司带来大问题，可能应该在规范和其他地方更加强调。许多网站所有者没有为非 www 版本设置单独的配置，因此可能会无意中在顶级域名上设置 includeSubDomain 标志。只有在实施前考虑到这种情况时，我才避免了这种情况。我最初会将到期时间设置得很短（一天），以解决这些问题，在我看来，这也是更有力的建议。这很容易被忽视，并给很多潜在的用户带来奇怪的问题。
2015 年 6 月编辑这里有一个真实的例子，说明一个网站在这件事上犯了错误： https://github.com/NuGet/NuGetGallery/issues/2535
编辑2015年10月的一篇文章建议您确实应该在TLD中使用includeSubDomains来解决cookie中的缺陷：http://www.kb.cert.org/vuls/id/804060。确实如此（否则，具有 DNS 访问权限的黑客可以创建一个虚构的子域，并利用它在 TLD 级别设置 cookie）。但是，上述对内部 HTTP 专用站点进行自我 DoS 攻击的风险仍然存在，并且这只会在您转到 TLD 或预加载 HSTS 时提供保护。
答案1
不使用 includeSubDomains 标志的方法意味着需要做更多的工作和纪律，但并不会造成危害，尤其是当您有理由这样做的时候。
您可以在每个不使用 includeSubDomains 的外部 HTTPS 服务器上明确设置 HSTS 标头。
此外，确保每个 HTTPS 服务器都有额外的 HTTP -> HTTPS 重定向。
但最佳做法是也对内部网站使用 https 流量。您可以使用自己的 CA 或不再那么昂贵的通配符证书。