angcz

@eason1874 我知道你说的意思，我没有在质疑算法的合理性，相关的文章我也看了很多了，只是有些细节我没有想明白，我觉得是自己没理解对，但是现在想不出来是哪里没想对而已。

@musi “客户端发出来的消息本身就是经过客户端的公钥加密的” 第二个客户端是不是写错了，应该是服务端？如果是的话，抓包软件作为中间人介入密钥协商过程，这时客户端是在把中间人当作服务端进行交互，所以客户端是用中间人公钥进行加密，中间人有私钥，自然也可以解密。

@ThirdFlame 假设使用的是 ecdhe 单向认证 抓包软件作为中间人与客户端交互 由于客户端实际是与抓包软件交互 所以抓包软件根据发送给客户端的中间人证书对应的私钥与之前交换的明文参数 不就可以算出对称加密密钥了吗？

@musi

感谢回复

不好意思 我没太懂你这里说的第二点是针对我的哪个回复的第二点 ssl pinning 的知识我有学习总结过，我可以在这里贴出来，但我没太明白这跟我的回复有什么关联。
（ Certificate Pinning：我们需要将 APP 代码内置仅接受指定域名的证书，而不接受操作系统或浏览器内置的 CA 根证书对应的任何证书。但是 CA 签发证书都存在有效期问题，所以缺点是在证书续期后需要将证书重新内置到 APP 中。解决方法是可以提供预置证书更新接口。在当前证书快过期时，APP 请求获取新的预置证书，这过渡时期，两个证书同时有效，直到安全完成证书切换。这种方式有一定的维护成本，且不易测试。
Public Key Pinning：公钥锁定则是提取证书中的公钥并内置到移动端 APP 中，通过与服务器对比公钥值来验证连接的合法性，我们在制作证书密钥时，公钥在证书的续期前后都可以保持不变（即密钥对不变），所以可以避免证书有效期问题。但是，这样不太符合周期性更新私钥的安全审计需求。一个折中的方法是，一次性预置多个公钥，只要任意一个公钥验证通过即可。考虑到我们的证书一般购买周期是 3-5 年，那么 3 个公钥，可以使用 9-15 年，同时，我们在此期间还可以发布新版本废弃老公钥，添加新公钥，这样可以使公钥一直更新下去。 ）

关于你说的第三点，双向认证和 ssl pinning 我清楚，也没有混淆，但是我还是没明白双向认证如何防止中间人攻击，可以看一下第 31 楼里倒数第二段的回复，我描述的这个流程，应该是有错误的，但是我没有想明白是哪个环节有问题，不好意思。

@marcoxuu

感谢回复

证书链的知识我有看过，我没有太明白这跟第 1，2 个问题的联系是？

如果如 eason 所说，客户端证书是内置在 app 里，那么也就是说所有用户，都共享一个客户端证书？因为我理解不同用户下载的 app，内容应该是一样的？那样是不是会出现一个用户的客户端证书对应的私钥泄露后，所有用户都被波及的情况？

如果如您所说，文中第四步是使用服务端公钥加密客户端公钥的话，那假设中间人是拦截了客户端 client hello，自己向服务端发送 client hello，然后接受了服务端证书，并将自己的证书返回给客户端，客户端信任了这个证书（假设客户端即使开启了 ssl pinning 也被 hook 关闭了），然后客户端用中间人公钥加密自己的证书，中间人收到加密后的证书，然后用自己的私钥解密，并用服务端的公钥加密，返回给服务端，服务端将加密方案用客户端公钥加密发送给中间人，中间人透传给客户端，客户端解密后用中间人公钥加密对称加密密钥参数，然后发送给中间人，中间人根据之前的参数和自己的私钥，不就可以算出对称加密密钥了吗？

当然我上面的理解肯定存在错误，还请指正。

@eason1874 感谢回复，客户端证书是内置在 app 里，那么也就是说所有用户，都共享一个客户端证书？因为我理解不同用户下载的 app，内容应该是一样的？那样是不是会出现一个用户的客户端证书对应的私钥泄露后，所有用户都被波及的情况？

@des

感谢回复

关于第 1，2 点，您说的很清楚，其实我更关心的是移动端的情况下，客户端证书是怎么处理的，是否是如同上面所回复的，是客户端安装后生成，私钥保密，公钥发送给 ca，请求生成证书？如果是的话，那这个发送请求的过程，是怎么保证安全的？

关于第 3，4，5 点，我确实没有说清楚，其实我讨论的是我用抓包软件抓双向认证明文的情况，也就是说抓包软件作为中间人，介入了双向认证过程的情况。假设双向认证过程中，抓包软件只是拦截了服务端发送给客户端的证书，将其替换成自己动态生成的证书，其余信息都是透传的，并且客户端也信任了这个证书（假设客户端就算开启了 ssl pinning 但是被 hook 更改了）。那么第 3 点，之所以能解密，是因为假设抓包软件作为中间人，那么“服务端”私钥，其实就是中间人的私钥。第 4 点，因为没有替换证书，只是把客户端证书透传给了服务端，所以服务端也可以正常验证通过。关于第 5 点，确实，抓包软件的原理虽然是充当中间人，但是跟中间人不完全一样，所以我们可以简单地就视作现在是在考虑中间人攻击的情况。

关于第 6 点，假设用的是基于 dh 的 ecdhe，也就是说根据明文的四个参数无法算出密钥，而只要握手双方根据自己的私钥加明文参数，就可以算出对称加密密钥，因为客户端实际是将中间人当成服务端在交互，所以中间人用自己的私钥加公开参数，就可以算出对称加密密钥。

当然我上面的理解肯定存在错误，还请指正。

@musi

感谢回复

关于第 2 点，双向认证时，客户端证书是直接内置在 app 里的，对于不同的用户，app 内容应该是不变的吧？也就是说所有用户都是共享一个客户端证书？那样是不是会有很大的风险？还是说如同上面的回复，客户端证书其实是客户端安装后生成的，私钥保存在本地，通过向 ca 发送请求得到证书？

关于第 3 点，确实“之前已经把服务端证书替换成抓包软件证书”这句话我表达有问题，会让人产生误会，我指的其实是发给客户端的服务端证书实际上是抓包软件生成的证书。

我想了下，发现我之所以会有这样的疑问，应该是由于在网上看到了不同版本的抓包软件原理的图，其中第一种是如您所说，也就是这里（ https://zhuanlan.zhihu.com/p/67199487 ）的图；第二种是如这里（ https://github.com/youngwind/blog/issues/108 ）所说。这两者的区别是，客户端向服务端发送请求的过程，第一种说是被抓包软件拦截，然后抓包软件再向服务端发送请求；第二种是说抓包软件把这个请求透传给了服务端。我上面的疑问其实都是基于第二种展开的。

你们要是真的觉得我有问题 你们有水平 就指出我的问题啊？一副自己很懂 我一文不值的样子 又不做任何详细的解释...这就是我为什么不想在网上发言 无论是讨论什么 只要大家不相识 不用在意面子 可以随便发言 就总会有人能让别人不舒服