有没有办法绕过 HTTP 严格传输协议（HSTS）现在已被许多网站使用，例如 Google 服务、银行服务等？
我知道 HSTS 协议强制 Web 客户端使用安全传输 (HTTPS)，即证书、密钥以加密形式发送。是否可以以纯文本格式? Web 服务器会接受它作为纯文本
我偶然看到一篇博客，上面说通过在网络中实施 MITM（中间人）攻击可以实现这一点。这是真的吗？
答案1
HTTP 严格传输安全性的目的，在RFC 6797，是为了确保请求按照相应站点的策略安全地发送。它本身并不是一个安全协议；它只是指示 Web 浏览器在特定主机和预定的时间段内强制使用安全传输 (HTTPS) 而不是不安全传输 (HTTP)。
有几种方法可以禁用主机的 HSTS，但它们都需要访问加密 HTTPS 流的纯文本数据。这基本上意味着，如果您能够禁用主机的 HSTS，那么您已经能够操纵与该主机的通信，因此您无需禁用该主机的 HSTS。
最明显的可能性是 RFC 中明确规定的第 6.1.1 节，将 max-age 指令设置为 0。这将导致兼容的客户端（Web 浏览器）从其已知 HSTS 主机列表中删除主机名。
另一种方法可能是直接操纵浏览器的 HSTS 存储浏览器供应商可以使用各种加密技术（代码已经编写好，因为 HTTPS 无论如何都需要它）或通过特权分离来使这种情况变得更加困难。
但是，即使你这样做，HSTS 标头和/或永久重定向到使用 HTTPS 也可能会在下次对同一主机的请求中重新传输，这将导致客户端重新建立主机的安全状态在服务器指定的时间内。
RFC 的第12节为客户提供实施建议。特别是，第12.1节表示如果出现与安全相关的错误，用户不应寻求帮助。
但是，由于 HSTS 只是一种告诉客户端对于给定主机名使用 HTTPS 而不是 HTTP 的机制，所有针对 HTTPS 的相关攻击仍然存在。例如，这意味着如果您可以控制客户端的根证书存储，或者如果您能够为控制私钥的主机获取证书，那么您就可以成功地对此类会话进行 MITM。这不受特定主机名上是否存在 HSTS 的影响。
通过实施适当的DNSSEC结合客户做适当的丹麦（RFC 6698，RFC 7218) 验证。例如，HSTS、DNSSEC的正确验证和DANE的正确验证的组合可能会使联想的SuperfishSSL 拦截代理不可能。