3

我将 HPKP 标头添加到我的网站，但 Chrome 或 Safari 不支持它。我通过设置代理并转到chrome://net-internals/#hsts并查找我的域来手动测试它 - 没有找到。HPKP 似乎是正确的，我还使用HPKP 工具集对其进行了测试，因此我知道它是有效的。

我在想我的流程可能会做一些奇怪的事情。我有一个网络应用程序，它通过myapp.example.com. 登录时，应用程序将用户重定向authserver.example.com/begin到启动 OpenID Connect 授权代码流。HPKP 标头仅从返回authserver.example.com/begin，我认为这可能是问题所在。我include-subdomain在 HPKP 标题中，所以我认为这不是问题。

这是 HPKP 标头（为便于阅读添加了换行符）：

public-key-pins:max-age=864000;includeSubDomains; \
pin-sha256="bcppaSjDk7AM8C/13vyGOR+EJHDYzv9/liatMm4fLdE="; \
pin-sha256="cJjqBxF88mhfexjIArmQxvZFqWQa45p40n05C6X/rNI="; \
report-uri="https://reporturl.example"

谢谢！

4

2 回答 2

1

我在我的网站上添加了 HPKP 标头，但 Chrome 或 Safari 不支持它...我通过设置代理手动对其进行了测试...

RFC 7469，HTTP 的公钥固定扩展，有点偷偷摸摸。IETF 使用覆盖发布它，因此攻击者可以破坏已知良好的 pinset。它在标准中被称为“覆盖”一次，但未提供详细信息。IETF 也未能在安全考虑部分发表讨论。

更重要的是，您设置的代理参与了覆盖。不管是错误的代理、移动设备 OEM 安装的代理证书，还是由攻击者控制的代理，诱使用户安装它。Web 安全模型和标准允许这样做。他们接受拦截并将其视为有效的用例。

他们所做的另一件事是将损坏的针组的报告设为“不得”或“不应该”。这意味着用户代理也是掩饰的同谋。这也没有在安全考虑部分讨论。他们真的不希望人们知道他们所谓的安全连接正在被拦截。

避免它的最佳选择是移出网络安全模型。当安全是一个问题时，不要使用基于浏览器的应用程序。使用混合应用程序并自己执行固定。您的混合应用可以托管 WebView 控件或视图，但仍可以访问通道以验证参数。另请参阅OWASP 的证书和公钥固定。

另请参阅IETF 邮件列表上对 draft-ietf-websec-key-pinning 的评论。评论中的一项建议是将标题更改为“具有覆盖的 HTTP 的公钥固定扩展”以突出显示该功能。毫不奇怪，这不是他们想要的。他们试图在用户不知情的情况下秘密进行。

以下是 RFC 6479 中的相关文本：

2.7. 与预加载引脚列表的交互

UA 可以选择实现额外的固定信息来源，例如通过内置的固定信息列表。此类 UA 应允许用户覆盖此类附加源，包括禁用它们。

对于既具有内置引脚和来自先前观察到的 PKP 标头响应字段的引脚的已知固定主机的有效策略是实现定义的。

于 2017-03-24T02:08:06.177 回答
1

本地安装的 CA（如您所说的用于代理的那些正在运行的 CA）会覆盖任何 HPKP 检查。

鉴于它们的流行，这是必要的，以免完全破坏互联网：大公司中使用的防病毒软件和代理基本上是通过本地颁发的证书进行 MITM https 流量，否则他们无法读取流量。

有人争辩说，本地安装 CA 需要访问您的计算机，到那时它无论如何都结束了，但对我来说，这仍然大大降低了对 HPKP 的保护，再加上使用 HPKP 的高风险，意味着我真的不是它的粉丝。

于 2017-03-24T05:44:19.357 回答