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加固新方向——混淆和瘦身》完整講義