一，概念鋪墊

HTTPS也是?個應?層協議，是在HTTP協議的基礎上引?了?個加密層，HTTP協議內容都是按照?本的?式明?傳輸的，這就導致在傳輸過程中出現?些被篡改的情況。所以HTTPS就要對正文部分做加密

---

1.1 什么是加密？

• 加密就是把 明?(要傳輸的信息) 進??系列變換，?成 密?
• 解密就是把 密? 再進??系列變換，還原成 明?

在這個加密和解密的過程中，往往需要?個或者多個中間的數據，輔助進?這個過程，這樣的數據稱為密鑰

---

1.2 為什么要加密？

我們以運營商劫持的例子來說，當我們要從網上下載一個“天天動聽”

未被劫持時，我們的下載鏈接都是正常的：

已被劫持時，點擊下載按鈕，就會彈出QQ瀏覽器的下載鏈接而不是原來的鏈接

由于我們通過?絡傳輸的任何的數據包都會經過運營商的?絡設備(路由器，交換機等)，那么運營商的?絡設備就可以解析出你傳輸的數據內容，并進?篡改。點擊"下載按鈕"，其實就是在給服務器發送了?個HTTP請求，獲取到的HTTP響應其實就包含了該APP的下載鏈接。運營商劫持之后，就發現這個請求是要下載天天動聽，那么就?動的把交給?戶的響應給篡改成"QQ瀏覽器"的下載地址了。

這是因為http的內容是明?傳輸的，明?數據會經過 路由器、wifi熱點、通信服務運營商、代理服務器 等多個物理節點，如果信息在傳輸過程中被劫持，傳輸的內容就完全暴露了。劫持者還可以篡改傳輸的信息且不被雙?察覺，這就是 中間?攻擊 ，所以我們才需要對信息進?加密

---

1.3 加密的方式

常?的加密?式有兩種：

• 對稱加密：采?單鑰密碼系統的加密?法，同?個密鑰可以同時?作信息的加密和解密
  • 特點是：算法公開、計算量?、加密速度快、加密效率?
  • 常?對稱加密算法：DES、3DES、AES、TDEA、Blowfish、RC2等
• 非對稱加密：需要兩個密鑰來進?加密和解密，這兩個密鑰是公開密鑰（public key，簡稱公鑰，可以在網絡中傳送）和私有密鑰（private key，簡稱私鑰，不可以在網絡中傳送）
  • 如果通過公鑰對明文加密變成密文，則通過私鑰對密文解密變為明文，反之相反
  • 公鑰和私鑰是配對的，最?的缺點就是運算速度?常慢，?對稱加密要慢很多
  • 常??對稱加密算法：RSA，DSA，ECDSA

---

1.4 數據摘要&數據指紋

數字指紋(數據摘要),其基本原理是利? 單向散列函數(Hash函數) 對信息進?運算，?成?串固定?度的數字摘要。數字指紋并不是?種加密機制，因為不可以解密，但可以?來判斷數據有沒有被竄改

這里舉兩個使用場景：
1.mysql數據庫登錄的例子

2. 百度網盤秒傳的例子
我們都會向百度網盤上傳電影，那么這個電影可能有很多人上傳，但是百度網盤不會將這個電影存很多份，而是存一份，其他的形成鏈接文件

所以數據指紋的作用有兩個：

• 用來比對兩個文件是否相同
• 比對一個是否被篡改

二，認識https

在說明https之前，我們這里可以探討以下https是如何一步步成熟的

2.1 方案1-只使用對稱加密

如果通信雙?都各?持有同?個密鑰X，且沒有別?知道，這兩?的通信安全當然是可以被保證的（除?密鑰被破解）

但是這個方案有一個問題，服務器同?時刻其實是給很多客?端提供服務的，這么多客?端，每個??的秘鑰都必須是不同的(如果是相同那密鑰就太容易擴散了，?客就也能拿到了)。因此服務器就需要維護每個客?端和每個密鑰之間的關聯關系，這顯然不現實。

?較理想的做法，就是能在客?端和服務器建?連接的時候，雙?協商確定這次的密鑰是啥。

但是如果直接把密鑰明?傳輸，那么?客也就能獲得密鑰了，因此密鑰的傳輸也必須加密傳輸。但是要想對密鑰進?對稱加密，就仍然需要先協商確定?個"密鑰的密鑰"，這就成了"先有雞還是先有蛋"的問題了。此時密鑰的傳輸再?對稱加密就?不通了

2.2 方案2-只使用非對稱加密

鑒于?對稱加密的機制，如果服務器先把公鑰以明??式傳輸給瀏覽器，之后瀏覽器向服務器傳數據前都先?這個公鑰加密好再傳，從客?端到服務器信道似乎是安全的(有安全問題)，因為只有服務器有相應的私鑰能解開公鑰加密的數據，但是服務器到瀏覽器的這條路怎么保障安全？

如果服務器?它的私鑰加密數據傳給瀏覽器，那么瀏覽器?公鑰可以解密它，?這個公鑰是?開始通過明?傳輸給瀏覽器的，若這個公鑰被中間?劫持到了，那他也能?該公鑰解密服務器傳來的信息了

2.3 方案3-雙方都使用非對稱加密

服務端擁有公鑰S與對應的私鑰S’，客?端擁有公鑰C與對應的私鑰C’，客?和服務端交換公鑰。
客?端給服務端發信息：先?S對數據加密，再發送，只能由服務器解密，因為只有服務器有私鑰S’。
服務端給客?端發信息：先?C對數據加密，在發送，只能由客?端解密，因為只有客?端有私鑰C’

但是這樣會有兩個問題：

• 效率太低，非對稱加密本來效率就低
• 依舊有安全問題

2.4 方案4-非對稱加密+對稱加密

服務端具有?對稱公鑰S和私鑰S’，客?端發起https請求，獲取服務端公鑰S
? 客?端在本地?成對稱密鑰C，通過公鑰S加密，發送給服務器
? 由于中間的?絡設備沒有私鑰，即使截獲了數據，也?法還原出內部的原?，也就?法獲取到對稱密鑰
? 服務器通過私鑰S’解密，還原出客?端發送的對稱密鑰C。并且使?這個對稱密鑰加密給客?端返回的響應數據
? 后續客?端和服務器的通信都只?對稱加密即可，由于該密鑰只有客?端和服務器兩個主機知道，其他主機/設備不知道密鑰即使截獲數據也沒有意義

雖然上?已經?較接近答案了，但是依舊有安全問題
如果最開始，中間?就已經開始攻擊了呢？

---

中間人攻擊
但是中間?的攻擊，如果在最開始握?協商的時候就進?了，那就不?定了，假設hacker已經成功成
為中間?

1. 服務器具有?對稱加密算法的公鑰S，私鑰S’
2. 中間?具有?對稱加密算法的公鑰M，私鑰M’
3. 客?端向服務器發起請求，服務器明?傳送公鑰S給客?端
4. 中間?劫持數據報?，提取公鑰S并保存好，然后將被劫持報?中的公鑰S替換成為??的公鑰M，并將偽造報?發給客?端
5. 客?端收到報?，提取公鑰M(??當然不知道公鑰被更換過了)，??形成對稱秘鑰X，?公鑰M加密X，形成報?發送給服務器
6. 中間?劫持后，直接???的私鑰M’進?解密，得到通信秘鑰X，再?曾經保存的服務端公鑰S加密后，將報?推送給服務器
7. 服務器拿到報?，???的私鑰S’解密，得到通信秘鑰X
8. 雙?開始采?X進?對稱加密，進?通信。但是?切都在中間?的掌握中，劫持數據，進?竊聽甚?修改，都是可以的
   上?的攻擊?案，同樣適?于?案2，?案3
   問題本質出在哪?了呢？客?端?法確定收到的含有公鑰的數據報?是否是?標服務器發送過來的
   

---

引入證書

為了解決上面的問題，就有了證書，服務端在使?HTTPS前，需要向CA機構申領?份數字證書，數字證書?含有證書申請者信息、公鑰信息等。服務器把證書傳輸給瀏覽器，瀏覽器從證書?獲取公鑰就?了，證書就如?份證，證明服務端公鑰的權威性

這個證書可以理解成是?個結構化的字符串，??包含了以下信息：
? 證書發布機構
? 證書有效期
? 公鑰
? 證書所有者
? 簽名
? …
需要注意的是：申請證書的時候，需要在特定平臺?成查，服務端會同時?成?對?密鑰對?，即公鑰和私鑰。這對密鑰對?就是?來在?絡通信中進?明?加密以及數字簽名的。其中公鑰會隨著CSR?件，?起發給CA進?權威認證，私鑰服務端自己保留，?來后續進?通信（其實主要就是?來交換對稱秘鑰）

當服務端申請CA證書的時候，CA機構會對該服務端進?審核，并專?為該?站形成數字簽名，過程如下：

1. CA機構擁有?對稱加密的私鑰A和公鑰A’
2. CA機構對服務端申請的證書明?數據進?hash，形成數據摘要
3. 然后對數據摘要?CA私鑰A’加密，得到數字簽名S
   服務端申請的證書明?和數字簽名S共同組成了數字證書，這樣?份數字證書就可以頒發給服務端了

這樣就算中間人篡改了證書的內容，或者將簽名和內容都改了，那么客戶端也可以識別出來

2.5 方案5-非對稱加密+對稱加密+證書認證

有了上面的解決方法，所以就有了方案五，在客?端和服務器剛?建?連接的時候，服務器給客?端返回?個證書，證書包含了之前服務端的公鑰，也包含了?站的?份信息

客?端會進?認證，當客?端獲取到這個證書之后，會對證書進?校驗(防?證書是偽造的)
? 判定證書的有效期是否過期
? 判定證書的發布機構是否受信任(操作系統中已內置的受信任的證書發布機構).
? 驗證證書是否被篡改：從系統中拿到該證書發布機構的公鑰，對簽名解密，得到?個hash值(數據摘要)，設為hash1。然后計算整個證書的hash值，設為hash2。對?hash1和hash2是否相等。如果相等，則說明證書是沒有被篡改過的