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