1、（1）上一篇tls1.3實戰（https://www.cnblogs.com/theseventhson/p/14613527.html）分析了client hello和server hello，主要介紹了雙方通過tls1.3協議握手的細節，還有一個很大的問題遺留：對於server hello包，wireshark就解析到了0xba這個位置（也就是ChangeCipherSpec），從0xbb到0x58e=1422的位置，還有1234byte並未解析，這些又都是什么數據了？縱觀整個協議的握手過程，截至目前看到的都是handshake密鑰交換階段，record傳輸加密數據的階段都在哪了？
ChangeCipherSpec字段本身是通知對方用協商好的對稱密鑰加密通信數據，所以從這之后的消息都是進行加密了的，可能是因為Wireshark沒有對后續的消息進行解密，所以只是顯示了ApplicationData，即加密傳輸的數據。
這些加密后的數據，那些時record階段的數據了？ record階段的數據既然加密了，能解密查看么？ 如果能，怎么查看了？
自己隨便選個目錄，比如我選了這個：D:\software\sslkeylog.log，在環境變量新建一個，取名為SSLKEYLOGFILE，如下：
然后在wireshark的編輯->首選項->Protocols選擇TLS（網上有些教程是讓選擇SSL，但我用的是3.4.0版本，沒有SSL選項，只有TLS選項），找到紅框框的地方，添上剛才環境變量指定的log文件路徑：
配置好后重新用chrome打開網頁，sslkeylog.log文件內容：這個是tls1.2的內容，格式為：CLIENT_RANDOM <client_random> <master_secret>，也就是記錄了client_random和master_secret；
CLIENT_RANDOM F6EC7D82E1A3704B9EEC4876FCAAB722E010D7FB4FA8DF332AF48D******** 2576E2B4C11802D86377C80B74504E7E03EDD11EE9CE780F86CB9DF06E30A1EC9FC15C14835252FE036DF7********
CLIENT_RANDOM 3DC71D07C9C3E512D7FFC5774BBCA8D07097580288BB3C86CA0E4F******** F6C87019AC A076F396E470C435DE478EDAEF9B2D6C72642706321A8A2456FD0A201A39D50EA055F6EA6EE0AEEFB********
至此，還未dump tls1.3的密鑰到sslkeylogfile.log（文件除了幾個CLIENT_RANDOM，就沒其他內容了），所以wireshark還是無法解密record階段的內容。網上查了很多資料，期間耗費了好幾個小時，終於用這個命令成功把chrome的密鑰dump到指定文件：
"C:\Program Files\Google\Chrome\Application\chrome.exe" --ssl-key-log-file=%SSLKEYLOGFILE%
文件都有61KB大了：
各種密鑰收集了近700條：
wireshark也能正常解密了：能看到entrypt extension、certificate、verify、finished
至此：利用chrome dump的key在wireshark中成功解密tls1.3的數據！
（2）解密注意（這些坑耗費了我好幾個小時排查）：
- 環境變量設置好后，電腦不用重啟，但瀏覽器要重啟；
- 在任務管理器看看瀏覽器進程是不是全部退出，不能有任何殘留的實例；如果不確定，建議重啟電腦，確保瀏覽器進程全部退出，沒有殘留
- 執行如下的命令：給瀏覽器認為設置一個參數；（直接打開瀏覽器是沒用的！一定要手動給瀏覽器設置這個參數！）
"C:\Program Files\Google\Chrome\Application\chrome.exe" --ssl-key-log-file=%SSLKEYLOGFILE%
（3）上面都是現象，原理在這：這里用的是ECDHE算法讓雙方互相交換公鑰，然后各自根據曲線類型和對方的公鑰生成對稱加密的密鑰pre-master-secret。這個對稱密鑰並未通過網絡傳輸，所以wireshark是抓不到的！怎么才能得到這個密鑰了？就是通過上述設置環境變量的方式，讓瀏覽器把pre-master-secret導出到指定的log文件，然后wireshark去指定的文件讀密鑰，就能解密application data了！
2、接下來介紹一下這幾個重點的handshake protocol；
- handshake protocol：certificate；client和server在通信時，為了確認發數據人的身份，就需要認證。這里server會先把證書發給client，client用事先內置的第三方權威認證中心的公鑰解密證書，來確認這個證書是不是server發過的（緊接着下一個certificates verify字段就是干這個的）！這兩個證書就是google發給client的證書。證書里面有google生成的ECC的公鑰，用於和client協商生成對稱加密的密鑰；既然是證書，包含的內容有很多，兩個證書一共有3532byte；
證書中比較重要的字段：
1） issuer：這個證書的頒發者
2）validity：證書有效期
3）subject：這個證書頒發給誰的，這里明顯是google；
4）subjectPublicKeyInfo：server的公鑰信息。這里能看出來采用了secp256r1曲線，並提供了server的公鑰給client；后續client會根據這個公鑰生成對稱密鑰；
- handshake Protocol：certificate verify；這里選用的是secp256r1橢圓曲線來做認證，確保服務器發過來的certificates是沒有被篡改的；certificate的hash值是用sha256計算出來的，長71byte；
- handkshake Protocol：Finished；Finished消息是身份驗證階段的最后一條消息，也是第一個使用協商的算法簇進行加密和防篡改保護的消息；Verify Data是通過HMAC計算得來的，包含finished_key和握手消息的hash。 verify_data =HMAC(finished_key,Transcript-Hash(Handshake Context,Certificate, CertificateVerify))
3、 至此，所有的application data都被解密，並還原成了http包：
隨便打開一個http包，所有的head信息都能看到：
4、最后做個總結：tls1.3中雙方握手通信的流程圖如下：
- +表示該報文中值得注意的extension
- * 表示該內容也可能不被發送
- {} 表示該內容使用handshake_key加密
- [] 表示該內容使用application_key加密
其中：（1）handshake_key是由我們使用的PSK與前兩次報文，使用HKDF（內建的某函數，其中會使用到加密套件指定的哈希算法）導出而來的
（2）application_key則是以整個握手階段的報文作為輸入，計算四次HKDF導出而來
補充：剛開始學這些通信協議的時候會遇到各種證書，不太能分得清，這里系統性總結一下：
（1）根證書：由全球權威機構頒發，在瀏覽器或操作系統出廠時就內置好的（當然證書是可以增加的，如fiddler的證書）；chorome查詢如下：
根證書核心的功能之一是提供公鑰，作為信任鏈建立的起點！證書內容如下：
（2）中間機構頒發機構：由根證書機構簽發的，可直接用戶簽發網站的證書！這里的證書也是可以添加的，比如fiddler；內容和根證書一樣！
（3）個人證書：這里面都是fiddler為了抓包而頒發的，目的是欺騙客戶端！
從上面的截圖可以看到，為了作為中間人抓包，fiddler在3個地方都安裝了證書，這些證書都是怎么工作的了？ 為什么安裝了證書的fiddler就能解密https這些加密的數據包了？
- 首先：fiddler要求用戶把自己的證書安裝在受信任的根證書頒發機構，fiddler證書就成了CA根證書；
- 其次：再用這個CA根證書給自己頒發中間證書；最后再用這個中間證書偽造各個網站的證書；
- 最后：一旦攔截客戶端的訪問請求，就把偽造的這些網站證書發給客戶端，讓客戶端誤以為fiddler就是目標網站，達到欺騙的目的！具體做法就是fiddler在偽造的個人證書中內置自己的公鑰，后續客戶端會利用這個公鑰、根據tls1.3協議生成各種premaster key、session key等，fiddler截獲后可以直接解密數據了！在客戶端看來，以為通信的對方就是網站，其實是fiddler！罪惡之源就是CA根證書被更改，導致整個信任鏈建立的起點被篡改！
參考：
1、https://gohalo.me/post/decrypt-tls-ssl-with-wireshark.html 使用 Wireshark 解密 SSL/TLS 流量
2、https://strawberrytree.top/blog/2020/09/17/%E4%BD%BF%E7%94%A8openssl%E4%BD%BF%E7%94%A8%E5%A4%96%E9%83%A8psk%E8%BF%9B%E8%A1%8C%E6%8F%A1%E6%89%8B%EF%BC%88tls1-3%EF%BC%89/ 使用OpenSSL指定加密套件使用外部PSK進行握手（TLS1.3，OpenSSL3.0）
3、https://zh.wikipedia.org/wiki/%E6%A0%B9%E8%AF%81%E4%B9%A6 根證書