Ssl 移动应用中的公钥锁定与证书锁定

情景：

• 我在android应用程序中锁定了3个证书的公钥pin SHA：根CA、中间CA和叶CA

我所理解的（如果我在这里说错了，请纠正我）：

• 使用公钥固定，以便我们可以检查服务器正在颁发的证书的公钥是否已更改

• 如果证书的公钥SHA是我们在应用程序中“固定”的公钥，则该证书有效。要检查公钥，首先它将使用公钥解密签名，并确保该签名的数据中也存在相同的公钥

• 当叶证书已过期但与有效的“固定”公钥SHA相对应时，将检查证书链是否有效，如果其中一个证书有效，则接受证书并建立连接

• 当我获得的叶证书具有无效的公钥但未过期时，则意味着我从可能是攻击者的人那里获得了错误的证书

问题:

• 如果攻击者破坏客户端并安装自己的受信任CA，然后在客户端上执行MITM，通过出示自己的伪造证书（由安装在客户端设备上的CA签名）来拦截所有通信，则公钥固定是否有助于安全性

• 直接证书钉扎和公钥钉扎在这里有什么不同

• 在上述问题中使用自签名证书意味着什么

请尽可能详细地帮助我理解这一点

当叶证书已过期但与有效的“固定”公钥SHA相对应时，将检查证书链是否有效，如果其中一个证书有效，则接受证书并建立连接

不接受。不接受过期证书。固定不会覆盖TLS的基本原则，但会增强它以减少接受的证书数量

如果攻击者破坏客户端并安装自己的受信任CA，然后在客户端上执行MITM，通过出示自己的伪造证书（由安装在客户端设备上的CA签名）来拦截所有通信，则公钥固定是否有助于安全性

对于浏览器，手动安装的受信任CA不受固定要求的约束。对我来说，这是固定的一个根本缺陷。不过老实说，一旦你有权在机器上安装根证书，游戏就差不多结束了。无论如何，这个例外是必要的，以允许病毒扫描程序、公司代理和其他拦截代理工作-否则，任何固定的网站无法访问时，背后的这些代理之一，虽然它确实削弱了HPKP（HTTP公钥Pining）在我心目中

对于应用程序（您的用例），钉扎可用于防止MITM攻击

直接证书钉扎和公钥钉扎在这里有什么不同

你不明白吗？当您锁定一个直接证书时，您基本上锁定了该证书的公钥（实际上，证书链接的私钥的SHA）

这意味着您可以从相同的私钥（IMHO中的错误做法）重新颁发证书，而不必更新PIN

您还可以从中间公钥甚至根公钥进行pin。这意味着您可以让您的CA重新颁发证书，而无需再次更新pin。这当然会将您与该CA联系在一起，但至少不允许一些随机CA为您的站点颁发证书

在上述问题中使用自签名证书意味着什么

对于浏览器，锁定基本上不能与自签名证书一起使用。因为浏览器无法识别它（因此锁定不起作用），或者通过手动安装颁发者来信任它-在这一点上，根据上面的点，锁定被忽略

对于应用程序（同样是您的用例），我知道可以固定自签名证书。尽管这取决于您使用的HTTP库以及如何配置

固定证书本身的一个缺点（如果是单泄漏自签名证书，这可能是唯一的方法），就是重新颁发证书将使旧的PIN无效（除非您重用相同的私钥，但如果重新颁发的原因是密钥泄露，则这可能是不可能的）。所以，如果您的应用程序进行HTTP呼叫总部以检查是否有新版本或类似版本，那么如果重新颁发证书并且尚未下载应用程序的新版本，则该呼叫可能会失败

几乎所有浏览器都不推荐HPKP，因为与其优点相比，HPKP的风险非常高，而且有许多因固定而损坏的案例。请参阅维基百科：。通过监视错误颁发的证书被视为更安全的选择

---

在移动应用程序领域，钉住似乎仍然有点流行，因为你对应用程序有更大的控制权，并且可以在出现问题时重新发布新版本。但这仍然是复杂和危险的。

“锁定基本上不能与自签名证书一起使用。因为它要么不被浏览器识别”。那么移动应用程序呢？在移动应用程序中，我们从根到叶锁定所有证书的公钥SHA。你能更新你的答案吗？很抱歉，我错过了这是一个应用程序，而不是浏览器。答案已更新。@Barry Pollard如果我理解正确，对于移动应用程序，如果我只锁定根公钥SHA而不是所有3个公钥SHA，它仍然可以工作，因为即使叶端和中间端号由于信任链而丢失，也会看到根端号匹配，因此会起作用？关于公司的手动安装的受信任CA