nginx SSL和hsts问题

如何解决nginx SSL和hsts问题

我已经有一个没有SSL的Nginx SSL。 但是在后端，很少有服务不是https。 启用HSTS是否有任何潜在风险？ 我担心HSTS标头存在时，HSTS标头会中断内部路由，强制重定向到HTTPS

例如

当前：

公共用户-> https://www.123.com-内部服务---> Http://internalA.123.com-> Http://internalA.123.com

它会变成下面吗？

公共用户->“ https://www.123.com” ---内部服务---> Https://internalA.123.com-> Https://internalA.123.com

如果是，则该服务肯定会因HSTS而中断

解决方法

HSTS仅与客户端（浏览器）和Web服务器（nginx）之间的连接有关。服务器随后如何处理接收到的数据，即数据是在本地处理还是服务器只是其他服务器的反向代理，这无关紧要。客户端和服务器之间的类似HTTPS只能保护这两者之间的通信，并且既不能保护来自反向代理的任何进一步的连接，也不能保护服务器端对数据的本地处理。

,

HSTS是从服务器（nginx）到客户端（浏览器）的一条指令，指示“嘿，下一次，假设我使用HTTPS。”因此，在上述情况下，它不会像Steffen所说的那样用于后端连接。

但是绝对有一些危险需要注意：

首先，如果您在顶级域（例如123.com）上进行设置并使用includeSubDomains，那么123.com上的每个域都可能会突然受到HSTS保护。这可能仍然不会影响您的后端连接，但是，如果您碰巧在浏览器中访问https://123.com（也许您只是在URL栏中键入了该内容）并选择了标头，然后尝试访问http://intranet.123.com或http://dev.123.com甚至http://dev.123.com:8080，然后它们都将重定向到HTTPS，如果它们不能通过HTTPS使用，则它们将失败，并且您将无法再访问这些站点。由于可能没有太多人访问裸域，所以这很难跟踪，因此它“对我来说很好”。

当然，如果您仅在该域中的所有站点（包括所有内部站点）上使用HTTPS，那么这不是问题，但是如果没有...

作为一种额外的保护，您还可以将站点提交到预加载列表，然后在下一个发行版中将其硬编码到浏览器中，并且其他一些客户端也使用此硬编码列表。尽管这是一种额外的保护，但它带来了额外的风险，因为其中的一项要求是includeSubDomains中包含了顶级域。我知道您还没有问过这个问题，但是既然您在问这个问题的风险，我认为在这里值得一提。因此，通过预加载HSTS，即使没有 访问https://123.com来获取标头，它也会突然带来所有上述风险。而且，由于浏览器版本之间相隔数月（甚至数年），这基本上是不可逆的。您可能很高兴在您的www域上运行HSTS，认为一切正常，并决定升级到预加载列表，原因是您没有看到任何问题，并且突然在下一个浏览器版本中，所有仅HTTP内部站点停止了工作正常，您需要立即升级所有HTTPS，否则将无法访问它们。

总而言之，如果当前仍有一些仅使用HTTP的站点，请注意HSTS。考虑只将其退回需要它的网站（例如https://123.com 不 includeSubdomains和https://www.123.com includeSubdomains）并预加载时要格外小心。我个人认为预加载对于大多数网站来说都是多余的，但是如果您确实想这样做，那么最佳实践是首先从首页上的https://123.com加载资源，并尽量少增加它，然后慢慢增加它。这样，每个人都可以在将其提交到预加载列表之前进行选择，这不会让人感到惊讶。

但是HSTS很好，应该在所有面向公众的网站恕我直言上使用，我不希望这个答案让您失望-只是了解它的工作原理以及由此带来的风险。