一、 簡介
- SSL（Secure Socket Layer 安全套接層），由網景在20世紀90年代開發的安全協議；
- 1995年Netscape發布SSL v2.0
- 1996年Netscape發布SSL v3.0
- 1999年 IETF(Internet工程任務組)發布TLS v1.0，用于替代SSL v3.0
- 2006年 發布TLS v1.1
- 2008年 發布TLS v1.2
- 2018年 發布TLS v1.3
至2020年3月，微軟、蘋果、谷歌等多家企業已棄用TLS v1.0 和 TLS v1.1。
目前，應用最廣泛的是TLS 1.0，接下來是SSL 3.0。但是，主流瀏覽器都已經實現了TLS 1.2的支持。TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。
二 、通信模式演化
- 正常通訊，無加密通信過程很不安全，黑客可以監聽雙方的通信、攔截通信、偽造數據進行攻擊。
- 使用密鑰加密為了應對攻擊，對通信數據使用對稱加密算法進行加密。通信雙方需要共享密鑰。1981年，出現對稱加密算法DES。DES使用56bit的密鑰。但由于雙方需要共享密鑰，這個密鑰在傳輸過程中有可能被攔截。
- 更高強度的密鑰DES可能被暴力破解。為了更高的安全性，出現了triple-DES(最長168bit密鑰)、AES (最高 256bit密鑰 )。這仍沒解決雙方傳遞共享密鑰的問題。
- 非對稱加密最著名的非對稱加密算法RSA算法，其加密與解密使用不同密鑰，加密的密鑰可以公開。這樣可以有效解決雙方共享密鑰的問題。在使用中，通訊雙方都有一個公鑰和私鑰。
A要給B發網絡數據流程：
- A使用私鑰加密數據的hash值
- A再用B的公鑰加密數據。
- A將加密的hash值和加密的數據加上一些其它信息（如時間戳）發給B
- B 先用私鑰解密數據
- B本地運行一個hash值
- B用A的公鑰解密hash值，與自己運行的比較，檢驗數據完整性。但最初通訊交換公鑰的過程，仍存在被中間人攻擊的可能。
- 使用可信任機構頒布數字證書
三 、HTTPS
HTTP Over SSL，就是通過SSL/TLS加密HTTP數據。證書鏈檢測工具： myssl.com
四、SSL/TLS 基本運行過程
1. 整體通訊流程
- 客戶端向服務器端索要并驗證公鑰
- 雙方協商生成“對話密鑰”
- 雙方采用“對話密鑰”進行加密通信。
SSL/TLS 使用非對稱加密 。
- 保證公鑰不被篡改：將公鑰放在數字證書中，只要證書是可信的，公鑰就是可信的。
- 每一次對話，雙方生成一個對稱密鑰，用來加密信息，采用對稱加密。 非對稱加密只用來加密對稱加密的密鑰。
流程示意圖：
通訊抓包示意圖：
2. 握手階段詳細過程
握手階段涉及4次通信。
4.1 客戶端發出請求(Client Hello)
客戶端數據主要包含：
- 支持的協議版本，如TLS 1.2版
- 一個客戶端生成的隨機數，稍后用于生成公鑰
- 支持的加密方法 ，如RSA
- 支持的壓縮方法。
客戶端發送的信息中不包括服務器的域名。2006年，TLS協議加入了一個Service Name Indication擴展，允許客戶端向服務器提供它所請求的域名。
支持的加密算法示例：
4.2 服務器回應(Server Hello)
服務器收到客戶端請求后，向客戶端發出回應，包含：
- 確認使用的加密通信協議版本，比如TLS 1.2版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。
- 一個服務器生成的隨機數，稍后用于生成"對話密鑰"。
- 確認使用的加密方法，比如RSA公鑰加密。
- 服務器證書。
如果是雙向認證，服務器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供客戶端證書。即金融機構服務器端只允許認證客戶連入自己的網絡，會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。下面是單向認證抓包示意，Server Hello分成兩個包發送。
4.3 客戶端回應
客戶端收到服務器回應以后，首先驗證服務器證書。如果有以下問題：
- 證書不是可信機構頒布
- 或者證書中的域名與實際域名不一致
- 或證書已經過期
這時就會向訪問者顯示一個警告，由用戶選擇是否還要繼續通信。
如果證書沒有問題，客戶端就會從證書中取出服務器的公鑰，然后，向服務器發送以下信息：
- 一個隨機數，用服務器公鑰加密，稱為pre-master key。
- 編碼改變通知，表示隨后的信息將用雙方商定的加密方法 和密鑰發送
- 客戶端握手結束通知，表示客戶端的握手階段已經結束。 這一項同時也是前面發送的所有內容的hash值，用來供服務器檢驗。
客戶端與服務器同時有了三個隨機數，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把”會話密鑰“。
使用三次隨機數，防止有的主機生成的只是偽隨機數。
4.4 服務器回應
服務器收到客戶端的第三個隨機數pre-master key之后，計算生成本次會話所用的”會話密鑰“，然后給客戶端發送下面信息：
- 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法 和密鑰發送。
- 服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供客戶端檢驗。
