简介： TLS/SSL 握手失败引发的链接异常问题怎么搞？阿里云 SRE 工程师手把手带你排查解决。html
1.TLS/SSL 握手基本流程
*图片来源于网络
android
2.案例分享
2.1CFCA 证书的历史问题
2.1.1背景
某客户为其生产环境的站点申请了一张由 CFCA 签发的证书。相关域名正确配置该证书且启用 HTTPS 后，经测试发现他们的客户端 App 在低版本手机上（ iOS < 10.0，Android < 6.0）没法链接到相关站点。浏览器
客户端调试发现，控制台会看到证书无效的错误信息（Invalid Certificate 或 Certificate Unknown ）。缓存
2.1.2排查
起初，工程师并不知道客户的证书是由哪一个机构签发以及有什么问题。而对于这类问题，通常均须要客户端网络包作进一步的分析与判断。所以安排客户在受影响的设备上进行问题复现及客户端抓包操做。安全
获取到网络包后，首先确认了客户端链接失败的直接缘由为 TLS 握手过程异常终止，见下：服务器
查看 Encrypted Alert 内容，错误信息为 0x02 0x2E。根据 TLS 1.2 协议（RFC5246 ）的定义， 该错误为由于 certificate_unknown。网络
继续查看该证书的具体信息，根据 Server Hello 帧中携带的证书信息得知该证书由证书机构 China Financial Certification Authority(CFCA) 签发。再根据证书信息中的 Authority Information Access (AIA) 信息确认 Intermediate CA 和 Root CA 证书。确认该证书签发机构的根证书为 CFCA EV ROOT。工具
回到存在问题的手机设备上（Android 5.1），检查系统内置的受信任 CA 根证书列表，未能找到 CFCA EV ROOT CA 证书；而在正常链接的手机上，能够找到该 CA 的根证书并默认设置为”信任“。测试
查阅 CFCA 证书的相关说明，该机构的证书在 iOS 10.1 及 Android 6.0 及以上版本才完成入根接入。ui
*参考:https://www.cfca.com.cn/upload/20161101.pdf
2.1.3小结
从上面的分析能够看到，该问题的根因是低版本客户端设备没有内置 CFCA 的 CA 根证书。所以，基本的解决方案包括：
- 更换其余 CA 机构签发的证书，保证其 CA 根证书的在特定设备上已默认信任。
- 手动在受影响的设备上安装该 CA 根证书及中间证书，并配置为信任状态。
- 客户端 App 预置该 CA 根证书，并经过客户端代码配置信任该证书。
须要结合不一样的业务场景选择合理解决方案。
2.2证书链信任模式引发的问题
2.2.1背景
某客户新增了一个容灾备用接入地址，启用了一个新的域名并配置了一张全新的证书。测试发现，切换到该备用地址时，Android 客户端没法正常链接，报证书未知错误（Certificate Unknown）；iOS 客户端表现正常。
2.2.2排查
和 2.1 的问题相似，首先在受影响的设备上进行问题复现及客户端抓包操做。
获取到网络包以后，确认了客户端链接失败的直接缘由为 TLS 握手过程异常终止，缘由与 2.1 中的问题同样，为Certificate Unknown ：
相似问题 2.1 的排查动做，查看该证书的 CA 根证书及根证书的信任状况。
发现该证书由中间 CA 机构 Secure Site Pro CA G2 签发，其根 CA 为 DigiCert Global Root CA:
DigiCert Global Root CA 做为一个普遍支持的证书签发机构，其根 CA 证书在绝大多数的设备上均为受信任状态，这一点在受影响的设备上也获得了确认。既然根 CA 的证书处于信任状态，为什么证书验证仍是失败？这成为下一步排查的重点方向。
同一台设备，切换到正常环境下，也完成一次抓包操做。获取到新的网络包后作对比分析，发现两种状况下网络包中体现的区别为：
正常环境下，服务器返回的证书包含了完整的 CA 证书链；
异常状况下，服务端返回的证书仅包含叶节点 CA 证书。
根据上述线索进行排查研究，发现：不一样于其余平台，Android 客户端默认是不会经过 AIA Extension 去作证书链的校验。
*参考：https://tools.ietf.org/html/rfc3280#section-4.2.2.1 ；https://developer.android.com/training/articles/security-ssl#UnknownCa
所以，当中间 CA 证书未安装或未缓存时，客户端 App 是不会主动拉取中间 CA 证书并作进一步信任链校验的，从而致使证书校验失败。
2.2.3小结
从上面的排查分析看到，该问题和 Android 平台自身的证书校验机制和证书打包方式相关。解决方案包括：
代码层面手动定制 TrustManager 去定制校验过程；
或从新打包证书，将中间 CA 证书和根 CA 证书一同打包到服务端证书中。
该客户综合开发成本与环境现状，选择从新打包证书。新的证书配置完成后，问题获得解决。
2.3加密套件协商引发的问题
2.3.1背景
某客户反馈他们的 iOS 客户端 App 用户在特定运营商网络环境下没法打开特定的业务站点（HTTPS 站点）。客户端处于白屏等待状态并最终报错；而在一样的网络环境下，系统浏览器能够打开该站点；同一台设备，切换到另外一个网络运营商下，也能够访问该站点。
2.3.2排查
因为该问题直接表如今 Web 层，所以首先尝试经过 Charles 抓取 HTTP 层包进行分析。HTTP 日志发现相关 HTTP 请求并未发出。
由此怀疑问题发生在 TCP 层，进而在受影响的设备上进行问题复现及客户端抓包操做。
获取到网络包后，首先确认问题：
- 经过页面域名在网络包中寻找 DNS 解析结果；
- 根据 DNS 解析结果找到站点 IP，并过滤出客户端与该 IP 之间的访问状况；
- 观察客户端与该服务器之间的网络活动，发现存在 TLS 握手失败的状况：
从上面的网络包能够看到，服务端（机房 P 中的服务器提供接入服务）在收到 Client Hello 后，直接返回了 Handshake Failure，这种状况下，通常须要服务端配合排查握手失败的直接缘由。在客户端条件下，能够进一步缩小排查疑点。
从新考虑客户问题条件：相同的网络条件下，系统浏览器能够打开该页面；同一设备切换到另外一运营商下（站点此时由机房 Q 中的服务器提供接入服务），能够正常访问。针对这这两种正常状况进行抓包和进一步分析。
经过对三种状况的网络观察发现：
- 问题 App 发出的 Client Hello 显示支持 17 种加密套件：
- 正常 App 发出的 Client Hello 显示支持 26 种加密套件：
- 正常 App 和机房 P 服务器协商的加密套件为：TLS_RAS_WITH_3DES_EDE_CBC_SHA (0x000a) （不在问题 App 支持的加密套件范围内）；
- 问题 App 和机房 Q 服务器协商的加密套件为：TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)（在问题 App 支持的加密套件范围内）；
根据上述状况，能够推论问题的基本状况为：
- 问题 App 发出去的握手请求，支持17种加密套件（ A 集合）；
- 正常 App 发出去的握手请求，支持26种加密套件（ B 集合）；
- 机房 P 的接入服务器，能支持 B 集合中的至少一种加密套件，不支持 A 集合中的全部加密套件；
- 机房 Q 的接入服务器，既支持 A 集合中的至少一种加密套件，也支持 B 集合中的至少一种加密套件；
最终致使 问题 App 没法经过 机房 P 中的服务器 访问该站点。
2.3.3 小结
从上面的分析结论能够看到，因为客户端和服务端加密套件不匹配，致使在特定状况下的握手失败。进一步的问题解决方案包括：
调整客户端加密套件，增长支持的 Cipher Suites（涉及客户端底层 TLS/SSL 库的升级）；
调整服务端加密套件，增长支持的 Cipher Suites（涉及服务端 TLS/SSL 接入配置）。
该客户最终选择调整服务端加密套件，问题获得解决。
3.总结
从上述案例的分享和实践中能够看到，TLS 层面的问题在客户端的症状表现上有类似之处，可是问题的根因却截然不同。这里例举的问题虽不能覆盖全部的问题场景，但能够看到基本的排查思路以下：
判断问题是否属于 TLS/SSL 层面的问题。
抓取网络包；有条件的状况下，能够针对正常和异常状况抓取两份网络包，以便后续进行对比分析。
根据网络包探寻问题发生的直接缘由，进而进一步探究问题的根本缘由。
根据分析结论并结合业务场景，选择合适的解决方案。
这类问题的排查基础是对 HTTPS 和 TLS/SSL 协议的理解以及对分析工具的掌握。在移动领域，这类问题存在必定的共性，直接了解上述结论和分析方法能够帮助开发者快速“出坑”。
参考
- 如何抓取网络包，https://help.aliyun.com/document_detail/159169.html
- Security with HTTPS and SSL，https://developer.android.com/training/articles/security-ssl
- Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile，https://tools.ietf.org/html/rfc5280
彩（广）蛋（告）
针对市面上移动应用广泛存在的破解、篡改、盗版、钓⻥欺诈、内存调试、数据窃取等各种安全风险，mPaaS 「移动安全加固」依赖于阿里云集团的移动安全加固技术，经历了淘系等亿级应用的安全性考验。
可以有效为移动应用提供稳定、简单、有效的安全保护，提升 App 的总体安全水平，力保应用不被逆向破解，在安全性上具备很是可靠的保障。
原文连接 本文为阿里云原创内容，未经容许不得转载。