從 HTTP 到 HTTPS - 什麼是 HTTPS

這篇文章首發於個人我的網站：據說 - 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)，鏈接到服務器，把請求信息遞給服務器，服務器收到信息以後，解析相關的信息，而後進行處理，再返回瀏覽器請求的數據。

簡單來講是這麼一個流程：

1. 小明 跟 瀏覽器爸爸 說我想要去中關村某個店家拿一些東西 (發起請求)

2. 瀏覽器爸爸 就把 小明 要的東西記在一張清單上 (生成HTTP協議)

3. 而後 瀏覽器爸爸 派出一個 線程小弟，噌噌噌跑到中關村的店裏，把清單遞給 店家，說小明要這些東西 (進行傳輸)

4. 店家 讓 線程小弟 稍等，而後去屋子裏面拿小明的這些東西 (服務器收到請求)

5. 店家 把東西拿出來後，而且也打印了一份清單，讓 線程小弟 帶着清單和東西一塊兒拿回去 (服務器處理請求完畢)

6. 而後 線程小弟 回到 瀏覽器爸爸 那邊，把服務器給的清單和物品交給瀏覽器爸爸，瀏覽器爸爸根據清單核對物品 (瀏覽器處理響應)

7. 而後把物品打包交給了 小明 (瀏覽器渲染並呈現界面)

看圖說話：

這其中有個問題，瀏覽器爸爸和服務器都沒有驗證清單信息的有效性和對方的身份。萬一有人在中間把線程小哥攔下來，暴揍一頓，而後把物品清單給換了怎麼辦？或者有人把線程小哥在半路上暴揍一頓，拿了清單換了另一個小哥怎麼辦？

這是個很嚴肅的問題：假如服務器要把一些東西鎖在櫃子裏，須要小明給密碼才能夠打開櫃子。而後小明把密碼寫在清單上讓瀏覽器爸爸交給服務器。這時候，若是這張清單被人攔截下來，不就獲得了小明的密碼？

簡單來講，傳輸的信息中包含用戶密碼，被攔截了怎麼辦？

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請求應該是這樣的：

1. 客戶端 (瀏覽器) 發起 HTTP 請求，請求鏈接服務端，發送支持的加密通訊協議 (和版本)，而且生成一個隨機數，後續用於生成"對話密鑰"。

2. 服務端確認加密通訊協議 (和版本)，同時也生成一個隨機數，後續用於生成"對話密匙"，而且將 CA 頒發的數字證書，一塊兒發送給客戶端。

3. 客戶端收到數字證書後，檢測內置的"受信任的根證書頒發機構"，查看解開數字證書的公匙是否在。

4. 若是解開數字證書的公匙存在，則使用它解開數字證書，獲得正確的服務器公匙，同時再次生成一個隨機數，用於服務器公匙加密，併發送給服務器。

5. 此時本地和服務器同時將三個隨機數，根據約定的加密方法進行加密，各自生成本次會話的所使用的同一把 "會話密匙" 。

6. 到這裏，認證階段已經完畢，數據傳輸從 非對稱加密 換成了 對稱加密 (由於考慮到性能)，接下來全部的數據傳輸都是使用HTTP協議進行傳輸，只不過使用了 "會話密匙" 來加密內容。

見下圖：

參考和引用

• HTTPS 工做原理

• 阮一峯 - 數字簽名是什麼

• 阮一峯 - SSL/TLS協議運行機制的概述

這篇文章首發於個人我的網站：據說 - https://tasaid.com/，建議在個人我的網站閱讀，擁有更好的閱讀體驗。

這篇文章與 博客園 和 Segmentfault 共享。

前端開發QQ羣：377786580