轉載 從Http到Https

標籤：

轉載自 http://www.cnblogs.com/silin6/p/5928503.html

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協議進行傳輸，只不過使用了 "會話密匙" 來加密內容。

見：

 

轉載 從Http到Https