19 | TLS的各种特性：TLS握手为什么会失败？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
HTTPS/TLS是网络安全领域的关键技术，通过对称加密和非对称加密的综合利用，实现了数据的安全传输。本文深入介绍了TLS握手失败的问题排查思路，强调了排查思路和技术细节的重要性。通过实例分析了TLS握手失败的问题，突出了排查思路和技术细节的重要性。读者可以通过本文快速了解HTTPS/TLS的工作原理、常见问题和排查思路，对于需要深入了解HTTPS/TLS工作原理的读者具有很高的参考价值。文章还详细介绍了TLS证书链和TLS证书签名的相关知识，通过实例分析了证书过期导致的问题，并提供了解决方案。整体而言，本文内容丰富，技术深入，对于网络安全领域的从业者具有很高的参考价值。文章还提供了排查技巧和思考题，帮助读者更好地理解和应用所学知识。
《网络排查案例课》，新⼈⾸单¥59
全部留言(11)
- 最新
- 精选
孙新如果有扩展的兴趣，荐书: 《图解密码技术》 《深入浅出HTTPS从原理到实战》 图解密码技术是当年做银行项目买的，银行对密码这块用的比较多，还有专门的加密机用来硬加密硬解密。密码技术可以从老师最后总结这块扩展开来，讲的很系统，也很形象，和当年《图解TCP/IP》也是同期买的。这本书看完了以后密码相关的原理理解和使用应该没什么问题。市面上专门深入讲解HTTPS的书不多，可以参照这本，详细可以去豆瓣了解一下。作者回复: 谢谢，你的推荐也非常好：） 密码技术确实是比较冷门的，其实一般不是专门做加解密开发的话，也很难有机会学到很细节的知识，所以你推荐的这两本书很有用~
2022-03-0923
Realm问题1 ： * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): 其中OUT代表发包，IN代表收包 问题二： 不会，无“根”之木，是不行的。作者回复: 问题1：很详细，依次是OUT, IN, OUT, IN，是四次握手：） 问题2：对，这个会验证失败。
2022-03-0423- Geek6561问题1比较肤浅的理解：TLS应该是4次握手（client hello， serverHello、cert share，finish），TLS RSA 和TLS1.2 的ECDHE都是这种，如果是TLS 1.3的 Diffie-Hellman，4次还是5次不太确定了。TLS太复杂了，这一块的东西，老师有分享的打算吗？ 问题1：如果客户端没有这个根证书，是不会信任服务端返回的证书链的。因为PKI的基础就是权威CA的合法性。 另外，老师，前面curl的返回中：common name: server (does not match 'api.server.777.abcd.io')，这个有影响吗？
作者回复: 问题1你的答案是对的。TLS一般来说是4次握手，如果没有session reuse等情况的话。当然这也不是必然的，比如TLS1.2也可以做到1RTT，甚至TLS1.3可以是0RTT，这些都是协议做的优化，为了节省在RTT上花费的时间。在下一讲里会有更多的TLS的内容，你可以期待一下。 问题2的答案也正确。因为客户端没有这个根证书，那么这个证书链的源头无法验证通过，就失去了信任链的根基。 common name: server (does not match 'api.server.777.abcd.io')这个在正常验证中确实会报错的，但是关闭了证书校验就不会了。这次握手失败，原因不是名称不符，是无法找到共用的密码套件，所以无法开展密钥协商。 能看出来你都认真思考了，很棒：）
2022-03-0432 
追风筝的人信任根证书 -> 信任中间证书 -> 信任叶子证书 curl -vk https://站点名 openssl s_client -tlsextdebug -showcerts -connect 站点名:443 老师TLS case讲的很清楚作者回复: 你的总结也很好：） 在用openssl探测远端站点证书时，为了查看证书细节，可以运行下面命令： openssl s_client -connect 站点名:443 | openssl x509 -text
2022-03-171
taochao_zs1 TLS是四次握手，前面2次是hello握手，后面2次是交换密钥握手 2 会信任，只要中间证书是根证书签发出来的，可以验证证书的关系链是否一致（证书包含相同密钥和签名算法，完整性算法这些）。作者回复: 1. 是正确的 2. 题目里提到客户端并没有服务端返回的根证书，那么会验证失败，因为信任的起点是根证书~
2022-03-041
Bachue Zhou感觉 openssl 从本地找到同名的证书后因为该证书过期就造成握手失败是一个设计缺陷，理论上应该始终是从服务器获取的，即使为了提高效率会使用本地缓存的证书，也不应该因为该缓存过期就判定握手失败，而是应该继续从服务器获取。另外，这也说明 tls 大幅增加了通讯复杂度，所以在内网里全部启用 https 通讯将大幅增加运维成本。所以我认为 http/2 和 http/3 强制要求启用 https 是设计错误，提高客户的使用成本，缩减了自己的适用范围。作者回复: TLS的推广，从整体上肯定是利大于弊的。安全是网络发展的趋势，这个肯定不会改变。这几年的zero trust潮流，就是要求在内网也需要像外网那样实施严格的安全管控，否则对上市公司来说，都无法通过监管部门的安全审计。 从技术面上说，IPv4协议推出时，网络安全问题远达不到现在的尖锐程度。后来推出的IPv6就是强制启用IPsec做加密的，这一点也说明了网络发展的方向~
2022-11-02归属地：上海- taochao_zs杨老师有微信群吗，后面还想多和杨老师多多请教。
作者回复: 嗯我让助教拉一下~
2022-03-043 
那时刻我们之前也遇到过tls偶尔握手失败的案例，抓包来看是，客户端发出client hello之后，收到服务器的rst消息，且这个rst消息的ttl的值是64，我们猜想是被防火墙阻止了。不知老师是否遇到这样的case？以及分析原因呢？作者回复: 多半是防火墙发出了RST，而且因为这个RST报文的TTL是64，就是跟你的网关了，因为这是TTL原始值的一种（其他常见的是128和255）。
2022-03-042- 那时刻请问老师，PKI 里有交叉签名的技术，就是新老根证书对同一个新的中间证书进行签名，但并不适用于这个案例。 此时，对于这个中间证书签名的叶子证书，验证流程是如何呢？新老根证书都会验证么？
作者回复: 嗯 我想表达的意思是，叶子证书不会是新老两个中间证书做交叉签名的。之所以能用老的中间证书的公钥也能解开，只是因为新的中间证书用的私钥还是老的那个。 客户端拼接处的证书链是“根证书（未过期）->中间证书（过期）->叶子证书（未过期）”，因为其中的中间证书过期了，所以报告了certificate has expired。也就是最让人困惑的地方其实是：我们以为这里说的certificate是叶子证书，实际上是中间证书~ 我这样说是否更清晰一些？：）
2022-03-04 
斯蒂芬.赵使用go的http client对一个重定向短链发起curl get请求的时候报错：remote error: tls: internal errors是啥原因？2023-02-09归属地：山东
