首先使用wireshark而且打開瀏覽器,打開百度(百度使用的是HTTPS加密),隨意輸入關鍵詞瀏覽。css
我這裏將抓到的包進行過濾。過濾規則以下web
ip.addr == 115.239.210.27 && ssl
下面用圖來描述一下上面抓包所看到的流程。
算法
打開抓包的詳細,以下。
chrome
不難看出,這一握手過程,客戶端以明文形式傳輸了以下信息:瀏覽器
這一階段,服務端返回所選擇的協議版本(Version),加密套,壓縮算法,隨機數,Session ID等;服務器
from:https://blog.csdn.net/u010536377/article/details/78989931網絡
通過了 SSL 握手後,服務端的身份認證成功,協商出了加密算法爲 AES,密鑰爲 xxxxx(客戶端和服務端拿三個隨機值用相同算法計算出來的,並無明文傳輸)。一切準備就緒。session
SSL 握手成功,已經能夠對接下來的數據加密了,接下來各類應用層協議均可以加密傳輸。加密
應用數據傳輸消息。由於這裏是 HTTPS,因此能夠對 HTTP 應用協議數據加密而後傳輸了。spa
Secure Sockets Layer TLSv1.2 Record Layer: Application Data Protocol: http Content Type: Application Data (23) Version: TLS 1.2 (0x0303) Length: 1072 Encrypted Application Data: 6d9b3c9089271630c33506fe28cd6a61fed1f4bd2808f537...
從這裏,不知道密鑰是沒法知道這裏傳輸的是什麼數據,連傳輸的是什麼協議的內容都不知道。
因此以前建立 SSL 隧道,讓代理服務器盲傳 HTTPS 數據,就得經過 CONNECT 方法告訴代理服務器要連哪臺主機,哪一個端口號,要否則代理服務器也是一臉懵逼。
因此 SSL 協議是很獨立的,這裏是對 HTTP 進行了加密,也能夠對其餘協議進行加密。它就像是 TCP 和應用層協議的中間層,爲上層協議提供了加密的數據傳輸。
SSL 警告消息,由於是加密的內容,因此單從 Wireshark 看不出警報的內容。
Secure Sockets Layer TLSv1.2 Record Layer: Encrypted Alert Content Type: Alert (21) Version: TLS 1.2 (0x0303) Length: 48 Alert Message: Encrypted Alert
但由於警報消息常常只是客戶端用來提示服務端 SSL 傳輸結束,對照抓包到的內容確實如此。因此這裏只是 SSL 傳輸結束的一個信號。
發出了 Encryted Alert 後客戶端數據傳輸完畢,準備進入四次揮手斷開 TCP 鏈接。
密鑰交換算法目前經常使用的有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路徑,這樣就能夠解密了。