为什么选择 HSTS？

HSTS 旨在保护的弱点是首先通过 HTTP 发出请求连接到服务器的客户端，并且预计将被重定向到 HTTPS 版本（或 404）。攻击者可以 MitM 该请求，而不是发送重定向，而是通过 HTTP 发送（可能已修改）站点。

通过 HTTP 的连接可以打开有多种原因：

• SSL-strip 等攻击。
• 在 URL 栏中输入 HTTP 地址的人
• 到 HTTP 的硬编码链接。

这些是否会影响服务器？第三个可能，但这取决于您是否完全控制连接到服务器的所有软件。

如果你有完全的控制权

只需确保曾经使用的所有 URL 都是 HTTPS。如果它们是从配置文件中读取的，请明确检查它们是否不是 HTTP。这消除了对 HSTS 的需求。当您使用它时，您应该确保您只接受安全密码套件，并且可能考虑实施证书或公钥固定。

如果您没有完全控制权

假设其他人编写连接到您的服务器的软件。你不知道这些人是否知道他们在做什么。他们可能会不小心在某处发出 HTTP 请求。

如果他们使用的库实际解释和执行 HSTS 标头（负责执行 HSTS 的是客户端），这些人在打开 HSTS 时会更安全。但这仍然是一种边缘情况——如果你给出 404 答案而不是对 HTTP 请求进行重定向，那么很难想象为什么有人会编写制作它们的软件。我还怀疑大多数库都忽略了 HSTS 标头。但谁知道呢！

如果没有人使用浏览器使用该界面，HSTS 可能不会对您的情况产生影响。

如果您控制客户端（在您的情况下是另一台服务器），您可以只请求 HTTPS URL 而从不请求 HTTP 请求。客户端是否支持 HSTS 也是值得怀疑的。它在许多浏览器中实现，但在 HTTP 库中并不多。

它可以产生影响的一种方法是服务器是否从 HTTPS 重定向到 HTTP。启用 HSTS 后，支持的客户端将不会遵循重定向。

由于听起来您只需要 HTTPS，因此您可能需要禁用 HTTP 服务。

在服务器和客户端应用程序是定制开发和控制的场景中，没有HSTS 可以缓解的威胁模型。

传输的双方都应该配置适当的证书，并且应该在不依赖 HSTS 的情况下防止协议降级。

引入 HSTS 是为了防止通过完全禁用 SSL 或将协议降级到较低（不安全）版本来防止绕过 SSL，在这种情况下，用户访问他们拥有信息或技术技能来评估保护级别的远程服务器。

最后，如果客户端应用程序不支持 HSTS，打开它不会有任何影响。