我已将HPKP header 添加到我的网站，但Chrome或Safari不推荐使用。我通过设置代理并转到chrome://net-internals/#hsts并查找我的域(未找到)来手动对其进行测试。 HPKP似乎正确，我也使用HPKP toolset对其进行了测试，因此我知道它是有效的。
我想我可能在做一些奇怪的事情。我有一个网络应用程序，可通过myapp.example.com提供。登录后，该应用会将用户重定向到authserver.example.com/begin以启动OpenID Connect授权代码流。 HPKP header 仅从authserver.example.com/begin返回，我认为这可能是问题。我在HPKP header 中有include-subdomain，所以我认为这不是问题。
这是HPKP header (添加了换行符以提高可读性):
public-key-pins:max-age=864000;includeSubDomains; \
pin-sha256="bcppaSjDk7AM8C/13vyGOR+EJHDYzv9/liatMm4fLdE="; \
pin-sha256="cJjqBxF88mhfexjIArmQxvZFqWQa45p40n05C6X/rNI="; \
report-uri="https://reporturl.example"
谢谢!
最佳答案
我在网站上添加了HPKP header ，但是Chrome或Safari并没有使用它。我通过设置代理进行了手动测试。
RFC 7469, Public Key Pinning Extension for HTTP，那种偷偷摸摸的过去。 IETF对其进行了覆盖，因此攻击者可以破坏已知的良好密码集。它在标准中曾经通过名称“override” 提及过，但未提供详细信息。 IETF也未能在安全注意事项部分中发布讨论。
更重要的是，您设置的代理使用了替代功能。不管是错误的代理，由移动设备OEM安装的代理证书还是由诱骗用户安装它的攻击者控制的代理，都没有关系。网络安全模型和标准允许它。他们接受拦截并将其视为有效的用例。
他们所做的其他事情是将断针的报告设置为“不得”或“不应该”。这意味着用户代理在掩盖中也是同谋。安全注意事项部分也没有讨论。他们真的不希望人们知道他们所谓的安全连接已被拦截。
避免这种情况的最佳选择是移出网络安全模型。当出于安全考虑时，请不要使用基于浏览器的应用程序。使用混合应用程序并自行固定。您的混合应用程序可以承载WebView控件或 View ，但仍然可以访问通道以验证参数。另请参见OWASP's Certificate and Public Key Pinning。
另请参阅IETF邮件列表上的Comments on draft-ietf-websec-key-pinning。注释中的建议之一是将标题更改为“带有覆盖的HTTP的公钥固定扩展”以突出显示该功能。毫不奇怪，这不是他们想要的东西。他们试图在没有用户知识的情况下 secret 进行此操作。
这是RFC 6479中的相关文本:
2.7。与预加载的引脚列表的交互
UA可以选择实施其他固定来源
信息，例如通过固定信息的内置列表。
此类UA应该允许用户覆盖此类其他来源，
包括禁止他们考虑。
具有内置的已知固定主机的有效策略
来自先前观察到的PKP header 响应字段的引脚和引脚为
实现定义的。