在解決這個問題之前，先整體了解一下TLS的握手全過程。省略了不常見的過程。如圖：
下面按順序介紹各握手步驟。
這是TLS握手的第一步，由客戶端發起請求。此協議主要包括了一個客戶端生成的隨機字符串（用來下面生成session key），還有客戶端支持的加密套件列表。如圖：
服務器收到客戶端的Client Hello數據包之後，根據客戶端發來的加密套件列表，選擇一個加密套件，也生成一個隨機字符串返回給客戶端。我們看到下圖中的加密套件為，密鑰交換算法使用ECDHE_RSA，對稱加密算法使用AES_256_GCM_SHA384,如圖：
Server Key Exchange協議包，由服務器返回，主要目的是與客戶端交換用於數據對稱加密的密鑰。如圖：
服務器返回此協議數據，告訴客戶端已經完成返回所需用於密鑰交換的數據。服務器等待客戶端響應。
Client Key Exchange客戶端根據服務器返回的DH密鑰數據生成DH公共數據也發給服務器，用來生成最終的pre-master-secret。如圖：
此協議用於客戶端和服務器相互告知也完成密鑰交換過程，可以切換到對稱加密過程。
到這裡大概的TLS握手過程就結束了。為解決本文中的問題，還需要了解密鑰交換的算法，RSA和Diffie–Hellman。
密鑰交換算法目前常用的有RSA和Diffie-Hellman。
對於密鑰交換使用RSA算法，pre-master-secret由客戶端生成，並使用公鑰加密傳輸給服務器。
對於密鑰交換使用Diffie-Hellman算法，pre-master-secret則通過在Key Exchange階段交換的信息，由各自計算出pre-master-secret。所以pre-master-secret沒有存到硬盤，也沒有在網絡上傳輸，wireshark就無法獲取session key，也就無法解密應用數據。那我們是否可以反向計算出pre-master-secret呢？理論上可以，但是非常困難。
對Diffie-Hellman算法感興趣的可以參考https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
說了這麼多，究竟有什麼辦法可以讓wireshark解密數據？我們可以通過下面幾種方法來使wireshark能解密https數據包。
1. 中間人攻擊;
2. 設置web服務器使用RSA作為交換密鑰算法;
3. 如果是用chrome,firefox，可以設置導出pre-master-secret log，然後wireshark設置pre-master-secret log路徑，這樣就可以解密了。
原文地址：https://www.centos.bz/2015/12/why-wireshark-can-not-decrypt-https-data/
轉載地址：http://www.linuxprobe.com/linux-wireshark-https.html
http://xxxxxx/Linuxjc/1139902.html TechArticle
