第七章 確保Web安全的HTTPS
7.1 HTTP的缺點
主要分爲三種不足：
- 通信使用明文，內容可能會被竊聽
- 不驗證通信方的身份，因此有可能遭遇僞裝
- 無法證明報文的完整性，所以有可能已遭篡改
7.2 HTTPS
HTTP並非是應用層的一種新協議。只是HTTP通信接口部分用SSL和TLS協議替換。HTTPS採用混合加密機制：
1. 使用公開密匙加密方式安全的交換稍後的共享密匙加密中要使用的密匙。
2. 確保交換的密匙是安全的前提下，使用共享密匙加密方式進行通信。
HTTP+加密+認證+完整性保護=HTTPS
基本過程：
1. 服務器把自己的公開密鑰登錄至數字證書認證機構
2. 數字證書認證機構用自己的私有祕鑰向服務器的公開密碼部署數字簽名並頒發證書。
3. 客戶端拿到服務器的公鑰證書後，使用數字證書認證機構的公開密鑰，向數字證書認證機構驗證公鑰證書上的數字簽名，已確認服務器的公開密鑰的真實性。
4. 使用服務器的公開密鑰對報文加密後發送。
5. 服務器用私有祕鑰對報文進行解密。
HTTPS的安全通信機制
步驟1：客戶端發送Client Hello報文開始SSL通信。報文中包含客戶端支持的SSL的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
步驟2：服務端可進行SSL通信時，會以Server Hello報文作爲應答。和客戶端一樣，在報文中包含SSL版本以及加密組件。服務器的加密組件內容是從接受到客戶端加密組件中篩選出來的。
步驟3：之後服務器發送Certifacate報文，報文中包含公開密鑰證書。
步驟4：最後服務器發送Server Hello Done 報文通知客戶端，最初階段的SSL握手協商部分結束。
步驟5：SSL第一次握手結束之後，客戶端以Client Key Exchange報文作爲迴應。報文中包含通信加密中使用的一種被稱爲Pre-master secret 的隨機密碼串。該報文已用步驟3中的公開密鑰進行加密。
步驟6：接着客戶端繼續發送Change Cipher Spec 報文。該報文會提示服務器，在此報文之後的通信會採用Pre-master secret 密鑰加密。
步驟7：客戶端發送Finished 報文。該報文包含連接至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以服務器是否能夠正確解密該報文作爲判定標準。
步驟8：服務器同樣發送Change Cipher Spec 報文。
步驟9：服務器同樣發送Finished報文。
步驟10：服務器和客戶端的Finished 報文交換完畢之後，SSL連接就算建立完成。當然，通信會受到SSL 的保護。從此開始進行應用層協議的通信，及發送HTTP請求。
步驟11：應用層協議通信，即發送HTTP響應。
步驟12：最後由客戶端斷開連接。斷開連接時，上圖做了一些省略，這步之後在發送TCP FIN報文來關閉與TCP的通信。