深入淺出HTTPS

前言
在之前的文章《深入淺出密碼學（上）》、《深入淺出密碼學（中）》與《深入淺出密碼學（下）》中，沉思君爲大家介紹了密碼學中一些重要的概念，例如：加密、單向散列函數、消息認證碼與數字簽名等，如果不太清楚的朋友可以點擊文章鏈接進行閱讀。今天我們要講的是密碼學的一個非常廣泛且重要的應用——HTTPS。
在講解HTTPS前，我們先來講下HTTP。HTTP的名稱是超文本傳輸協議，其特點是無狀態性、不安全、單向通信（即不支持服務端推送，至少在HTTP1.1版本不支持）。關於無狀態性，沉思君在之前的文章《談談HTTP狀態保持》中有所提及，感興趣的讀者可以點擊鏈接進行閱讀。今天我們要講的主要是HTTP的不安全性，爲什麼說HTTP是不安全的呢？原因是HTTP協議使用明文進行傳輸，因此存在數據被竊聽的風險，此外，HTTP也沒有使用單向散列函數與消息認證碼等機制，因此數據存在被篡改和僞裝的風險，所以說HTTP協議是不安全的協議。爲了解決HTTP的不安全性，人們開始使用HTTPS協議進行數據傳輸。接下來將爲大家介紹下HTTPS的原理。
HTTPS概述
HTTPS的名稱是超文本傳輸安全協議，HTTPS經由HTTP進行通信，但利用SSL/TLS來加密數據包。HTTPS開發的主要目的，是提供對網站服務器的身份認證，保護交換數據的隱私與完整性。HTTPS並不是一種新的應用層協議，只是HTTP接口通信部分用SSL/TLS代替而已。簡而言之，HTTPS就是身披SSL/TLS外殼的HTTP。HTTP與HTTPS的網絡分層模型如下：
由此可見，HTTPS的核心是SSL/TLS，接下來將爲大家介紹SSL/TLS。
SSL/TLS概述
SSL和TLS都是加密協議，旨在基於不安全的基礎設施提供安全通信。這意味着，如果正確部署這些協議，你就可以對互聯網上的任意一個服務打開通信信道，並且可以確信你會與正確的服務器通信，安全地交換信息。簡而言之，SSL和TLS旨在爲不安全的應用層協議（如：HTTP）提供安全可靠的數據傳輸。其中TLS是SSL的升級版本，下文的介紹都是基於TLS。
TLS層次結構
首先，我們來看下TLS的層次結構。TLS是由“TLS記錄協議”跟“TLS握手協議”組成的。其中，"TLS記錄協議"負責對數據進行加密，而“TLS握手協議”則負責除加密之外的其他操作。在之前介紹密碼學的文章中，我們知道，加密、消息認證碼跟數字簽名都需要使用密鑰，既然TLS能夠對數據進行加密和認證，那麼它也必須使用到密鑰，那麼TLS通信雙方的密鑰是如何進行協商的呢？這就是“TLS握手協議”最主要的功能了，接下來我們將重點介紹“TLS握手協議”，即TLS是如何協商產生加密與認證所需的密鑰的。
TLS握手協議
TLS握手協議負責生成共享密鑰和交換證書。其中共享密鑰是爲了進行加密通信，交換證書是爲了通信雙方能夠相互認證。握手協議的細節如下：
ClientHello(客戶端→服務端)
客戶端發送消息給客戶端，告訴服務端自己支持的加密套件與其他信息。主要包含以下信息：
支持的密碼套件、支持的壓縮套件、可用的版本號、客戶端隨機數、會話id。其中，客戶端隨機數的作用在後文會介紹。
ServerHello(服務端→客戶端)
服務端回覆客戶端通信過程中使用的加密套件與其他信息。主要信息如下：
使用的密碼套件、使用的壓縮套件、使用的版本號、服務端隨機數、會話id。其中，服務端隨機數與客戶端隨機數無關，其作用在後文會介紹。
Certificate(服務端→客戶端)
服務端發送證書給客戶端。證書中包含了服務端的公鑰，可用於後續的加密或認證。
ServerKeyExchange(服務端→客戶端)
當第3步的信息不足以滿足需求時，服務端會在這一步發送其他必要的加密需要的信息給客戶端。
CertificateRequest(服務端→客戶端)
接着服務端向客戶端請求證書信息，這一步不是必要的，取決於服務端是否需要對客戶端身份進行驗證。
ServerHelloDone(服務端→客戶端)
服務端問候信息結束。
Certificate(客戶端→服務端)
客戶端發送自己的證書給服務端（如果服務端有請求客戶端的證書的話）。
ClientKeyExchange(客戶端→服務端)
客戶端發送經過加密的預備主密鑰給服務端。預備主密鑰由客戶端加密，可用於生成主密鑰，主密鑰則是整個會話過程中用戶加密和認證的密鑰。那麼客戶端是如何對預備主密鑰進行加密的呢？別忘了在第3步，服務端已經把它的證書發送給客戶端了，而證書中包含了服務端的公鑰，所以這裏客戶端是使用服務端的公鑰加密預備主密鑰的。
CertificateVerify(客戶端→服務端)
客戶端向服務端證實自己的確持有客戶端私鑰，即證明客戶端確實是客戶端證書的持有者。
ChangeCipherSpec(客戶端→服務端)
客戶端告訴服務端自己要切換密鑰了。由於在第8步，服務端跟客戶端已經協商了預備主密鑰了，而在第2步也協商了密鑰交換算法，所以在這一步，服務端跟客戶端就可以根據密鑰交換算法跟預備主密鑰生成主密鑰了。因此這一步客戶端告訴服務端自己將使用主密鑰進行通信了。
Finished(客戶端→服務端)
客戶端告訴服務端握手協議結束了。
ChangeCipherSpec(服務端→客戶端)
服務端告訴客戶端自己也要切換密鑰進行通信了。
Finished(服務端→客戶端)
服務端告訴客戶端握手協議結束了。
切換到TLS記錄協議
客戶端與服務端將切換到TLS記錄協議進行通信。
以上就是TLS握手協議的全過程。
讀者也許會有疑問，主密鑰是根據預備主密鑰生成的，那麼究竟是怎樣生成的呢？還有就是第1步跟第2步的隨機數有什麼用呢？其實第一步跟第2步的隨機數正是爲了生成主密鑰而服務的。主密鑰正是由預備主密鑰跟客戶端隨機數還有服務端隨機數生成的。至於怎麼生成，取決於具體的密鑰交換算法，常見的密鑰交換算法是RSA密鑰交換和DH密鑰交換，有興趣的朋友可以去深入瞭解下。
生成的主密鑰主要有2個用途：
作爲對稱加密的密鑰，對數據進行加密，防止竊聽。
作爲消息認證碼的密鑰，對數據進行認證。防止篡改和僞裝。
故而實現了安全通信。