共计 3943 个字符,预计需要花费 10 分钟才能阅读完成。
简介: TLS/SSL 握手失败引起的连贯异样问题怎么搞?阿里云 SRE 工程师手把手带你排查解决。
1.TLS/SSL 握手根本流程
* 图片来源于网络
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 及以上版本才实现入根接入。
* 参考: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 的整体平安程度,力保利用不被逆向破解,在安全性上具备十分牢靠的保障。
原文链接
本文为阿里云原创内容,未经容许不得转载。