一、網路通訊的三大風險
在HTTP協議中，所有報文的傳送、接收都是以明文的形式進行的。也就是說，在TCP/IP五層網路模型中，資料直接以明文的形式從應用層（HTTP）傳送給傳輸層（TCP），之間沒有任何加密過程，如下圖所示：
這將帶來以下三大風險：
-
1、竊聽/嗅探風險
中間人可以截獲客戶端、伺服器之間的通訊資料，一覽無遺。
-
2、資料篡改風險
中間人截獲資料之後，可以對資料修改之後再發生給對方。
-
3、身份偽造風險
由於網路通訊本身的特殊性，通訊雙方無法具體識別對方的身份，中間人可趁機而入。
那麼，針對上面的三大風險，我們有什麼樣的對策嗎？有的。
-
1、針對竊聽/嗅探風險，我們可以對資料使用密碼加密演算法進行加密，即使中間人截獲了我們的資料，由於沒有相應的解密金鑰，拿到了資料也沒法破解。
-
2、針對篡改風險，我們可以使用相關的數字簽名演算法，保障資料的完整性。
-
3、針對身份偽造風險，我們可以通過頒發數字證書來證明對方的身份。
當然了，並不是說HTTP協議本身就一定存在上面的三大風險，我們也可以使用HTTP協議，在資料傳輸之前對資料進行加密或者數字簽名，同樣也可以最大程度避免竊聽和篡改風險，但是並不能杜絕，因為沒有絕對地安全。
二、SSL/TLS協議
SSL/TLS 和 HTTPS 協議聯絡非常緊密，HTTPS 是在 SSL/TLS 協議基礎之上建立起來的。
可以這麼理解，HTTPS 中的 S ，指的就是 SSL/TLS 協議本身。
1、發展歷史
上面簡單總結了關於SSL/TLS協議的發展歷程，更加詳細的瞭解，可以參閱維基百科傳輸層安全性協議 。SSL協議是TLS協議的前身，是SSL協議的改進版本。
2、網路層次
SSL/TLS協議位於應用層和傳輸層之間，用於對上層資料包加密之後傳輸，同時進行身份、資料完整性校驗。
3、基本原理
簡單地講，SSL/TLS就是同時結合各種密碼演算法、數字簽名演算法及數字證書等技術的一套協議，目的就是為了保證通訊的安全性。
採用SSL/TLS協議，通訊雙方建立連線之前需要進行握手，目的是協商出會話金鑰，用於後續對通訊資料的加解密操作。
加密演算法分為兩大類：
-
1、對稱加密演算法
資料加解密使用同一份金鑰，加解密速度快，效率高，缺點是金鑰的管理難度大，一旦金鑰傳輸洩露，那就沒啥用處了。
-
2、非對稱加密演算法
資料加解密使用公鑰和私鑰，公鑰用於傳輸，私鑰自己儲存，安全性較高，但加解密速度偏慢。
而SSL/TLS則結合兩者的優缺點，資料包的加密使用對稱加密演算法，而對稱加密演算法的金鑰採用非對稱加密手段協商獲取。
常用的對稱加密演算法有：DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES
常用的非對稱加密演算法有：RSA、ECC（移動裝置用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）
常用的數字簽名演算法有：MAC、MD5、SHA1
三、Wireshark抓包分析
下面使用Wireshark抓包工具簡單分析下HTTPS協議的握手過程，以訪問百度為慄：https://www.ifeng.com
首先我們要知道握手的目的就是為了解決上面的三大風險，即協商出對話金鑰，驗證資料完整性、身份認證等。
從上圖大致可以總結出握手的基本流程：
- 1、客戶端向伺服器端傳送一個
Client Hello - 2、伺服器端想客戶端返回一個
Server Hello - 3、伺服器端向客戶端返回一個
Certificate - 4、伺服器端向客戶端返回
Server key change,Server Hello Done - 5、客戶端向伺服器端傳送
Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message - 6、伺服器端向客戶端返回
Change Cipher Spec, Encrypted Handshake Message
下面具體分析每一步的詳細內容：
- 1、
Client Hello中攜帶了什麼資訊呢？
Client Hello中攜帶了當前客戶端支援的TLS協議的版本號（Version）、客戶端支援的加密套件（Cipher Suites）、一個隨機數、客戶端支援的壓縮演算法（Compression Method）
- 2、
Server Hello中又返回了什麼資訊呢？
第一步客戶端告訴服務端我所支援的相關資訊，第二步服務端協商返回確定的資訊，如確定使用哪種加密套件（Cipher Suites）或壓縮方法等。
- 3、伺服器給客戶端下發一份證書
- 4、伺服器端返回給客戶端相關D-H演算法引數
這些引數後期客戶端可以算出會話金鑰，如果使用的是RSA演算法，那麼這一步是不需要的。傳遞完引數之後，告訴客戶端伺服器端的握手結束（Done）了。
- 5、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是客戶端將前面的握手訊息生成摘要再用協商好的祕鑰加密（對稱加密），這是客戶端發出的第一條加密訊息。服務端接收後會用祕鑰解密，能解出來說明前面協商出來的祕鑰是一致的。
- 6、Change Cipher Spec, Encrypted Handshake Message
同第5步，如果伺服器端通過D-H演算法能夠解密摘要，那麼伺服器端應該告訴客戶端說我們之間協商的會話金鑰是一致的。
以上是小編對SSL/STL、HTTPS的簡單理解，更全面的知識，可自行查閱RFC相關規範文件。由於小編學識尚淺，如有不正確的地方，請指出，謝謝！