1.背景
HTTPS作為站點安全的最佳實踐之一，已經得到了最廣泛的支援。然而在實際生産過程中，由TLS/SSL握手失敗引起的連接配接異常問題依然十分常見。本文将結合mPaaS（
https://www.aliyun.com/product/mpaas）用戶端實際排查案例，介紹這類問題在移動領域的排查和解決方案。
2. TLS/SSL握手基本流程
HTTPS的主要作用是在不安全的網絡上建立一個基于TLS/SSL協定的安全信道，對竊聽和中間人攻擊提供一定程度的合理防護。TLS/SSL握手的基本流程如下圖描述：
圖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握手過程異常終止，見下：
圖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）：
圖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：
圖4：用戶端連接配接失敗抓包分析結果
（2）類似上一個問題的排查動作，檢視該證書的CA根證書及根證書的信任情況。發現該證書由中間CA機構Secure Site Pro CA G2簽發，其根CA為DigiCert Global Root CA：
圖5：證書簽發機構排查結果
圖6：根CA排查結果
（3）DigiCert Global Root CA作為一個廣泛支援的證書簽發機構，其根CA憑證在絕大多數的裝置上均為受信任狀态，這一點在受影響的裝置上也得到了确認。既然根CA的證書處于信任狀态，為何證書驗證還是失敗？這成為下一步排查的重點方向。
（4）同一台裝置，切換到正常環境下，也完成一次抓包操作。擷取到新的網絡包後做對比分析，發現兩種情況下網絡包中展現的差別為：
正常環境下，伺服器傳回的證書包含了完整的CA憑證鍊；
而異常情況下，服務端傳回的證書僅包含葉節點CA憑證。
圖7：正常環境下伺服器傳回完整CA憑證鍊
圖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）擷取到網絡包後，首先确認問題：
通過頁面域名在網絡包中尋找DNS解析結果；
根據DNS解析結果找到站點IP，并過濾出用戶端與該IP之間的通路情況；
觀察用戶端與該伺服器之間的網絡活動，發現存在TLS握手失敗的情況：
圖9：抓包分析發現TLS握手失敗情況
（4）從上面的網絡包可以看到，服務端（機房P中的伺服器提供接入服務）在收到Client Hello後，直接傳回了Handshake Failure，這種情況下，一般需要服務端配合排查握手失敗的直接原因。在用戶端條件下，可以進一步縮小排查疑點。
（5）重新考慮客戶問題條件：相同的網絡條件下，系統浏覽器可以打開該頁面；同一裝置切換到另一營運商下（站點此時由機房Q中的伺服器提供接入服務），可以正常通路。針對這兩種正常情況進行抓包和進一步分析。
（6）通過對三種情況的網絡觀察發現：
問題App發出的Client Hello顯示支援17種加密套件：
圖10：問題app發出的Client Hello顯示支援17種加密套件
正常App發出的Client Hello顯示支援26種加密套件：
圖11：正常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支援的加密套件範圍内）；
（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技術學院釘釘圈子，和更多雲上人交流關于雲平台的那些事。