一、基礎概念

1.HTTP

HTTP (超文本傳輸協議) 是一種用于客戶端和服務器之間傳輸超媒體文檔的應用層協議，是萬維網的基礎。
簡而言之：一種獲取和發送信息的標準協議

2.SSL

安全套接字層（SSL）是一種通信協議或一組規則，用于在網絡上的兩個設備或應用程序之間創建安全連接。在通過互聯網共享憑證或數據之前，建立信任并對另一方進行身份驗證非常重要。SSL 是一種技術，您的應用程序或瀏覽器可能使用該技術在任何網絡上創建安全的加密通信通道。
簡而言之：一種用于進行身份驗證的通信協議

3.TLS

TLS 是 SSL 的直接后繼者，所有版本的 SSL 目前均已棄用。但是，使用術語 SSL 來描述 TLS 連接的情況很常見。在大多數情況下，術語 SSL 和 SSL/TLS 都是指 TLS 協議和 TLS 證書。
簡而言之：SSL的升級版

4.HTTPS

HTTPS 是在不安全的 HTTP 連接上建立安全 SSL/TLS 協議
簡而言之：HTTPS = HTTP + SSL/TLS

5.證書

• 域名證書：域名證書是針對域名注冊的擁有者而言的，它是以電子證書的格式來表現的，標明了注冊域名、域名所有人的中文和英文名稱、域名注冊時間和到期時間等這些內容。
• SSL證書：SSL證書是數字證書的一種，是遵守SSL協議的，由受信任的數字證書頒發機構（簡稱CA）在驗證服務器身份后頒發，具有服務器身份驗證和數據傳輸加密的功能。
  簡而言之：域名證書用于證明域名的歸屬權。SSL證書用于保護網站的數據傳輸安全。（域名證書是 SSL 證書的基礎）

二、思考

1.HTTP和HTTPS比較

1.1 HTTP在傳輸時候是明文傳輸，很容易被他人惡意攔截獲取篡改（中間人攻擊）

1.2 https則通過加密手段保證數據的安全。相應的因為在http基礎上每次傳輸都會涉及加密和解密，對應消耗的資源和時耗會增加。

1.3 如果確認服務所在的環境很安全（內網）或者涉及的都是非隱私性數據，則采用http會更好；如果涉及隱私數據則采用https會更好

2.HTTPS具體如何確保數據安全的

• 簡而言之就是使用SSL/TLS加密協議對HTTP通訊協議傳輸的內容進行加密/解密，即使中途傳輸內容被人截獲了，其獲得的也只是加密后的內容，保證了數據安全。
• 上面說了SSL，其實SSL就是TLS的前身，下文涉及這里的就統一就稱為TLS了。

2.1 TLS的對稱加密

• TLS的核心內容就是對稱加密。對稱加密就是客戶端跟服務端協商好一個對話密鑰（預主密鑰），每次發送/接收消息都用對話密鑰對內容進行加密/解密
  
  如圖，
  a.客戶端和服務端先進行一次會話（Client Hello,Server Hello），協商會話密鑰的生成算法和協議版本
  b.然后客戶側根據協商好的內容生成會話密鑰（預主密鑰）并發送給服務端【這一步注意存在隱患，后面會展開講】
  c.再之后客戶端和服務端就可以使用會話密鑰進行正常對稱加密交互了

2.2 TLS的非對稱加密

在上面講TLS的對稱加密流程中存在一個隱患點（流程b），就是客戶端在傳輸生成的會話密鑰（預主密鑰）時，如果這期間被黑客截獲，那他就也可以用會話密鑰對后序傳輸的所有內容進行加/解密，先前的所有操作都白搭了。
ps：這里可能會有人問既然a步驟時已經協商好了加密方法和版本，為啥雙方直接各自根據協商好的加密方法和版本直接都本地生成會話密鑰，就不需要再去傳輸會話密鑰了
首先，如果采取這種形式的話，那黑客直接就在最開始直接截取協商的加密算法和版本號就可以了，黑客也在本地生成對應的會話密鑰去加/解密后序的交互內容
其次，其實在Client Hello,生成密鑰的過程中客戶端會生成倆隨機數a、c，Server Hello過程中服務側會生成隨機數b，在生成會話密鑰時夾雜這三個隨機數進行生成。這樣即使黑客知道協商的加密算法和版本也無法計算出最終的會話密鑰
回歸正題，TLS這里就是通過非對成加密來優化傳輸會話密鑰中泄漏的風險

2.2.1非對稱加密

非對稱加密的核心內容就是使用公/私鑰，內容用公鑰加密，只有私鑰才能解密出來。私鑰自己保留，公鑰放開給任何人，別人用公鑰對內容加密，自己用私鑰進行解密。

2.2.2 非對成加密實際在TLS中的應用

a. 服務端在最開始協商版本和加密方法是把公鑰也發送給客戶端
b. 客戶生成會話密鑰后用公鑰再加密一道，然后發送給服務端
c. 服務端收到被公鑰加密過的會話密鑰，用私鑰進行解密獲取原始的會話密鑰
d. 后序客戶端跟服務端就可以用會話密鑰進行交互了
在這個過程中客戶端跟服務端并沒有傳輸過會話密鑰，所以即使黑客截獲到被會話密鑰加密的內容，也無法解密到真實數據

3.TLS過程存在的風險

上面講了TLS的對成加密+非對稱加密的全過程，但是這其中還是有一個風險點。公/私密鑰對任何人都可以創建，如果過程中黑客將傳輸的公鑰替換成自己創建的公鑰，那后序的操作也就都白費了

如圖，假設黑客從一開始就介入，類似中間商黃牛一樣。

• 面向客戶端裝成服務端，提供給服務端自己的公鑰y，用自己的私鑰y對客戶端發送來的“公鑰y加密過的會話密鑰”進行解密原始會話密鑰
• 面向服務端裝成客戶端，拿到服務端的公鑰x，將從客戶端解密到的“原始會話密鑰”用公鑰x進行加密再發送給服務端
• 這樣客戶端、黑客、服務端最終手上的會話密鑰就是一致的了，后序的交互過程就如下
  • 客戶端數據加密 -> 黑客解密拿到真實數據 -> 黑客使用會話密鑰對原始數據/篡改數據加密 -> 服務端解密到黑客發來的原始數據/篡改數據
  • 服務端數據加密 -> 黑客解密拿到真實數據 -> 黑客使用會話密鑰對原始數據/篡改數據加密 -> 客戶端解密到黑客發來的原始數據/篡改數據

4.優化TLS過程中的風險–證書

簡而言之，為了優化上面的風險，服務端不要直接傳輸公鑰給客戶端。而是替換為有公證力的證書傳輸給服務端。服務端可以根據證書解析拿到公鑰，同時證書也能證明該公鑰是沒有被人掉包/篡改過的

4.1 證書介紹

證書包含如下內容

• Issued To：證書的申請者，即服務側申請證書時登記自己的身份信息
• Issued By：證書的頒發者，有公證力的組織
• Validity Period：證書的有效期信息
• SHA-256 Fingerprints：證書的指紋信息和登記的公鑰
  • 指紋碼：證書的唯一標識（保證證書的完整性）。被Hash加密過
    
    服務側拿到證書需要確保兩個事情才能信任證書
    1.證書的完整性：證書在傳輸過程中是否被人截獲修改篡改過？比如證書被黑客攔截，對里面的內容進行了修改（數據篡改）
    2.證書的可信性：證書雖然是完整的，但不知道這個證書是否為客戶端發送的被公證過滴證書？比如真正的證書a被黑客攔截，黑客再給服務端換成自己生成的證書b發送過去（證書調包）
    這兩種情況分別需要使用證書指紋、數字簽名來驗證

4.2 證書指紋

指紋碼：證書的唯一標識（保證證書的完整性）。被Hash加密過

• hash加密不可逆且具有唯一性，即無法根據加密后的內容反解析出初始內容，不同的初始內容加密后不可能得到相同的加密串。那么服務側對原始內容hash后進行比對，如果不一致則代表當前證書中途被人篡改過內容

4.3 數字簽名

用于驗證證書身份的真實性

• 我們之前都是對內容公鑰加密，私鑰解密。數字簽名這里相反，會把內容進行私鑰加密，公鑰解密
• 權威機構CA頒發證書時候，會用私鑰對證書加密，然后頒發出去。服務端拿到加密證書后，再用公鑰解密證書，獲取證書信息。如果解密成功，說明手上的公鑰和證書加密使用的私鑰為一對，即說明該加密證書確實為權威機構所頒發的那個證書
• 電腦一般安裝的系統/瀏覽器內都自帶有由權威機構頒發的證書驗證公鑰，即不需要從網絡上傳遞公鑰，也就不存在證書公鑰被泄漏的風險
  ps：思考題：全網那么多域名需要申請證書，又有那么多權威CA機構。總不能在系統和瀏覽器里都預裝所有證書驗證公鑰吧？
  a.CA機構也是分級的，瀏覽器和系統只需要預裝根CA機構的公鑰；
  b.用根CA公鑰解密中間CA的【A類證書】（這里的證書指的是 根CA 頒發給 中間CA 驗證 中間CA機構權威性 的證書）；
  c.然后從A類證書里拿到下一級證書的公鑰（這里的下一級如果是更次級的中間CA，則類推繼續到下一級，直到拿到驗證服務端域名的【B類證書】），
  

4.4 TLS完整過程

ps：學習參考（bilibili：Zzlock、技術蛋老師）