关于 https 双向认证的细节

[angcz]

最近看了下 https 双向认证，有些点没搞懂，还请大家指教一下。

1.客户端证书是怎么生成的？
看网上说是由颁发服务端证书的 ca 生成的，感觉应该不对吧？也许实际应用中是用服务端自签名证书生成的？

2.客户端证书是怎么安装到客户端的？
分 app 和网页两种情况；对于不同的用户，安装的 app 应该都是一样的吧，那就是说大家用的都是同一个客户端证书，感觉不对吧？而且如果是安装时内置的话，那网页要怎么办呢，网页没有安装的过程吧？所以应该是安装之后生成的？但是生成又需要 ca 私钥，这东西不可能内置在客户端，那是通过网络传给客户端的吗，这样没法保证安全，应该也不是的吧？

3.双向认证怎么防止抓包的呢？
以这里 https://cloud.tencent.com/developer/article/1171381 第五节的图为例，我如果抓包，只要把 4 和 6 透传给服务端，然后把 8 透传给客户端，不就能正常拦截到 9 （之前已经把服务端证书替换成抓包软件证书），也就拿到了对称加密密钥了吗？

再次感谢大家指导。

[commoccoom]

之前自己按照 https://www.jianshu.com/p/2b2d1f511959 配置了一下，浏览器使用 Firefox，安装自定义证书方便，至于原理不太清楚了😂

[angcz]

刚才想了下...第 3 步里 如果透传的话 那就拿不到选择的加密方案了 不过加密方案的数量应该是有限的吧？遍历一遍应该也不是什么问题？

[ThirdFlame]

1 、客户端证书 也是 CA 签发生成的。 当然你如果自签发 ，ca 不也就是你自己么
2 、按照标准 每一个用户应该有自己的客户端证书。 硬件设备（如 pos 机 等 设备）直接写在安全新芯片内的。 网页的 一般通过其他渠道提供给客户由客户自行安装。
3 、单向认证 抓包你也得不到 对称加密的密钥的。

[angcz]

@commoccoom 这个我看了的，他操作都是在本地，服务端客户端都是自己，就没有了客户端获得客户端证书这一步，在实际应用中，怎么确保客户端安全地获得客户端证书呢？

[commoccoom]

[那就是说大家用的都是同一个客户端证书] ，客户端证书可以不同，但是用同一个 CA 签发，可以在服务器上注销某个客户端证书而不影响其他证书

[billlee]

1. 正常应该应该是由客户端生成证书请求，然后提交给 CA, 让 CA 确认。整个过程中私钥不离开客户端。

当然这里 CA 是谁就是另说了，如果是客户端应用，可以自己内置受信任的 CA, 如果是浏览器，那就是要浏览器认可的“真” CA. 只要双方都认可这个 CA 就行。

2. 上面已经说了，正常流程是客户端自己向 CA 申请，只提交公钥，私钥不离开客户端。

3. 正确的实现下，伪造的 CA 不受客户端 /服务器认可，握手会失败。反正整个证书体系都是依赖 CA 的可靠性的。

[angcz]

@ThirdFlame 感谢回复，关于第二点，硬件的很好理解，但软件要怎么做呢？这个“其他渠道”我并没有太懂，以支付宝为例，我们安装 app 或者登录网页后，就可以登录支付了，并没有显式地额外获取一个信息的过程。（其实我想到了在电脑上用支付宝好像需要安装支付宝证书？我记得不是很清楚了，不知道跟我们讨论的问题有没有关联）

[opengps]

https 不防止抓包，只是防止抓包看到的是明文

[angcz]

@billlee
感谢回复。

感觉您说得很清楚了，客户端密钥对是在客户端生成，证书是通过向 ca 请求得到的，并且因为代码判断仅接受某些 ca 颁发的证书，所以也不出现信任了抓包软件的根证书，然后接受了抓包软件生成的客户端证书这种情况。

然而还有个问题我没太懂，就是第 3 个问题，如帖子里所说，如果我用一个抓包软件想抓双向认证的包，在服务端校验客户端证书的过程中，只是透传信息，那最终还是可以得到生成的对称加密密钥？

[angcz]

@billlee 哦，我有点傻了，您的意思是，代码里判断只接受某些 ca 颁发的证书？所以就不出现手机信任了抓包软件的根证书，从而导致 app 信任了抓包软件生成的证书的情况？但这点好像就跟双向认证无关了，也就是说能做到这点的话，即使不做双向认证，也可以防止抓包，那双向认证的意义是什么呢？

[3dwelcome]

"那网页要怎么办呢，网页没有安装的过程吧？"
你没遇到过这类网页，是对客户端进行证书申请，和要求输入密码是一样的，客户端证书=客户端授权，和你用证书登录 ssh 服务器是一回事。

chrome 和 firefox 都有安装和管理客户端证书的地方。

"即使不做双向认证，也可以防止抓包，那双向认证的意义是什么呢？"
就是免输入密码来鉴权。

[Biwood]

建议自己下载 Wireshark 抓包看看，并配合 wikipedia 上的 TLS 词条或者其他权威的英文文档来理解，哪怕看的是译文也比这些不知道被转载了多少次的所谓“干货”强。有可能第一个转载的人本身就一知半解，后面转载的人又以讹传讹，结果添油加醋，越写越复杂，其实根本没那么复杂。

[des]

典型的看的太少想的太多，可以先从非对称加密开始看

[wdlth]

@angcz 你把双向认证和 SSL Pinning 弄混了吧，你是想问 SSL Pinning 么？

[eason1874]

普通 HTTPS 是单向认证，信任系统信任 CA 签发的证书，所以在系统添加自签 CA 证书之后，通过自签证书代理请求就可以监听。

为了防止上述情况，可以在 APP 代码内置信任 CA 指纹，通常叫公钥固定或者 SSL Pinning 。这样一来，在系统信任了中间人自签证书也不管用，因为 APP 不信任。

但是 SSL Pinning 可以通过 hook 系统 API 去关闭（现成工具很多），一旦关闭，又回到普通单向认证了。

这时双向认证就要上场了，生成 CA 证书部署在服务器，然后使用 CA 自签客户端证书给 APP 使用，开启双向认证后服务器就只接受客户端证书的请求。这样一来，替换证书进行抓包就不管用了，只能先脱壳拿到真实的客户端证书。

没有 100%理论安全的，双向认证也只是加大难度而已，双向认证排除脚本小子，APP 加固提高脱壳难度。

一般双向认证的 CA 是自己生成的，客户端证书是拿这个 CA 自签的，内置在 APP 里。APP 不同版本可以签发不同的客户端证书去用，迭代到一定程度就把老版本的证书进行吊销（版本更新 API 不用双向认证，确保无证书也有提示）。

[billlee]

@angcz 双向认证和防抓包是没有关系的。双向认知和单向认证的区别，在于服务端可以通过证书识别客户端的身份。如果是单向认证，服务端就需要通过类似用户名密码之类的额外凭据来识别；如果是双向认证，根据客户端证书就可以了。

典型的用途就是银行 U 盾，连接 U 盾后只要用 U 盾密码解锁 U 盾，就可以完成身份认证。

[angcz]

@ThirdFlame 关于第 3 点，确实如果用 ecdhe，那得到了公开参数，也无法算出对称加密密钥，那这种情况下抓包软件是怎么抓到 app 的流量的呢？

[marcoxuu]

@des 赞同，提问很明显没有了解非对称加密算法的公钥签名私钥验证的过程，以及 pki 系统的基本原理

[angcz]

@des
@marcoxuu
我真是够了 我本来不想理你们的 我在学校时上过密码学以及网络安全的课程 这些东西我都系统学习过 只不过很久没接触忘记了 我现在是从“如何防止抓包软件抓包明文”这个问题出发 发现最安全的方案是双向认证 然后对双向认证的细节有些疑问而已 这些实现细节学校里是不会涉及的 网上随便搜搜也找不到 我估计你们觉得我没有基础 是因为我上面的一些发言是没有思考过程 只说了一个结论 以及 des 能不能说话不要这样 上来就是一句贬低 就是你们这种人让网络环境变得差的好吗 就事对事行不行？

[angcz]

我是真的没搞懂你们是从那句话觉得我连非对称加密对称加密都不懂的？？