圖解HTTP讀書筆記（七）
第七章 確定Web安全的HTTPS
HTTP的缺點
HTTP主要有這些不足，如：
1. 通信使用明文（不加密），内容可以會被竊聽
2. 不驗證通信方的身份，是以有可能遭遇僞裝
任何人都可以發起請求，隻要伺服器接收到請求，就會傳回響應。是以不确認通信方，存在隐患。
- 無法證明封包的完整性，是以有可能已遭篡改
伺服器或者用戶端2者接收到請求或響應有可能在傳輸的過程中被篡改。
中間人攻擊：請求或響應在傳輸途中，遭攻擊者攔截并篡改内容的攻擊成為中間人攻擊（Man-in-the-Middle attack,MITM）。
HTTP+加密+認證+完整性保護=HTTPS
HTTPS：在HTTP協定的基礎上，加上加密及認證機制。HTTPS并非是一種新協定，隻是HTTP通信接口部分用SSL(Secure Socket Layer)和TLS(Transport Layer Security)協定代替。
通常HTTP直接和TCP通信，現在使用HTTPS，中間隔了一層SSL。采用了SSL後，HTTP就擁有了HTTPS的加密、證書和完整性。
HTTPS的安全通信機制
為了更好的了解HTTPS，我們來觀察下HTTPS的通信步驟。
- 用戶端通過發送Client Hello封包開始SSL通信。封包中包含用戶端支援的SSL的指定版本、加密元件清單（所使用的加密算法及密鑰長度等）。
- 伺服器可進行SSL通信時，會以Server Hello封包作為響應，和用戶端一樣，在封包中包含SSL版本以及加密元件。伺服器的加密元件内容是從接收到用戶端加密元件内篩選出來的。
- 之後伺服器發送Certificate封包。封包中包含公開密鑰證書。
- 最後伺服器發送Server Hello Done封包通知用戶端，最初階段的SSL握手協商部分結束。
- SSL第一從握手結束後，用戶端以Client Key Exchange封包作為回應，封包中包含通信加密中使用的一種被稱為Pre-master secret的随機密碼串。該封包已用步驟3中的公鑰進行加密（完整性展現）。
- 接着用戶端繼續發送Change Cipher Spec封包。該封包會提示伺服器，在此封包之後的通信會采用Pre-master secret密鑰加密（加密展現）。
- 用戶端發送Finished封包。該封包包含連接配接至今全部封包的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正确解密該封包作為判定标準。
- 伺服器同樣發送Change Cipher Spec封包。
- 伺服器同樣發送Finished封包。
- 伺服器和用戶端的Finished封包交換完畢後，SSL連接配接就算建立完成。當然，通信會受到SSL的保護。從此處開始進行應用層協定的通信，即發送HTTP請求。
- 應用層協定通信，即發送HTTP響應。
- 最後由用戶端斷開連接配接。斷開連接配接時，發送close_notify封包。這步之後再發送TCP FIN封包來關閉與TCP的通信。
下面是對整個流程的圖解。圖中說明了從僅使用伺服器端的公開密鑰證書（伺服器證書）建立HTTPS通信的整個過程。