Https、SSL/TLS相關知識及wireShark抓包分析

1、網絡通訊的三大風險

在HTTP協議中，全部報文的發送、接收都是以明文的形式進行的。也就是說，在TCP/IP五層網絡模型中，數據直接以明文的形式從應用層（HTTP）發送給傳輸層（TCP），之間沒有任何加密過程，以下圖所示：

這將帶來如下三大風險：

• 一、竊聽/嗅探風險

  中間人能夠截獲客戶端、服務器之間的通訊數據，一覽無遺。

• 二、數據篡改風險

  中間人截獲數據以後，能夠對數據修改以後再發生給對方。

• 三、身份僞造風險

  因爲網絡通訊自己的特殊性，通訊雙方沒法具體識別對方的身份，中間人可趁機而入。

那麼，針對上面的三大風險，咱們有什麼樣的對策嗎？有的。

• 一、針對竊聽/嗅探風險，咱們能夠對數據使用密碼加密算法進行加密，即便中間人截獲了咱們的數據，因爲沒有相應的解密密鑰，拿到了數據也無法破解。

• 二、針對篡改風險，咱們可使用相關的數字簽名算法，保障數據的完整性。

• 三、針對身份僞造風險，咱們能夠經過頒發數字證書來證實對方的身份。

固然了，並非說HTTP協議自己就必定存在上面的三大風險，咱們也可使用HTTP協議，在數據傳輸以前對數據進行加密或者數字簽名，一樣也能夠最大程度避免竊聽和篡改風險，可是並不能杜絕，由於沒有絕對地安全。

2、SSL/TLS協議

SSL/TLS 和 HTTPS 協議聯繫很是緊密，HTTPS 是在 SSL/TLS 協議基礎之上創建起來的。

能夠這麼理解，HTTPS 中的 S ，指的就是 SSL/TLS 協議自己。

一、發展歷史

上面簡單總結了關於SSL/TLS協議的發展歷程，更加詳細的瞭解，能夠參閱維基百科傳輸層安全性協議 。SSL協議是TLS協議的前身，是SSL協議的改進版本。

二、網絡層次

SSL/TLS協議位於應用層和傳輸層之間，用於對上層數據包加密以後傳輸，同時進行身份、數據完整性校驗。

三、基本原理

簡單地講，SSL/TLS就是同時結合各類密碼算法、數字簽名算法及數字證書等技術的一套協議，目的就是爲了保證通訊的安全性。

採用SSL/TLS協議，通訊雙方創建鏈接以前須要進行握手，目的是協商出會話密鑰，用於後續對通訊數據的加解密操做。

加密算法分爲兩大類：

• 一、對稱加密算法

  數據加解密使用同一份密鑰，加解密速度快，效率高，缺點是密鑰的管理難度大，一旦密鑰傳輸泄露，那就沒啥用處了。

• 二、非對稱加密算法

  數據加解密使用公鑰和私鑰，公鑰用於傳輸，私鑰本身保存，安全性較高，但加解密速度偏慢。

而SSL/TLS則結合二者的優缺點，數據包的加密使用對稱加密算法，而對稱加密算法的密鑰採用非對稱加密手段協商獲取。

經常使用的對稱加密算法有：DES、3DES、Blowfish、IDEA、RC四、RC五、RC6和AES

經常使用的非對稱加密算法有：RSA、ECC（移動設備用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）

經常使用的數字簽名算法有：MAC、MD五、SHA1

3、Wireshark抓包分析

下面使用Wireshark抓包工具簡單分析下HTTPS協議的握手過程，以訪問百度爲慄：https://www.ifeng.com

首先咱們要知道握手的目的就是爲了解決上面的三大風險，即協商出對話密鑰，驗證數據完整性、身份認證等。

從上圖大體能夠總結出握手的基本流程：

• 一、客戶端向服務器端發送一個Client Hello
• 二、服務器端想客戶端返回一個Server Hello
• 三、服務器端向客戶端返回一個Certificate
• 四、服務器端向客戶端返回Server key change,Server Hello Done
• 五、客戶端向服務器端發送Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
• 六、服務器端向客戶端返回Change Cipher Spec, Encrypted Handshake Message

下面具體分析每一步的詳細內容：

• 一、Client Hello中攜帶了什麼信息呢？

Client Hello中攜帶了當前客戶端支持的TLS協議的版本號（Version）、客戶端支持的加密套件（Cipher Suites）、一個隨機數、客戶端支持的壓縮算法（Compression Method）

• 二、Server Hello中又返回了什麼信息呢？

第一步客戶端告訴服務端我所支持的相關信息，第二步服務端協商返回肯定的信息，如肯定使用哪一種加密套件（Cipher Suites）或壓縮方法等。

• 三、服務器給客戶端下發一份證書

• 四、服務器端返回給客戶端相關D-H算法參數

這些參數後期客戶端能夠算出會話密鑰，若是使用的是RSA算法，那麼這一步是不須要的。傳遞完參數以後，告訴客戶端服務器端的握手結束（Done）了。

• 五、Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

這一步，客戶端根據第四步傳過來的公鑰，生成一個叫預備-主密鑰的pre-master key,而後Client Key Exchange將這個預備-主密鑰傳給服務器端。服務器端結合本身的私鑰解出這個預備-主密鑰的信息，獲得第三個隨機數，因此，到目前爲止，客戶端和服務器都擁有 Random1 + Random2 + Random3。

緊接着兩邊根據D-H算法及第四步傳遞的相關參數生成一個會話密鑰，後續就使用這個密鑰進行通訊了。能夠看出，會話密鑰能不能被破解，關鍵看第三個隨機數能不能被破解，並且第三個隨機數用wireShark是抓取不到的。

Change Cipher Spec這一步是告訴服務器端後期的通訊都會使用咱們協商出來的密鑰進行通訊。

Encrypted Handshake Message是客戶端將前面的握手消息生成摘要再用協商好的祕鑰加密（對稱加密），這是客戶端發出的第一條加密消息。服務端接收後會用祕鑰解密，能解出來講明前面協商出來的祕鑰是一致的。

• 六、Change Cipher Spec, Encrypted Handshake Message

同第5步，若是服務器端經過D-H算法可以解密摘要，那麼服務器端應該告訴客戶端說咱們之間協商的會話密鑰是一致的。

以上是小編對SSL/STL、HTTPS的簡單理解，更全面的知識，可自行查閱RFC相關規範文檔。因爲小編學識尚淺，若有不正確的地方，請指出，謝謝！