為什麼Wireshark無法解密HTTPS資料

為什麼Wireshark無法解密HTTPS資料
導讀由於需要定位一個問題，在伺服器上tcpdump抓取https資料包，然後下載到本地開啟wireshark分析。然後我們下載網域名稱私密金鑰配置到wireshark，探索資料包居然無法解密。是wireshark配置密鑰的方法不對？但Google了好多文章都是說這樣配置的。由於對HTTPS認識不夠深,一時不知道如何入手解決。沒辦法，只能先瞭解tls這個協議了，於是查看了TLS1.2的RFC文檔，終於勉強解答了這個疑惑。TLS握手整個過程

在解決這個問題之前，先整體瞭解一下TLS的握手全過程。省略了不常見的過程。

下面按順序介紹各握手步驟。

Client Hello

這是TLS握手的第一步，由用戶端發起請求。此協議主要包括了一個用戶端產生的隨機字串（用來下面產生session key），還有用戶端支援的加密套件列表。

Server Hello

伺服器收到用戶端的Client Hello資料包之後，根據用戶端發來的加密套件列表，選擇一個加密套件，也產生一個隨機字串返回給用戶端。我們看到中的加密套件為，金鑰交換演算法使用ECDHE_RSA，對稱式加密演算法使用AES_256_GCM_SHA384,

Server Certificate

Server Key Exchange協議包，由伺服器返回，主要目的是與用戶端交換用於資料對稱式加密的密鑰。

Server Hello Done

伺服器返回此協議資料，告訴用戶端已經完成返回所需用於金鑰交換的資料。伺服器等待用戶端響應。

Client Key Exchange

用戶端根據伺服器返回的DH密鑰資料產生DH公用資料也發給伺服器，用來產生最終的pre-master-secret。

Change Cipher Spec

此協議用於用戶端和伺服器相互告知也完成金鑰交換過程，可以切換到對稱式加密過程。
到這裡大概的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 ‎