更安全的Web通訊HTTPS

1. HTTP協議存在的問題

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

在網購過程當中，若是使用純粹的HTTP協議，那麼用戶的帳號密碼，信用卡，銀行卡信息都將在信息傳輸過程當中直接裸奔。從例子中咱們能夠看到信用卡信息直接被明文傳輸了。除了明文傳輸以外，還存在着如下兩個問題:

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

常規狀況下，能夠對通訊的內容進行加密，來避免明文傳輸的問題。可是單靠這點，沒法解決信息完整性和認證問題。爲了解決這些問題，須要對通訊進行加密。也就引入了 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個子協議，其中第一個握手協議是最重要的，它的做用是確認雙方使用的密碼套件，雙方共享密鑰，基於證書的認證操做。 其餘三個子協議的做用分別是：

• 密碼規則更變協議：通知對方要交換密碼了
• 警告協議：把錯誤信息傳給對方
• 應用數據協議：將承載的數據傳達給對方

記錄協議位於下層，它的做用是使用對稱加密的方式對消息進行加密通訊，過程能夠再進一步細分爲：

1. 將消息分割成多個片斷，每一個片斷進行壓縮。
2. 壓縮後的片斷，加上消息認證碼，用於保證完整性，並進行數據認證。消息認證碼的密鑰在握手結束後能夠生成，下面會介紹。
3. 上面生成的東西，經過對稱加密，加密使用CBC模式，而CBC模式的初始化向量，以及對稱加密的密鑰，均可以在握手完成，經過主密碼生成，下面會介紹。
4. 通過上面加密以後，再加上一個報頭，就是最後的報文數據了。這個報頭由數據類型，版本號，壓縮後的長度組成。其中數據類型是上層握手協議的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 協議的可用版本，客戶端隨機數。

二： 服務端 -> 客戶端

1. 服務端向客戶端發送Server Hello。
2. 服務端發送Certificate，以及把證書清單發給客戶端,裏面包含了公開密鑰的證書。
3. Certificate不足以知足需求的時候，還會發送 ServerKeyExchange，告訴客戶端使用這些信息來進行密鑰交換。
4. 服務端向客戶端發送CertificateRequest消息，發送了服務端能理解的證書類型清單和能理解的的認證機構名稱清單。
5. ServerHelloDone

三： 客戶端 -> 服務端

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

四： 服務端 -> 客戶端

1. 服務端發送 changeCipherSpec，告訴客戶度要切換密碼了
2. 服務端發送 Finished 表示結束。 而後就切換到了應用數據協議。以後雙方使用應用數據協議和TLS記錄協議來進行密碼通訊。

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

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

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

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

• 用於對稱加密的密鑰
• 消息認證碼的密鑰
• 對稱密碼的CBC模式中使用的初始化向量

每同樣都有兩份，即客戶端發往服務端，和服務端發往客戶端。因此主密碼一共能夠生成6種信息。

以上就是HTTPS握手過程的詳細解析。握手創建完成後，客戶端和服務端有擁有對稱加密的密鑰，那麼就可使用這個密鑰對通訊內容進行加密了。

HTTPS相對於HTTP有什麼不同？

總結一下，HTTPS多作了什麼，它和HTTP有什麼不同。

• HTTP是明文傳輸，HTTPS是加密傳輸
• HTTPS須要申請證書，有必定成本
• HTTP使用80端口，HTTPS使用443端口
• HTTP沒有身份認證，HTTPS有身份認證
• HTTP報文完整性沒法驗證，可能被篡改。HTTPS能夠驗證。

參考資料

圖解密碼技術

圖解HTTP

HTTP權威指南

Transport Layer Security