起因
需要呼叫一個https服務，獲取token，再攜帶token呼叫對應系統傳送報文。
在postman測試中，token可以正常獲取，攜帶token併傳送GET請求也可以正常傳送請求返回資料。
但是在應用程式使用中發現GET請求始終無法呼叫成功，response狀態碼405。應用使用HttpURLConnection進行請求，後續刪除部分不使用的程式碼後居然通了。
想深入理解https請求道理經歷了什麼改變，從不可用變為可用。
Wireshark攔截應用程式https請求資料
最初的想法使用wireshark監控本地網路資料，找到對應https解析後觀察問題原因。
跟據TLS協議握手邏輯，在wireshark中使用正確證書、金鑰等方式，將請求解析。
金鑰獲取方式：
-
透過windwsi配置環境變數SSLKEYLOGFILE，再透過chrome瀏覽器匯出到金鑰檔案中，透過wireshare匯入金鑰檔案，進行解析。
-
透過Fiddler代理請求，然後匯出證書，再透過證書生成金鑰等檔案資訊，匯入wireshare，進行解析。
可惜2種方式都沒解決掉。
搜尋原因，分析為tls1.2本地與服務端協商的套件為TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384，現在瀏覽器預設使用ECDHE的加密型別，作為套件使用，wireshare無法處理此型別https請求解析。
嚴重懷疑：1、直接透過Fiddler就可以解決我的需求。2、Wireshark還是沒用明白。
Charles安裝
主要就是以下步驟：
- 安裝後的註冊（否則30天試用）。
- 對於SSL代理的配置，需要把瀏覽器授信根證書引入程式。
- 設定SSL代理的域名、埠。
postman的https請求代理
開啟Charles的攔截後，傳送postman直接攔截成功。
觀察請求頭資料，一切正常加密套件確認為TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384。
應用程式的https請求代理
開啟Charles的攔截後，應用傳送請求居然沒顯示攔截？？？
查了各種資料，對Charles針對性配置，仍然無效。再對windows系統進行配置仍然無效。判斷應為程式問題，程式使用HttpURLConnection傳送請求，發現需要設定Proxy物件，才能成功被Charles攔截。
觀察後發現HttpURLConnection存在一個坑，雖然在編寫過程設定了請求為GET方式，但是透過HttpURLConnection獲取了輸出流，雖然沒有傳入任何引數，請求方式在Charles中顯示為POST。
思考
- Charles本質為代理或者說是中間人攻擊，https請求必須流經Charles才能被攔截到，例如：A -> Charles -> 計算機網路底層 -> B。
- HttpURLConnection傳送請求的方式，網路層級應該比Charles更低。
- 但是postman為什麼直接能被Charles攔截？是因為網路層級與Charles一致或更高麼。
- Wireshark的所處的網路層級一定比Charles低，那是否可以透過伺服器證書解析請求、響應資訊呢？
總結
- Fiddler確實也能解決這個問題，找到的資料是透過fiddler將https代理到另一個本地伺服器，解析資訊。
- Wireshark應該可以解析瀏覽器傳送的https請求，透過應用貌似需要程式特殊配置。
- HttpURLConnection傳送GET請求失敗，居然因為呼叫getOutputStream()方法後請求型別變為了POST，哪怕是沒有對輸出流新增任何資料。
巨人的肩膀
Charles抓取https請求及常見問題解決
charles高階篇：過濾請求、串改請求、上行下行超時、弱網
使用 RSA 金鑰交換方式時，使用私鑰解密 HTTPS 流量資料 (timd.cn)
使用 Key Log 解密 TLS 流量 (timd.cn)
使用 MITM 的方式，解密 HTTPS 流量 (timd.cn)
計算機網路筆記 (timd.cn)
HTTPS中間人攻擊實踐（原理·實踐）
如何透過Wireshark檢視HTTPS、HTTP/2網路包（解碼TLS、SSL）
抓包工具Charles使用，中間人攻擊，手機抓包 - 技術改變命運Andy - 部落格園 (cnblogs.com)
清晰圖解https如何防範中間人攻擊_公鑰密碼體系防止中間人-CSDN部落格