搞定客户端证书错误,看这篇就够了
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 的整体安全水平,力保应用不被逆向破解,在安全性上具有非常可靠的保障。
如有更多接入相关问题
欢迎使用钉钉扫码或搜索33417739入群交流
关注公众号“mPaaS”,回复“安全加固”,立即获取《APP加固新方向——混淆和瘦身》完整讲义
访问2020阿里巴巴双11技术全观专题页,了解更多关于2020双11的技术干货内容
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Flutter 快速上手,秒变大前端
Flutter是什么 Flutter是谷歌的移动UI框架,可以快速在iOS和Android上构建高质量的原生用户界面。Flutter可以与现有的代码一起工作。在全世界,Flutter正在被越来越多的开发者和组织使用,并且Flutter是完全免费、开源的。简单来说,Flutter是一款移动应用程序SDK,包含框架、控件和一些工具,可以用一套代码同时构建Android和iOS应用,并且性能可以达到原生应用一样的性能。Flutter简介 配置开发环境 Flutter开发可以在macOS,Linux或Windows上完成。虽然您可以在Flutter工具链中使用任何编辑器,但IntelliJ IDEA,Android Studio和Visual Studio Code的IDE插件可以简化开发工作。 下载flutter SDK。地址 将flutter的bin目录添加到path中。 执行flutter doctor命令,他会安装flutter框架,包括dart,而且提示你任何其他需要安装的依赖。 安装其他依赖。 在IDE中安装flutter插件。 体验 ▐ Android Studio (为Flut...
- 下一篇
阿里云AIoT 经典基础知识 快问快答
业务数据流程 我的传感设备,IoT平台,业务服务器,App之间是什么关系? 上行数据链路: 设备以MQTT协议建立和 IoT 物联网平台的长连接,异步PUBLISH数据(Topic和Payload)到 IoT 平台 IoT 平台根据配置的规则引擎,处理数据后,流转到 数据库DB,消息队列MQ,函数计算FC 或者 通过AMQP协议流转到你的ECS服务器上 下行数据链路: ECS服务器程序调用HTTPS的Pub API,发送数据到 IoT 平台 IoT 平台通过MQTT协议,PUBLISH数据到设备端(指定Topic和Payload) FAQ 1.为什么设备无法上报数据? 您需要先定义具有发布权限的通信Topic 2.为什么设备无法接收数据? 您需要先定义具有订阅权限的通信Topic,并且设备主动subscribe此通信Topic定义Topic设备订阅Topic成功 3.设备一定要预先烧录三元组吗? 不需要,参考这个方案 https://developer.aliyun.com/article/770299 4.接入电信NB-IoT设备能对接到阿里云IoT吗? 可以,参考这个方案https...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Mario游戏-低调大师作品
- CentOS6,CentOS7官方镜像安装Oracle11G
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS8编译安装MySQL8.0.19
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7