angcz

@luny 社保断了会有什么影响吗 好像就是一些落户啥的会要求一直交社保？不让断的话 得自己去交 没有公司那部分 会很多吧

内存泄漏吧

得了吧，昨天一切照旧，不官宣，没人敢当弄潮儿

@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，内容应该是一样的？那样是不是会出现一个用户的客户端证书对应的私钥泄露后，所有用户都被波及的情况？