更安全的Web通訊HTTPS

YinTokey發表於2019-03-01

WebHTTP

1. HTTP協議存在的問題

閱讀本篇需要對HTTP協議有最基本的瞭解。借用《圖解密碼技術》裡的圖片，我們以如下一個購物場景開始介紹：

在網購過程中，如果使用純粹的HTTP協議，那麼使用者的賬號密碼，信用卡，銀行卡資訊都將在資訊傳輸過程中直接裸奔。從例子中我們可以看到信用卡資訊直接被明文傳輸了。除了明文傳輸之外，還存在著以下兩個問題:

無法驗證通訊方身份的真實性，即無法確認對方是否是真正的商家。
無法確認資訊是否被篡改，即無法確認傳輸過程信用卡資訊和收貨地址是否被篡改過。

常規情況下，可以對通訊的內容進行加密，來避免明文傳輸的問題。但是單靠這點，無法解決資訊完整性和認證問題。為了解決這些問題，需要對通訊進行加密。也就引入了 HTTPS 。

2. HTTPS結構

2.1 HTTPS與HTTP

HTTPS 本身並不是一個協議，它使用 SSL/TLS 作為對通訊加密的協議，承載 HTTP ，將兩種協議疊加，來實現對 HTTP 通訊進行加密的目的。二者的關係為 HTTP+加密+認證+完整性保護=HTTPS 單純從層次上對比二者的差異為：

即在 HTTP 協議下又加了一層 SSL，計算機網路通訊過程的資訊流動方向是傳送方資訊由上到下進行包裝，然後接收方將資訊由下到上進行解包。上述的購物場景，如果使用了 SSL/TLS 承載 HTTP，那麼通訊的流程將會變化成如下圖：

無論是客戶端，還是服務端，訊息傳送的時候，都是從上往下，經過了 SSL/TLS 加密，然後接收的時候再由下往上解密。

看到這裡你可能對流程已經有所理解，但又存在疑惑： SSL/TLS 是什麼東西？

2.2 SSL/TLS

SSL（Secure Socket Layer），稱為安全套接層，是1994年網景公司設計的一種安全協議，用於解決了網路通訊安全和資料完整性問題。第一個版本的TLS（Transport Layer Security）是在 SSL3.0基礎上設計的，可以理解為 SSL 3.1。後續的 TLS 版本又加入了更多特性，可以把它理解為是 SSL 的升級版。

2.3 SSL/TLS 位於哪一層？

目前普遍的說法是 SSL/TLS 無法確切地被劃分到 OSI 或者 TCP/IP 的具體某一層。從邏輯上來講，SSL/TLS 的加密功能正好能和 OSI的表示層相對應，但是一些應用程式會把它當做傳輸層。所以比較保守的說法是SSL/TLS介於傳輸層和應用層之間。

2.4 TLS結構簡介

SSL/TLS 不僅可以承載 HTTP，也可以承載其他應用層協議。

協議本身可以分成兩層，上層是握手協議，下層是記錄協議。如下圖：

上層又分成了4個子協議，其中第一個握手協議是最重要的，它的作用是確認雙方使用的密碼套件，雙方共享金鑰，基於證書的認證操作。其他三個子協議的作用分別是：

密碼規則更變協議：通知對方要交換密碼了
警告協議：把錯誤資訊傳給對方
應用資料協議：將承載的資料傳達給對方

記錄協議位於下層，它的作用是使用對稱加密的方式對訊息進行加密通訊，過程可以再進一步細分為：

將訊息分割成多個片段，每個片段進行壓縮。
壓縮後的片段，加上訊息認證碼，用於保證完整性，並進行資料認證。訊息認證碼的金鑰在握手結束後可以生成，下面會介紹。
上面生成的東西，通過對稱加密，加密使用CBC模式，而CBC模式的初始化向量，以及對稱加密的金鑰，都可以在握手完成，通過主密碼生成，下面會介紹。
經過上面加密之後，再加上一個報頭，就是最後的報文資料了。這個報頭由資料型別，版本號，壓縮後的長度組成。其中資料型別是上層握手協議的4個子協議之一。

HTTPS握手過程

我們知道 HTTP 是基於 TCP 來完成的，TCP有握手過程，HTTPS同樣也有握手過程。當我們談論 HTTPS的時候，其實更側重的是談論 SSL。

預設情況下 HTTP 通訊，客戶端會開啟一條到伺服器埠80的連線。而 HTTPS 則會開啟一條到伺服器埠443的連線。 TCP 連線建立後，會初始化 SSL，溝通加密引數，交換金鑰，完成握手過程後，SSL 初始化完成。然後就可以加密通訊了。

我們在談論HTTPS握手過程，其實就是SSL的握手過程。這個握手過程分成4個部分。下面將詳細地解析這4個部分。

一：客戶端 -> 服務端

客戶端向服務端傳送Client Hello，告訴服務端它能理解的密碼套件（RSA/3DES等），壓縮方式，會話id,當前時間，SSL/TLS 協議的可用版本，客戶端隨機數。

二：服務端 -> 客戶端

服務端向客戶端傳送Server Hello。
服務端傳送Certificate，以及把證書清單發給客戶端,裡面包含了公開金鑰的證書。
Certificate不足以滿足需求的時候，還會傳送 ServerKeyExchange，告訴客戶端使用這些資訊來進行金鑰交換。
服務端向客戶端傳送CertificateRequest訊息，傳送了服務端能理解的證書型別清單和能理解的的認證機構名稱清單。
ServerHelloDone

三：客戶端 -> 服務端

如果收到 CertificateRequest，會向服務端傳送Certificate訊息，以及傳送自己的證書。
傳送 ClientKeyExchange以及經過加密的預備主密碼（隨機數）。這個報文是經過加密的，加密的公鑰就是服務端傳送Certificate時，發給客戶端的公鑰。
如果收到 CertificateRequest，還會傳送 certificateVerify訊息，告訴服務端它就時客戶端證書的持有者本人。
客戶端傳送changeCipherSpec訊息，告訴服務端要切換密碼了（實際上這個是密碼規則更變協議裡的東西）。服務端收到這個訊息後，雙方同時切換密碼
客戶端傳送 Finished （這時候客戶端使用已經切換後的密碼套件來傳送）

四：服務端 -> 客戶端

服務端傳送 changeCipherSpec，告訴客戶度要切換密碼了
服務端傳送 Finished 表示結束。然後就切換到了應用資料協議。之後雙方使用應用資料協議和TLS記錄協議來進行密碼通訊。

握手過程一共完成的工作有：

客戶端獲得服務端的合法公鑰（第二部分第二點），完成服務端認證。
服務端獲得客戶端的合法公鑰（第三部分第一點），完成客戶端認證。
雙端生成通訊中對稱加密的共享金鑰。
雙端生成訊息認證中的共享金鑰。

HTTPS 採用了混合加密機制。在握手環節使用公鑰加密方式。通訊建立後，交換報文時，使用共享金鑰加密，也就是上面第3和第4點。對稱加密會比非對稱加密快很多，提高通訊過程的效率。共享金鑰的生成過程，可以從這張圖中去理解。

客戶端和服務端可以擁有一樣的預備主密碼，在握手的開始階段，雙方協商了共同使用什麼密碼套件。預備主密碼同時使用由密碼套件中兩個單向雜湊函式（MD5和SHA-1）組合的偽隨機數生成器，生成主密碼（客戶端的預備主密碼也是使用偽隨機數生成）。兩端都會根據這個一樣的預備主密碼，計算出一樣的主密碼。然後再由一樣的主密碼，生成下面三個：