我在我的网站上添加了HPKP标题，但Chrome或Safari并不尊重它。我通过设置代理并转到chrome://net-internals/#hsts并查找我找不到的域名来手动测试。 HPKP似乎是正确的，我也使用HPKP toolset进行了测试，所以我知道它是有效的。
我在想我可能会做一些奇怪的事情。我有一个网络应用程序，通过myapp.example.com提供。登录时，应用程序会将用户重定向到authserver.example.com/begin以启动OpenID Connect授权代码流程。仅从authserver.example.com/begin返回HPKP标头，我认为这可能是问题所在。我在HPKP标题中有include-subdomain，所以我认为这不是问题。
这是HPKP标题（为了便于阅读而添加了换行符）：
public-key-pins:max-age=864000;includeSubDomains; \
pin-sha256="bcppaSjDk7AM8C/13vyGOR+EJHDYzv9/liatMm4fLdE="; \
pin-sha256="cJjqBxF88mhfexjIArmQxvZFqWQa45p40n05C6X/rNI="; \
report-uri="https://reporturl.example"
谢谢！
答案 0 :(得分：1)
我在我的网站上添加了HPKP标题，但Chrome或Safari并没有兑现它......我通过设置代理手动测试了它...
RFC 7469, Public Key Pinning Extension for HTTP，有点偷偷溜过你。 IETF以覆盖的方式发布了它，因此攻击者可以打破已知的良好pinset。它在标准中提到了一次名称 ＆＃34;覆盖＆＃34; ，但未提供详细信息。 IETF也没有在安全考虑部分发表讨论。
更重要的是，您设置的代理使用了覆盖。无论是错误的代理，移动设备OEM安装的代理证书，还是欺骗用户安装它的攻击者控制的代理都没关系。 Web安全模型和标准允许它。他们接受拦截并认为它是一个有效的用例。
他们所做的其他事情是将损坏的pinset报告为 Must Not 或不应该。这意味着用户代理也是掩盖中的同谋。这也没有在安全考虑部分讨论过。他们真的不希望人们知道他们所谓的安全连接正在被截获。
避免它的最好办法是移出网络安全模型。当安全性受到关注时，不要使用基于浏览器的应用程序。使用混合应用程序并自行执行固定。您的混合应用程序可以托管WebView控件或视图，但仍可以访问该通道以验证参数。另请参阅OWASP's Certificate and Public Key Pinning。
另请参阅IETF邮件列表中的Comments on draft-ietf-websec-key-pinning。评论中的一个建议是将标题更改为＆＃34; HTTP的公钥固定扩展和覆盖＆＃34; 以突出显示该功能。毫不奇怪，这不是他们想要的东西。他们试图在没有用户知识的情况下秘密进行。
以下是RFC 6479的相关文字：
2.7。与预加载的引脚列表的交互
UAs可以选择实施额外的钉扎源 信息，例如通过内置的钉扎信息列表。 此类UA应允许用户覆盖此类其他来源， 包括禁止他们考虑。
具有内置功能的已知固定主机的有效策略 来自先前观察到的PKP报头响应字段的引脚和引脚是 实现定义的。
答案 1 :(得分：1)
本地安装的CA（就像您说的那样用于代理的CA）会覆盖任何HPKP检查。
这是必要的，以便不会完全打破互联网，因为它们普遍存在：大型企业中使用的防病毒软件和代理基本上MITM通过本地颁发的证书https流量，否则他们无法读取流量。
有些人认为在本地安装CA需要访问您的计算机，并且此时它仍然是游戏，但对我而言，这仍然大大降低了对HPKP的保护，并且加上使用的高风险HPKP，意味着我真的不喜欢它。