http 超文本傳輸協議

存在問題：

1. 安全性、隱私性、數據完整性

2. 易被中間人（黑客之類的）對數據進行劫持、篡改、隱私泄露

引出了=====================================================================

https （source）

1. http 在網絡模型中的應用層
   Application => transport => internet => network Access
2. 所有經由網絡中的數據都是 以 最原始狀態傳輸的，一旦被截獲，內容會被輕易獲取

https中引入了 =====================================================================

TLS協議

的概念=====================================================================

1. 專門對數據進行加密解密操作
2. 客戶端產生數據后，會通過TLS進行數據加密，傳到對端，通過TLS對數據進行解密
3. 將解密后的 數據傳輸給http服務的

—網絡中 傳輸的 是加密后的數據

TLS 和 SSL 對比

1. TLS（transport layer security）：使用廣泛的網絡傳輸加密協議，規定了如何為在網絡中傳輸的數據進行加密和解密，確保數據安全性
2. SSL（Secure Socket Layer） ===> SSL.3.0版本 共享給IETF組織，最終重命名為TLS
3. SSL 為 TLS 前身

對稱加密

TLS 采用哪種方式對數據進行加密解密的

對稱加密

• 指通訊雙方更具協商好的算法，生成一個唯一密鑰
• 該密鑰用于同時對數據進行加解密操作

大致流程

1. 訪問某個服務時（已經三次握手了），會先向服務端發送個 hello請求，請求中包含了客戶端所支持的 TSL版本 和加密函數 和 加密算法等信息
2. 服務器接收請求，選取最優TSL協議、加密函數、加密算法，返回給客戶端
3. 客戶端接收到響應后，先隨機生成一段字符串（預主密鑰），通過使用加密的函數和算法生成一組密鑰（會話密鑰）
4. 同時客戶端把生成的 預主密鑰 發送給服務端，并且告知生成對稱密鑰的算法和信息。
5. 服務端通過使用客戶端發送過來的 加密的函數和算法生成一組密鑰（會話密鑰）

名詞

預主密鑰： 客戶端隨機生成的一段字符串

會話密鑰（對稱密鑰）： 預主密鑰 結合服務端返回的TLS協議、加密函數、加密算法 生成

問題

1. 無法保證 預主密鑰安全傳輸給服務端
2. 中間人也能拿到客戶端發送過來的 預主密鑰 和 TLS協議、加密算法、函數等信息，生成對應的 會話密鑰

怎么解決 預主密鑰安全傳輸===================================================

引入了=====================================================================

非對稱加密(PKI)

• 公鑰： 用于加密，對外開發，所有人都能獲取
• 私鑰： 用于解密，只有擁有者知道

public key infrastructure

示例

1. 客戶端 向服務傳輸數據時， 服務端首先會生成 公鑰私鑰對
2. 服務器將公鑰發送給客戶端，還有合適的TLS 協議， 加密算法等信息
3. 客戶端隨機生成一串字符串（預主密鑰），預主密鑰通過 加密算法生成 對應的 會話密鑰
4. 客戶端使用服務器發送的公鑰 對 預主密鑰進行加密。并且發送給服務端。還有 TLS 、加密算法等信息。
5. 服務端通過自己的私鑰對 加密過的預主密鑰進行解密。得到正確的預主密鑰，通過加密算法得到 會話密鑰。

問題

1. 無法保證客戶端獲取的公鑰真的是 目標服務提供的。
2. 客戶端獲取到公鑰真的是目標服務所頒發的嗎？

舉例

1. 服務器的公鑰、密鑰對被中間人截取。中間人提供自己的公鑰私鑰對給客戶端。客戶端不知道
2. 客戶端隨機生成 預主密鑰，使用 中間人提供的公鑰進行加密；使用中間人提供的加密算法生成 會話密鑰
3. 中間人拿到客戶端發來的加密后的預主密鑰，用自己的私鑰進行解密，拿到了正確的 預主密鑰。
4. 中間人用預主密鑰生成對應的會話密鑰（中間人和客戶端之間的）
5. 中間人用服務器的公鑰對 預主密鑰進行加密；用服務器提供的加密算法生成會話密鑰（中間人和服務器之間的）
6. 服務器拿到中間人提供的加密后的預主密鑰，用自己的私鑰進行解密拿到 預主密鑰；進行會話密鑰生成。
7. 這樣中間人就能對兩邊通訊內容繼續截取、監聽了

為解決這問題=================================================================
引入了=====================================================================

證書CSR

-Digital Certification 證書頒發機構（CA）所簽發

• 唯一，表示一個站點的身份信息；網站的身份證
• 證書：內容包含–證書的申請者、證書的頒發機構、證書的有效起始結束信息、證書的指紋（公鑰）

證書的申請流程

• 向CA機構進行申請，—簽發簽證。
  網站申請證書時

1. 申請者需要創建一個證書申請請求文件（SCR）Certificate Signing Request
2. 申請證書中通常要包含：網站域名、IP地址、公司名稱、地理位置、郵箱地址、公鑰信息等信息
3. 發送給 CA，ca對信息審核，審核完成后頒發給申請者，申請者把證書部署在web服務即可

證書的工作原理

1. 證書指紋：

1. 用戶唯一表示證書（確保證書的完整性）

• hash 加密： 單項加密算法

  • 特性：不可逆、唯一性

  生成證書時，會對證書的內容和公鑰分別進行hash計算，作為證書指紋附加到證書中，同時說明使用的hash算法

2. 瀏覽器從服務端獲取到證書后會使用相同的算法對證書進行hash 算法。將計算后的結果與附加在證書的中的指紋做對比
3. 如果一致，證明證書在網絡傳輸過程中沒有被人所截獲并篡改內容
4. 實現對證書正確性的核實（但無法保證證書是合法機構頒發的。也可能是一些偽造證書）

問題

1. 還需要核實證書的真實性，確定證書真是由證書中所描述的CA所頒發的，而不是偽造的。

通過證書簽名實現=====================================================================

2. 數字簽名（驗證證書的真實性）

• 通過 KPI（非對稱加密）來進行加密和解密進行驗證證書的真偽

• CA使用私鑰進行加密，公鑰進行解密

• CA生成好證書后，會對證書進行 私鑰加密，并附加到證書中發送給服務器

• 客戶端網站獲取到證書后。會使用 CA對應的公鑰 對其進行解密，一但解密成功。就代表 證書確實是CA機構頒發的

問題

瀏覽器CA的公鑰在那兒呢，怎么安全獲取CA公鑰呢，如何保證公鑰不被中間人替換

就要知道=============================================================

預安裝

1. 機構對證書進行簽名時，不僅用到私鑰，還會用到另外一個證書-根證書

   • 作用；為其他證書進行簽名，每個操作系統都會維護一個根證書庫：默認瀏覽器已經安裝好了受信人的CA根證書

2. 驗證證書中的數字簽名時，只要找到對應的CA根證書即可（避免網絡傳輸時被竊聽，掉包的風險）

=============

大概流程

1. 客戶端請求時（三次握手后），發送hello 請求，攜帶 支持的TLS、加密算法
2. 服務端響應 服務端采用的 TLS協議， 解密算法；同時發送 證書給客戶端
3. 客戶端驗證證書指紋、簽名確定證書的真實性。
4. 客戶端通過CA提供的公鑰從證書中提起出服務器的公鑰（保證公鑰一定是目標服務器的）
5. 客戶端生成預主密鑰，使用 公鑰進行加密，發送給服務器，攜帶加密算法等信息；預主密鑰使用加密算法生成 會話密鑰
6. 服務器使用自己的私鑰 對 加密的預主密鑰解密，拿到正確的預主密鑰；使用加密算法生成 對應的會話密鑰。
7. 開始真正傳輸數據，并且這些數據進行會話密鑰加密。

1-6之間的過程（不包括三次握手） 俗稱為 TLS握手。