計算機網路——深入理解HTTP以及HTTPs

首先明確一點，https的出現就是為了解決http明文傳輸資料不安全性的問題。如果要真正做到在網路通訊中資料安全傳輸，首先要解決的三大問題：資料的機密性、資料的有效性、資料的完整性和一致性
對於資料機密性：https(ssl/tls)透過非對稱金鑰交換金鑰，對稱加密傳輸資料保證
對於資料有效性：https(ssl/tls)透過簽名和認證保證
對於資料完整性和一致性：https(ssl/tls)透過訊息摘要演算法（單向雜湊演算法）保證

2.1 HTTPS簡介

https並不是一種全新的協議，它實際上是http協議和ssl（TLS）協議的組合，即建立在ssl（Secure Socket Layer）上的安全協議，即安全性透過SSL協議實現。

2.2 SSL簡介

SSL是一種位於應用層和傳輸層之間，可以為任何基於TCP等可靠連線的應用層協議提供安全性保證的協議 SSL利用身份驗證，資料加密和訊息完整性驗證機制，為網路上資料的傳輸提供安全性保證。SSL目前有三個版本，SSL1.0、SSL2.0、SSL3.0。它已被廣泛地用於Web瀏覽器與伺服器之間的身份認證和加密資料傳輸。SSL支援各種應用層協議。

SSL協議可分為兩層： SSL記錄協議（SSL Record Protocol）：它建立在可靠的傳輸協議（如TCP）之上，為高層協議提供資料封裝、壓縮、加密等基本功能的支援。 SSL握手協議（SSL Handshake Protocol）：它建立在SSL記錄協議之上，用於在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密金鑰等。

TLS（Transport Layer Security）是SSL的繼任者，是SSL 3.0的後續版本，該協議也由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。

下圖可以看出SSL/TLS與傳輸層和應用層之間的關係，即位於OSI七層網路模型中的會話層：

2.3 SSL安全機制

• 身份驗證機制
  基於證照利用數字簽名方法對伺服器和客戶端進行身份驗證，其中客戶端的身份驗證是可選的。
• 資料傳輸的機密性
  利用對稱金鑰演算法對傳輸的資料進行加密。
• 訊息完整性驗證
  訊息傳輸過程中使用MAC演算法來檢驗訊息的完整性。

2.4 SSL握手階段

SSL透過握手過程交換資料傳輸過程中加密用的金鑰，建立起安全的連結。注意以下幾點

• 由於非對稱加密的速度比較慢，所以它一般用於金鑰交換，雙方透過公鑰演算法協商出一份金鑰，然後透過對稱加密來通訊，當然，為了保證資料的完整性，在加密前要先經過HMAC的處理。
• 握手階段是發生在TCP建連之後開始進行的，握手其實就是在協商，協商加解密協議所需要的一些引數資訊等內容。
• 握手過程有單向驗證和雙向驗證之分，簡單解釋一下，單向驗證就是server端將證照傳送給客戶端，客戶端驗證server端證照的合法性等，例如百度、新浪、google等普通的https網站，雙向驗證則是不僅客戶端會驗證server端的合法性，同時server端也會驗證客戶端的合法性，例如銀行網銀登陸，支付寶登陸交易等。

SSL預設只進行server端的認證，客戶端的認證是可選的。以下是其流程圖：

解釋一下上圖發生的主要四次通訊過程：

1. 客戶端發出請求

    - 支援的協議版本號（SSL Version），比如TLS 1.0版。
    - 一個客戶端生成的隨機數（Client Random1），稍後用於生成"對話金鑰"。
    - 客戶端支援的加密套件（Support Ciphers）比如：RSA公鑰加密演算法、DH加密演算法。

2. 伺服器回應（Sever Hello、Certificate、Server Key Exchange、Server Hello Done）
   上圖中，從Server Hello到Server Done，有些服務端的實現是每條單獨傳送，有服務端實現是合併到一起傳送。Sever Hello和Server Done都是隻有頭沒有內容的資料。主要傳送以下內容：

    - 確認使用的加密通訊協議版本，比如TLS1.0版本。如果瀏覽器與伺服器支援版本不一致，伺服器關閉加密通訊。
    - 一個伺服器生成的隨機數（Sever Random），稍後用於生成"對話金鑰"。
    - 確認使用的加密方法，比如RSA公鑰加密。
    - 伺服器證照（Certificate）。

   ps1：此為單向驗證，若是雙向驗證，需要在Sever Hello Done之前傳送Certificate Request，表示需要客戶端提供證照，內容為：客戶端應當提供的證照型別和服務端可以接受的證照列表

此時上面這兩步都還是明文傳輸！！！

3. 客戶端回應（Client Key Exchange、 Change Chiper Spec、Encrypted Handshake Message）
   ps1:如果服務端需要對客戶端進行驗證，在客戶端收到服務端的 Server Hello 訊息之後，首先需要向服務端傳送客戶端的證照，讓服務端來驗證客戶端的合法性。

    - 一個隨機數（Pre Master Secret）。客戶端將透過約定演算法生成一個48位元組的premaster secret，即預主金鑰，這個金鑰中包含了客戶端tls的版本號資訊和一個隨機數，如果有中間人共計，有意降低TLS版本的話，則會馬上終止傳送資料。即協議版本設計來抵禦rollback attacks（反轉攻擊）。該隨機數用伺服器公鑰加密，防止被竊聽。
    - 編碼改變通知（Change Chiper Spec），表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送。
    - 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面傳送的所有內容的hash值，用來供伺服器校驗。

至於為什麼一定要用三個隨機數，來生成”會話金鑰”，dog250解釋得很好：
“不管是客戶端還是伺服器，都需要隨機數，這樣生成的金鑰才不會每次都一樣。由於TLS協議中證照是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的金鑰的隨機性。
對於RSA金鑰交換演算法來說，pre-master-key本身就是一個隨機數，再加上hello訊息中的隨機，三個隨機數透過一個金鑰匯出器最終匯出一個對稱金鑰。
pre master的存在在於SSL協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那麼pre master secret就有可能被猜出來，那麼僅適用pre master secret作為金鑰就不合適了，因此必須引入新的隨機因素，那麼客戶端和伺服器加上pre master secret三個隨機數一同生成的金鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。”

4. 伺服器最後回應（New Session Ticket, Change Chiper Spec, Encrypted Handshake Message）

new session ticket
該資料包主要是server端向客戶端傳送新的session ticket，因為最開始並沒有這個資訊，並通知客戶端開始使用加密方式傳輸資料。該session ticket就相當於普通網站中的session，當瀏覽器在次傳送請求或者中間網路原因連線被斷開之後，client hello階段攜帶該session id，則認為是同一個人訪問，不在進行證照互動階段，該session id的複用也是最佳化的一點。傳送的內容如下

- 服務端傳輸改變通知（Change Chiper Spec）
- 服務端第一個加密報文（Encrypted Handshake Message）用以做出對之前握手過程的簡單驗證！

---

簡單總結以上過程：
客戶端和服務端建立 SSL 握手：客戶端透過 CA 證照來確認服務端的身份；互相傳遞三個隨機數，之後透過這隨機數來生成一個金鑰；互相確認金鑰，然後握手結束；資料通訊開始，都使用同一個對話金鑰來加解密；
我們可以發現，在 HTTPS 加密原理的過程中把對稱加密和非對稱加密都利用了起來。即利用了非對稱加密安全性高的特點，又利用了對稱加密速度快，效率高的好處。

---

2.5 延申：什麼是ＣＡ？以及在整個握手過程中的作用

  認證機構CA（Certificate Authority）在https中是一個很重要的角色，CA是PKI的核心執行機構，是PKI（Public key Infrastructure  公鑰基礎設施）的主要組成部分，通常稱之為認證中心，從廣義上講，認證中心還應該包括證照申請序號產生器構RA（Registration Authority），它是數字證照的申請註冊、證照籤發的管理機構。客戶端是怎麼驗證該證照的頒發機構即CA中心是合法有效的呢，其實在系統瀏覽器中有預埋CA中心的根證照，在其中的根證照為可信任機構.

證照生成過程

1. 認證機構會生成一對秘鑰, 公鑰和私鑰
2. 然後生成伺服器（請求者）的數字簽名：

• 伺服器公鑰 經過數字摘要演算法 生成數字指紋
• 把生成的數字指紋 在用認證機構的私鑰加密 生成數字簽名

3. 最後用私鑰整體加密生成公鑰證照，主要包含兩部分內容：數字簽名和伺服器公鑰

客戶端校驗 CA 證照的步驟

伺服器將公鑰證照傳送給客戶端， 客戶端驗證公鑰證照從而確保公鑰的合法性。

1、客戶端取出提前內建在手機內部的認證機構的公鑰
2、用認證機構的公鑰去解密公鑰證照裡的數字簽名 從而得到數字指紋
3、客戶端對公鑰證照的伺服器公鑰進行數字摘要演算法 從而生成數字指紋
4、對比客戶端自己生成的數字指紋(第3步)和解密得到的數字指紋(第2步)是否一致 如果一致則公鑰證照驗證透過，服務端是可以被信任的；如果不相等，那麼就說明該證照是錯誤的，可能被篡改了，瀏覽器會給出相關提示，無法建立起 HTTPS 連線。除此之外，還會校驗 CA 證照的有效時間和域名匹配等。

---

2.6 加密套件和協議版本

在強化基於SSL/TLS的服務時，兩個配置引數至關重要：允許的SSL/TLS版本和允許的密碼套件。應根據最佳實踐設定這些引數，但這些引數並不總是很清楚; 此外，在不斷髮展的安全世界中，昨天解決一個安全問題的最佳建議可能成為當今易受攻擊的配置。

協議版本
庫程式碼中廣泛支援五種版本的SSL/TLS：SSL 2.0，SSL 3.0，TLS 1.0，TLS 1.1和TLS 1.2。

加密套件

• 金鑰交換演算法
• 資料加密演算法
• 訊息驗證演算法（MAC:Message Authentication Code）。

金鑰交換演算法用於握手過程中建立通道，一般採用非對稱加密演算法。

資料加密演算法用於通道建立之後的加密傳輸資料，一般採用對稱加密演算法。

訊息驗證演算法是一種雜湊，用於驗證訊息的完整性，包括整個握手流程的完整性（例如TLS握手的最後一步就是一個對已有的握手訊息的全盤雜湊計算的過程）。

如何選擇各個演算法呢？
優先選擇ECC證照和ECDHE握手的方式，如果客戶端不支援或者只有RSA證照，就會選擇RSA證照和ECDHE金鑰交換演算法，而一直沒有選擇RSA的金鑰交換演算法。只有在ECDHE金鑰交換演算法完全不支援之後才會去可能使用RSA來進行金鑰交換
(RSA金鑰交換、DH以及DHE金鑰交換演算法在實際的應用相對在減少。ECDHE逐漸成為主流。)
關於選擇ECDHE加密演算法主要基於前向安全性 —— 即對歷史通訊的安全！

本作品採用《CC 協議》，轉載必須註明作者和本文連結