客户端证书错误避坑指南

  1. 云栖社区>
  2. 阿里云SRE技术社区>
  3. 博客>
  4. 正文

客户端证书错误避坑指南

阿里云SRE团队小编 2020-06-10 17:47:54 浏览582

1.背景

HTTPS作为站点安全的最佳实践之一,已经得到了最广泛的支持。然而在实际生产过程中,由TLS/SSL握手失败引起的连接异常问题依然十分常见。本文将结合mPaaS(https://www.aliyun.com/product/mpaas)客户端实际排查案例,介绍这类问题在移动领域的排查和解决方案。

2. TLS/SSL握手基本流程

HTTPS的主要作用是在不安全的网络上创建一个基于TLS/SSL协议的安全信道,对窃听和中间人攻击提供一定程度的合理防护。TLS/SSL握手的基本流程如下图描述:

image

图1:TLS/SSL握手基本流程图

3.案例分享

3.1 CFCA证书的历史问题

3.1.1背景

某客户为其生产环境的站点申请了一张由CFCA(https://www.cfca.com.cn/)签发的证书。相关域名正确配置该证书且启用HTTPS后,经测试发现他们的客户端App在低版本手机上(iOS<10.0,Android<6.0)无法连接到相关站点。
客户端调试发现,控制台会看到证书无效的错误信息(Invalid Certificate或Certificate Unknown)。

3.1.2排查

起初,工程师并不知道客户的证书是由哪个机构签发以及有什么问题。而对于这类问题,一般均需要对客户端网络包做进一步的分析与判断。因此安排客户在受影响的设备上进行问题复现及客户端抓包操作。

(1)获取到网络包后,首先确认了客户端连接失败的直接原因为TLS握手过程异常终止,见下:

image

图2:客户端连接失败抓包分析结果

(2)查看Encrypted Alert内容,错误信息为0x02 0x2E。根据TLS 1.2协议(RFC5246,https://tools.ietf.org/html/rfc5246#page-69)的定义,该错误是因为certificate_unknown。

(3)继续查看该证书的具体信息,根据Server Hello帧中携带的证书信息得知该证书由证书机构China Financial Certification Authority(CFCA)签发。再根据证书信息中的Authority Information Access (AIA)信息确认Intermediate CA和Root CA证书。确认该证书签发机构的根证书为CFCA EV ROOT。

(4)回到存在问题的手机设备上(Android 5.1),检查系统内置的受信任CA根证书列表,未能找到CFCA EV ROOT CA证书;而在正常连接的手机上,可以找到该CA的根证书并默认设置为“信任”。

(5)查阅CFCA证书的相关说明,该机构的证书在iOS 10.1及Android 6.0及以上版本才完成入根接入(参考https://www.cfca.com.cn/upload/20161101.pdf):

image

图3:CFCA证书的版本支持说明

3.1.3小结

从上面的分析可以看到,该问题的根因是低版本客户端设备没有内置CFCA的CA根证书。因此,基本的解决方案包括:

(1)更换其他CA机构签发的证书,保证其CA根证书的在特定设备上已默认信任。

(2)手动在受影响的设备上安装该CA根证书及中间证书,并配置为信任状态。

(3)客户端App预置该CA根证书,并通过客户端代码配置信任该证书。

需要结合不同的业务场景选择合理解决方案。

3.2证书链信任模式引起的问题

3.2.1背景

某客户新增了一个容灾备用接入地址,启用了一个新的域名并配置了一张全新的证书。测试发现,切换到该备用地址时,Android客户端无法正常连接,报证书未知错误(Certificate Unknown);iOS客户端表现正常。

3.2.2排查

和上一个问题类似,首先在受影响的设备上进行问题复现及客户端抓包操作。

(1)获取到网络包之后,确认了客户端连接失败的直接原因为TLS握手过程异常终止,原因与上一个问题一样,为Certificate Unknown:

image

图4:客户端连接失败抓包分析结果

(2)类似上一个问题的排查动作,查看该证书的CA根证书及根证书的信任情况。发现该证书由中间CA机构Secure Site Pro CA G2签发,其根CA为DigiCert Global Root CA:

image

图5:证书签发机构排查结果


image

图6:根CA排查结果

(3)DigiCert Global Root CA作为一个广泛支持的证书签发机构,其根CA证书在绝大多数的设备上均为受信任状态,这一点在受影响的设备上也得到了确认。既然根CA的证书处于信任状态,为何证书验证还是失败?这成为下一步排查的重点方向。

(4)同一台设备,切换到正常环境下,也完成一次抓包操作。获取到新的网络包后做对比分析,发现两种情况下网络包中体现的区别为:

  • 正常环境下,服务器返回的证书包含了完整的CA证书链;
  • 而异常情况下,服务端返回的证书仅包含叶节点CA证书。

    image

    图7:正常环境下服务器返回完整CA证书链

image

图8:异常环境下服务端返回仅包含叶节点CA证书

(5)根据上述线索进行排查研究,发现:不同于其他平台,Android客户端默认是不会通过AIA Extension去做证书链的校验(AIA机制参考https://tools.ietf.org/html/rfc3280#section-4.2.2.1)。因此,当中间CA证书未安装或未缓存时,客户端App是不会主动拉取中间CA证书并做进一步信任链校验的,参考https://developer.android.com/training/articles/security-ssl#UnknownCa,从而导致证书校验失败。

3.2.3小结

从上面的排查分析看到,该问题和Android平台自身的证书校验机制和证书打包方式相关。解决方案包括:

(1)代码层面手动定制TrustManager去定制校验过程;

(2)或重新打包证书,将中间CA证书和根CA证书一同打包到服务端证书中。

该客户综合开发成本与环境现状,选择重新打包证书。新的证书配置完成后,问题得到解决。

3.3加密套件协商引起的问题

3.3.1背景

某客户反馈他们的iOS客户端App用户在特定运营商网络环境下无法打开特定的业务站点(HTTPS站点)。客户端处于白屏等待状态并最终报错;而在同样的网络环境下,系统浏览器可以打开该站点;同一台设备,切换到另一个网络运营商下,也可以访问该站点。

3.3.2排查

(1)由于该问题直接表现在Web层,因此首先尝试通过Charles抓取HTTP层包进行分析。HTTP日志发现相关HTTP请求并未发出。

(2)由此怀疑问题发生在TCP层,进而在受影响的设备上进行问题复现及客户端抓包操作。

(3)获取到网络包后,首先确认问题:

  1. 通过页面域名在网络包中寻找DNS解析结果;
  2. 根据DNS解析结果找到站点IP,并过滤出客户端与该IP之间的访问情况;
  3. 观察客户端与该服务器之间的网络活动,发现存在TLS握手失败的情况:

    image

    图9:抓包分析发现TLS握手失败情况

(4)从上面的网络包可以看到,服务端(机房P中的服务器提供接入服务)在收到Client Hello后,直接返回了Handshake Failure,这种情况下,一般需要服务端配合排查握手失败的直接原因。在客户端条件下,可以进一步缩小排查疑点。

(5)重新考虑客户问题条件:相同的网络条件下,系统浏览器可以打开该页面;同一设备切换到另一运营商下(站点此时由机房Q中的服务器提供接入服务),可以正常访问。针对这两种正常情况进行抓包和进一步分析。

(6)通过对三种情况的网络观察发现:

  1. 问题App发出的Client Hello显示支持17种加密套件:

    image

    图10:问题app发出的Client Hello显示支持17种加密套件

  2. 正常App发出的Client Hello显示支持26种加密套件:

    image

    图11:正常App发出的Client Hello显示支持26种加密套件

  3. 正常App和机房P服务器协商的加密套件为:TLS_RAS_WITH_3DES_EDE_CBC_SHA (0x000a)(不在问题App支持的加密套件范围内);
  4. 问题App和机房Q服务器协商的加密套件为:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)(在问题App支持的加密套件范围内);

(7)根据上述情况,可以推论问题的基本情况为:

  • 问题App发出去的握手请求,支持17种加密套件(A集合);
  • 正常App发出去的握手请求,支持26种加密套件(B集合);
  • 机房P的接入服务器,能支持B集合种的至少一种加密套件,不支持A集合中的所有加密套件;
  • 机房Q的接入服务器,既支持A集合中的至少一种加密套件,也支持B集合中的至少一种加密套件;
  • 最终导致问题App无法通过机房P中的服务器访问该站点。

3.3.3小结

从上面的分析结论可以看到,由于客户端和服务端加密套件不匹配,导致在特定情况下的握手失败。进一步的问题解决方案包括:

(1)调整客户端加密套件,增加支持的Cipher Suites(涉及客户端底层TLS/SSL库的升级);

(2)调整服务端加密套件,增加支持的Cipher Suites(涉及服务端TLS/SSL接入配置)。

该客户最终选择调整服务端加密套件,问题得到解决。

4.总结

从上述案例的分享和实践中可以看到,TLS层面的问题在客户端的症状表现上有相似之处,但是问题的根因却大相径庭。这里列举的问题虽不能覆盖所有的问题场景,但可以看到基本的排查思路如下:
(1)判断问题是否属于TLS/SSL层面的问题。

(2)抓取网络包;有条件的情况下,可以针对正常和异常情况抓取两份网络包,以便后续进行对比分析。

(3)根据网络包探寻问题发生的直接原因,进而进一步探究问题的根本原因。

(4)根据分析结论并结合业务场景,选择合适的解决方案。

这类问题的排查基础是对HTTPS和TLS/SSL协议的理解以及对分析工具的掌握。在移动领域,这类问题存在一定的共性,直接了解上述结论和分析方法可以帮助开发者快速“出坑”。

参考资料:
(1)如何抓取网络包,https://help.aliyun.com/document_detail/159169.html
(2)Security with HTTPS and SSL,https://developer.android.com/training/articles/security-ssl
(3)Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, https://tools.ietf.org/html/rfc5280

作者:王愈

阿里云智能GTS-SRE团队金融线技术服务经理

曾就职于微软全球技术服务中心,互联网开发支持服务部。现在就职于阿里云智能 SRE金融线技术服务经理团队,主要负责金融线客户的移动开发(mPaaS)解决方案、开发咨询等工作。

我们是阿里云智能全球技术服务-SRE团队,我们致力成为一个以技术为基础、面向服务、保障业务系统高可用的工程师团队;提供专业、体系化的SRE服务,帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统,提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云,让客户云上业务运行更加稳定可靠的技术,您可用钉钉扫描下方二维码,加入阿里云SRE技术学院钉钉圈子,和更多云上人交流关于云平台的那些事。

image