假设我经营一家公司“Example Inc”，并有一个网站：
现在因为我是安全良心，我正在使用 https 并希望设置 HSTS 标头以强制使用它。我还会在很长一段时间内包含子域，比如说一年。
严格的传输安全性：max-age=31536000；包括子域
现在我也是一个很好的网站所有者，所以我设置了以下 301 重定向到上述网站：
最后一个也有 HSTS 标头以及它的 https 站点。
据我了解，这是运行 https 网站的推荐设置（显然还有许多其他设置），并且相当普遍。
到目前为止，一切都很好。
现在在内部，在公司内部网上，在 Internet 上不可用，我有大量服务器并使用 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）。然而，上述自我 DoSing 内部仅 HTTP 站点的风险仍然存在，这只会为您提供保护去 TLD 或预加载 HSTS。