现在因为我是安全良心,我正在使用https,并希望设置HSTS标头以强制使用它.我还会包括子域名很长一段时间,比方说一年.
Strict-Transport-Security: max-age=31536000; includeSubDomains
现在我也是一个很好的网站所有者,所以我设置了以下301重定向到上面的网站：
> http://www.example.com
> http://example.com
> https://example.com
最后一个也有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网络服务器.
还有其他想法吗？
此外,认为这可能会给公司带来很大的问题,并且可能应该在规范和其他地方更多地突出显示.许多网站所有者没有非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的保护.
