這篇文章首發於我的個人網站：聽說 - https://tasaid.com/，建議在我的個人網站閱讀，擁有更好的閱讀體驗。
這篇文章與 博客園 和 Segmentfault 共享。
前端開發QQ群：377786580
HTTPS是互聯網 web 大勢所趨。各大網站都已陸續部署了HTTPS，這篇文章我們來探討什么是HTTPS以及為什么要部署HTTPS。
這篇文章收錄在《Said - 從HTTP到HTTPS》系列：
- 從 HTTP 到 HTTPS - 什么是 HTTPS
- 從 HTTP 到 HTTPS - IIS如何部署 HTTPS
- 從 HTTP 到 HTTPS - 網站部署 HTTPS 中需要做的事情
HTTP
當你在瀏覽器輸入一個網址 (例如 http://tasaid.com)的時候，瀏覽器發起一個 HTTP 請求，帶着請求信息 (參見 HTTP Headers)，連接到服務器，把請求信息遞給服務器，服務器收到信息之后，解析相關的信息，然后進行處理，再返回瀏覽器請求的數據。
簡單來說是這么一個流程：
- 小明 跟 瀏覽器爸爸 說我想要去中關村某個店家拿一些東西 (發起請求)
- 瀏覽器爸爸 就把 小明 要的東西記在一張清單上 (生成HTTP協議)
- 然后 瀏覽器爸爸 派出一個 線程小弟，噌噌噌跑到中關村的店里，把清單遞給 店家，說小明要這些東西 (進行傳輸)
- 店家 讓 線程小弟 稍等，然后去屋子里面拿小明的這些東西 (服務器收到請求)
- 店家 把東西拿出來后，並且也打印了一份清單，讓 線程小弟 帶着清單和東西一起拿回去 (服務器處理請求完畢)
- 然后 線程小弟 回到 瀏覽器爸爸 那邊，把服務器給的清單和物品交給瀏覽器爸爸，瀏覽器爸爸根據清單核對物品 (瀏覽器處理響應)
- 然后把物品打包交給了 小明 (瀏覽器渲染並呈現界面)
看圖說話：
這其中有個問題，瀏覽器爸爸和服務器都沒有驗證清單信息的有效性和對方的身份。萬一有人在中間把線程小哥攔下來，暴揍一頓，然后把物品清單給換了怎么辦？或者有人把線程小哥在半路上暴揍一頓，拿了清單換了另外一個小哥怎么辦？
這是個很嚴肅的問題：假如服務器要把一些東西鎖在櫃子里，需要小明給密碼才可以打開櫃子。然后小明把密碼寫在清單上讓瀏覽器爸爸交給服務器。這時候，如果這張清單被人攔截下來，不就得到了小明的密碼？
簡單來說，傳輸的信息中包含用戶密碼，被攔截了怎么辦？
HTTPS
正因為HTTP請求有這些安全性的問題，所以HTTPS誕生了，致力於解決了這些安全性問題，我們進行一下對比：
| 安全性 | HTTP | HTTPS |
|---|---|---|
| 竊聽風險 | 傳遞的信息是明文的，可能會被有心人攔截下來竊聽 | 信息加密傳播 |
| 篡改風險 | 傳遞的信息可能會被篡改 | 信息校驗，一旦被篡改立刻就會被發現 |
| 偽裝風險 | 沒有驗證通信另外一頭對方的身份，可能遭遇偽裝 | 身份校驗 |
那么HTTPS是如何做到更安全的呢？
簡單來說，HTTPS 即是在 HTTP 下加入了一層 SSL 加密，所以被稱為HTTPS。具體的加密過程則是 公匙加密法：
- 客戶端向服務器索要公匙，然后使用公匙加密信息
- 服務器收到加密后的信息，用自己的私匙解密
公匙密碼和算法都是公開的，而私匙則是保密的。加密使用的公匙和解碼使用的密匙都是不相同的，因此這是一個 非對稱加密 算法。
數字證書
提及 HTTPS ，就會聽到大家說需要證書才能部署，那么什么是證書呢？
因為互聯網不安全，公匙也是信息的一部分，也是會有被篡改的風險的。所以引入了互聯網權威機構 - CA 機構，又稱為證書授權 (Certificate Authority) 機構，瀏覽器會內置這些"受信任的根證書頒發機構" (即 CA)。
服務端向權威的身份鑒定 CA 機構申請數字證書，CA 機構驗證了網站之后，會把網站錄入到內部列表，采用 Hash 把服務端的一些相關信息生成摘要，然后 CA 機構用自己的私匙，把服務端的公匙和相關信息一起加密，然后給申請證書的服務端頒發數字證書，用於其他客戶端 (比如瀏覽器) 認證這個網站的公匙。
客戶端通過服務端下發的證書，找到對應的 CA，然后向 CA 驗證這個證書是否有效，CA 驗證通過之后，下發服務端的公匙。
因為 CA 是權威並且可信的，所以客戶端 (瀏覽器) 信任 CA，而 CA 又信任經過認證的服務端 ，所以客戶端 (瀏覽器) 也信任這個服務端，這就是信任鏈 (Chain Of Trust)。
而 CA 頒發的數字證書，一般包含這些信息：
簡單來說：為了保證公匙是安全的，所以通過數字證書驗證公匙。
加密通信
一條完整的HTTPS請求應該是這樣的：
- 客戶端 (瀏覽器) 發起 HTTP 請求，請求連接服務端，發送支持的加密通信協議 (和版本)，並且生成一個隨機數，后續用於生成"對話密鑰"。
- 服務端確認加密通信協議 (和版本)，同時也生成一個隨機數，后續用於生成"對話密匙"，並且將 CA 頒發的數字證書，一起發送給客戶端。
- 客戶端收到數字證書后，檢測內置的"受信任的根證書頒發機構"，查看解開數字證書的公匙是否在。
- 如果解開數字證書的公匙存在，則使用它解開數字證書，得到正確的服務器公匙，同時再次生成一個隨機數，用於服務器公匙加密，並發送給服務器。
- 此時本地和服務器同時將三個隨機數，根據約定的加密方法進行加密，各自生成本次會話的所使用的同一把 "會話密匙" 。
- 到這里，認證階段已經完畢，數據傳輸從 非對稱加密 換成了 對稱加密 (因為考慮到性能)，接下來所有的數據傳輸都是使用HTTP協議進行傳輸，只不過使用了 "會話密匙" 來加密內容。
見下圖：
參考和引用
這篇文章首發於我的個人網站：聽說 - https://tasaid.com/，建議在我的個人網站閱讀，擁有更好的閱讀體驗。
這篇文章與 博客園 和 Segmentfault 共享。
前端開發QQ群：377786580