簡介： TLS/SSL 握手失敗引發的鏈接異常問題怎麼搞？阿里雲 SRE 工程師手把手帶你排查解決。html
1.TLS/SSL 握手基本流程
*圖片來源於網絡
android
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 及以上版本才完成入根接入。ui
*參考: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 的總體安全水平，力保應用不被逆向破解，在安全性上具備很是可靠的保障。
原文連接 本文爲阿里雲原創內容，未經容許不得轉載。