1. 背景

HTTPS 作為站點安全的最佳實踐之一，已經得到了最廣泛的支援。然而在實際生產過程中，由 TLS/SSL 握手失敗引起的連線異常問題依然十分常見。本文將結合 mPaaS 客戶端實際排查案例，介紹這類問題在移動領域的排查和解決方案。

2. TLS/SSL 握手基本流程

HTTPS 的主要作用是在不安全的網路上建立一個基於 TLS/SSL 協議安全通道，對竊聽和中間人攻擊提供一定程度的合理防護。TLS/SSL 握手的基本流程如下圖描述：

3. 案例分享

2.1 CFCA 證書的歷史問題

2.1.1 背景

某客戶為其生產環境的站點申請了一張由 CFCA 簽發的證書。相關域名正確配置該證書且啟用 HTTPS 後，經測試發現他們的客戶端 App 在低版本手機上（ iOS < 10.0，Android < 6.0）無法連線到相關站點。

2.1.2 排查

起初，工程師並不知道客戶的證書是由哪個機構簽發以及有什麼問題。而對於這類問題，一般均需要客戶端網路包做進一步的分析與判斷。因此安排客戶在受影響的裝置上進行問題復現及客戶端抓包操作。

1. 獲取到網路包後，首先確認了客戶端連線失敗的直接原因為 TLS 握手過程異常終止，見下：
   

2. 檢視 Encrypted Alert 內容，錯誤資訊為 0x02 0x2E。根據 TLS 1.2 協議（RFC5246 ）的定義， 該錯誤為因為 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 及以上版本才完成入根接入，參考這裡:
   

2.1.3 小結

從上面的分析可以看到，該問題的根因是低版本客戶端裝置沒有內建 CFCA 的 CA 根證書。因此，基本的解決方案包括：

1. 更換其他 CA 機構簽發的證書，保證其 CA 根證書的在特定裝置上已預設信任。

2. 手動在受影響的裝置上安裝該 CA 根證書及中間證書，並配置為信任狀態。

3. 客戶端 App 預置該 CA 根證書，並通過客戶端程式碼配置信任該證書。

需要結合不同的業務場景選擇合理解決方案。

2.2 證書鏈信任模式引起的問題

背景

某客戶新增了一個容災備用接入地址，啟用了一個新的域名並配置了一張全新的證書。測試發現，切換到該備用地址時，Android 客戶端無法正常連線，報證書未知錯誤（Certificate Unknown）；iOS 客戶端表現正常。

排查

和 2.1 的問題類似，首先在受影響的裝置上進行問題復現及客戶端抓包操作。

1. 獲取到網路包之後，確認了客戶端連線失敗的直接原因為 TLS 握手過程異常終止，原因與 2.1 中的問題一樣，為Certificate Unknown ：
   

2. 類似問題 2.1 的排查動作，檢視該證書的 CA 根證書及根證書的信任情況。
   發現該證書由中間 CA 機構 Secure Site Pro CA G2 簽發，其根 CA 為 DigiCert Global Root CA:
   
   

3. DigiCert Global Root CA 作為一個廣泛支援的證書籤發機構，其根 CA 證書在絕大多數的裝置上均為受信任狀態，這一點在受影響的裝置上也得到了確認。既然根 CA 的證書處於信任狀態，為何證書驗證還是失敗？這成為下一步排查的重點方向。

4. 同一臺裝置，切換到正常環境下，也完成一次抓包操作。獲取到新的網路包後做對比分析，發現兩種情況下網路包中體現的區別為：

• 正常環境下，伺服器返回的證書包含了完整的 CA 證書鏈；

• 而異常情況下，服務端返回的證書僅包含葉節點 CA 證書。
  
  

5. 根據上述線索進行排查研究，發現：不同於其他平臺，Android 客戶端預設是不會通過 AIA Extension 去做證書鏈的校驗（ AIA 機制參考這裡）。因此，當中間 CA 證書未安裝或未快取時，客戶端 App 是不會主動拉取中間 CA 證書並做進一步信任鏈校驗的，參考這裡，從而導致證書校驗失敗。

小結

從上面的排查分析看到，該問題和 Android 平臺自身的證書校驗機制和證書打包方式相關。解決方案包括：

1. 程式碼層面手動定製 TrustManager 去定製校驗過程；

2. 或重新打包證書，將中間 CA 證書和根 CA 證書一同打包到服務端證書中。

該客戶綜合開發成本與環境現狀，選擇重新打包證書。新的證書配置完成後，問題得到解決。

2.3 加密套件協商引起的問題

背景

某客戶反饋他們的 iOS 客戶端 App 使用者在特定運營商網路環境下無法開啟特定的業務站點（HTTPS 站點）。客戶端處於白屏等待狀態並最終報錯；而在同樣的網路環境下，系統瀏覽器可以開啟該站點；同一臺裝置，切換到另一個網路運營商下，也可以訪問該站點。

排查

1. 由於該問題直接表現在 Web 層，因此首先嚐試通過 Charles 抓取 HTTP 層包進行分析。HTTP 日誌發現相關 HTTP 請求並未發出。

2. 由此懷疑問題發生在 TCP 層，進而在受影響的裝置上進行問題復現及客戶端抓包操作。

3. 獲取到網路包後，首先確認問題：
   a. 通過頁面域名在網路包中尋找 DNS 解析結果；
   b. 根據 DNS 解析結果找到站點 IP，並過濾出客戶端與該 IP 之間的訪問情況；
   c. 觀察客戶端與該伺服器之間的網路活動，發現存在 TLS 握手失敗的情況：
   

4. 從上面的網路包可以看到，服務端（機房 P 中的伺服器提供接入服務）在收到 Client Hello 後，直接返回了 Handshake Failure，這種情況下，一般需要服務端配合排查握手失敗的直接原因。在客戶端條件下，可以進一步縮小排查疑點。

5. 重新考慮客戶問題條件：相同的網路條件下，系統瀏覽器可以開啟該頁面；同一裝置切換到另一運營商下（站點此時由機房 Q 中的伺服器提供接入服務），可以正常訪問。針對這這兩種正常情況進行抓包和進一步分析。

6. 通過對三種情況的網路觀察發現：
   a. 問題 App 發出的 Client Hello 顯示支援 17 種加密套件：
   
   
   b. 正常 App 發出的 Client Hello 顯示支援 26 種加密套件：
   
   
   c. 正常 App 和機房 P 伺服器協商的加密套件為：TLS_RAS_WITH_3DES_EDE_CBC_SHA (0x000a) （不在問題 App 支援的加密套件範圍內）；
   d. 問題 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 中的伺服器 訪問該站點。

小結

從上面的分析結論可以看到，由於客戶端和服務端加密套件不匹配，導致在特定情況下的握手失敗。進一步的問題解決方案包括：

1. 調整客戶端加密套件，增加支援的 Cipher Suites（涉及客戶端底層 TLS/SSL 庫的升級）；

2. 調整服務端加密套件，增加支援的 Cipher Suites（涉及服務端 TLS/SSL 接入配置）。

該客戶最終選擇調整服務端加密套件，問題得到解決。

3. 總結

從上述案例的分享和實踐中可以看到，TLS 層面的問題在客戶端的症狀表現上有相似之處，但是問題的根因卻大相徑庭。這裡例舉的問題雖不能覆蓋所有的問題場景，但可以看到基本的排查思路如下：

1. 判斷問題是否屬於 TLS/SSL 層面的問題。

2. 抓取網路包；有條件的情況下，可以針對正常和異常情況抓取兩份網路包，以便後續進行對比分析。

3. 根據網路包探尋問題發生的直接原因，進而進一步探究問題的根本原因。

4. 根據分析結論並結合業務場景，選擇合適的解決方案。

這類問題的排查基礎是對 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