原文：
以訪問www.sina.com.cn為例，抓包解析tls1.2到底是如何通訊的；
wireshark抓包內容及簡單說明：
10 0.042384 192.168.10.97 101.71.100.123 tlsv1.2 264 client hello
12 0.059895 101.71.100.123 192.168.10.97 tlsv1.2 1506 server hello
16 0.060412 101.71.100.123 192.168.10.97 tlsv1.2 1386 certificate, server key exchange, server hello done
18 0.063282 192.168.10.97 101.71.100.123 tlsv1.2 180 client key exchange, change cipher spec, encrypted handshake message
19 0.073250 101.71.100.123 192.168.10.97 tlsv1.2 312 new session ticket, change cipher spec, encrypted handshake message
身份驗證過程：
數字證書作用參考：
客戶端client hello階段：
作用：客戶端向服務端傳送建立連線請求；
此時，客戶端會攜帶支援的版本號、支援的加密套件、客戶端隨機數(用於協商對稱加密的金鑰)、支援的http協議
服務端server hello階段：
作用：根據客戶端所攜帶的內容，確定建立連線版本、加密套件，生成服務端隨機數(用於協商對稱加密的金鑰)
如下圖，可以看到確定的加密套件是：tls_ecdhe_rsa_with_aes_128_gcm_sha256
服務端certificate, server key exchange, server hello done階段：
certificate：向客戶端傳送由權威ca簽發的證書，以驗證身份；
server key exchange：基於server hello階段選擇的ecdhe交換金鑰演算法，傳送它生成的橢圓曲線的公鑰(經過簽名的)
server hello done：服務端結束打招呼階段
協商對稱加密金鑰的過程說明：
客戶端client key exchange, change cipher spec, encrypted handshake message階段：
client key exchange：基於協商選擇的ecdhe交換金鑰演算法，傳送它生成的橢圓曲線的公鑰；
change cipher spec：變更密碼規範協議，它非常簡單，就是一條通知訊息，告知對方以後的通訊都是加密的；
enctypted handshare message：生成對稱加密金鑰之後，傳送一條加密的資料，讓服務端解密驗證；
服務端new session ticket, change cipher spec, encrypted handshake message階段：
new session ticket：tls建立連線的優化方法，此處不說；
change cipher spec：告訴客戶端以後的通訊是加密的；
enctypted handshare message：傳送一條經過金鑰加密的資料，讓客戶端驗證；驗證通過則開始進行加密通訊；
信任始於握手 TLS1 2連線過程解析
一 https 建立連線 當你在瀏覽器位址列裡鍵入 https 開頭的 uri，再按下回車，會發生什麼呢？瀏覽器首先要從 uri 裡提取出協議名和網域名稱。因為協議名是 https 所以瀏覽器就知道了埠號是預設的 443，它再用 dns 解析網域名稱，得到目標的 ip 位址，然後就可以使用三次握手與...
Xutils 如何增加TLS1 2的支援
需求 公司為了提高伺服器安全，要求所有與伺服器互動的api都需要採用且僅支援https tls1.2。測試後發現xutils 無法訪問這種介面，尋遍各個 後找到一種解決方案。然後在requestparams 新增sslsocketfactory tlsonlysocketfactory factor...
說說TLS協議裡的wireshark抓包內容（一）
我們看到第63號 客戶端向伺服器傳送 client hello 資料報 我們觀察內容 先看到 content type 內容的格式 其實就是說這是握手協議中的 client hello tls中有四種協議 握手協議 22 這裡就是22可以看到 警告協議 21 密碼變更協議 20 這協議沒有出現在我們...