一、HTTPS 是什么

HTTP 協議內容都是按照文本的方式明文傳輸的，這就導致在傳輸過程中出現一些被篡改的情況。HTTPS 也是一個應用層協議，是在 HTTP 協議的基礎上引入了一個加密層。

二、加密

1. 加密概念

加密就是把明文 (要傳輸的信息)進行一系列變換，生成密文。

解密就是把密文再進行一系列變換，還原成明文。

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

例如我們客戶端需要傳輸一個數字 5 給服務端，假設加密的方法為 5^2，于是 5 就稱為明文，2 稱為密鑰；生成新的數字 7，7 就稱為密文。當密文到了服務端進行解密，再異或密鑰即可得到明文。

2. 加密的原因

當我們下載一個軟件時，在客戶端和服務器之間還有一種角色，叫做運營商，所以我們的所有請求，在發給服務器之前，都要先經過運營商的，然后再由運營商轉發到服務端。所以我們在發起下載請求時，運營商正常轉發給服務端，但是服務端響應下載鏈接時，運營商卻可以將該響應的下載鏈接替換掉，導致我們下載的軟件不是我們想要的！

由于我們通過網絡傳輸的任何的數據包都會經過運營商的網絡設備（路由器, 交換機等），那么運營商的網絡設備就可以解析出你傳輸的數據內容，并進行篡改。點擊 “下載按鈕”，其實就是在給服務器發送了一個 HTTP 請求，獲取到的 HTTP 響應其實就包含了該 APP 的下載鏈接。運營商劫持之后，就發現這個請求是要下載某個 APP，那么就自動的把交給用戶的響應給篡改成另外一個軟件的下載地址了。

所以，因為 http 的內容是明文傳輸的，明文數據會經過路由器、wifi熱點、通信服務運營商、代理服務器等多個物理節點，如果信息在傳輸過程中被劫持，傳輸的內容就完全暴露了。劫持者還可以篡改傳輸的信息且不被雙方察覺，這就是中間人攻擊 ，所以我們才需要對信息進行加密。另外，不止運營商可以劫持，其他的黑客也可以用類似的手段進行劫持，來竊取用戶隱私信息，或者篡改內容！

所以在互聯網上，明文傳輸是比較危險的事情！HTTPS 就是在 HTTP 的基礎上進行了加密，進?步的來保證用戶的信息安全！

3. 常見的加密方式

（1）對稱加密

采用單鑰密碼系統的加密方法，同一個密鑰可以同時用作信息的加密和解密，這種加密方法稱為對稱加密，也稱為單密鑰加密，特征：加密和解密所用的密鑰是相同的。也就是我們上面舉的異或的例子。

• 特點：算法公開、計算量小、加密速度快、加密效率高

對稱加密其實就是通過同一個 “密鑰”，把明文加密成密文，并且也能把密文解密成明文。

（2）非對稱加密

需要兩個密鑰來進行加密和解密，這兩個密鑰是公開密鑰（public key，簡稱公鑰）和私有密鑰（private key，簡稱私鑰）。

• 特點：算法強度復雜、安全性依賴于算法與密鑰但是由于其算法復雜，而使得加密解密速度沒有對稱加密解密的速度快。

非對稱加密要用到兩個密鑰，一個叫做 “公鑰”，?個叫做 “私鑰”。

公鑰和私鑰是配對的，最大的缺點就是運算速度非常慢，比對稱加密要慢很多。其中：

• 通過公鑰對明文加密，變成密文
• 通過私鑰對密文解密，變成明文

也可以反著用：

• 通過私鑰對明文加密，變成密文
• 通過公鑰對密文解密，變成明文

也就是說，在一組公鑰和私鑰中，如果我們用了私鑰加密，那么只要擁有公鑰的人都可以解密；反過來，如果用了公鑰加密，那么只能由擁有私鑰的人來解密。

三、數據摘要(數據指紋)

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

四、HTTPS 的工作原理探究

既然要保證數據安全，就需要進行 “加密”。網絡傳輸中不再直接傳輸明文了，而是加密之后的 “密文”。加密的方式有很多，但是整體可以分成兩大類：對稱加密和非對稱加密。

1. 只使用對稱加密

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

引入對稱加密之后，即使數據被截獲，由于黑客不知道密鑰是啥，因此就無法進行解密, 也就不知道請求的真實內容是什么了。

但事情沒這么簡單，服務器同一時刻其實是給很多客戶端提供服務的。這么多客戶端，每個人用的秘鑰都必須是不同的(如果是相同那密鑰就太容易擴散了, 黑客就也能拿到了)。因此服務器就需要維護每個客戶端和每個密鑰之間的關聯關系，這也是個很麻煩的事情。

比較較理想的做法，就是能在客戶端和服務器建立連接的時候，雙方協商確定這次的密鑰是什么。但是如果直接把密鑰明文傳輸，那么黑客也就能獲得密鑰了！此時后續的加密操作就形同虛設了，因此密鑰的傳輸也必須加密傳輸！

2. 只使用非對稱加密

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

但是服務器到瀏覽器的這條路怎么保障安全？如果服務器用它的私鑰加密數據傳給瀏覽器，那么瀏覽器用公鑰可以解密它，而這個公鑰是一開始通過明文傳輸給瀏覽器的，若這個公鑰被中間人劫持到了，那它也能用該公鑰解密服務器傳來的信息了。

3. 雙方都使用非對稱加密

服務端擁有公鑰S與對應的私鑰S’，客戶端擁有公鑰C與對應的私鑰C’。客戶和服務端交換公鑰，客戶端給服務端發信息：先用S對數據加密，再發送，只能由服務器解密，因為只有服務器有私鑰S’；服務端給客戶端發信息：先用C對數據加密，在發送，只能由客戶端解密，因為只有客戶端有私鑰C’。但是這樣效率太低，而且依然還有安全問題！這個問題我們后面再說。如下圖：

4. 非對稱加密 + 對稱加密

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

雖然上面已經比較接近答案了，但是依舊有安全問題。方案 2，方案 3，方案 4 都存在一個問題，如果最開始，中間人就已經開始攻擊了呢？

中間人攻擊

中間人攻擊，Man-in-the-MiddleAttack，簡稱 “MITM攻擊”。確實，在?案2/3/4中，客戶端獲取到公鑰S之后，對客戶端形成的對稱秘鑰C用服務端給客戶端的公鑰S進行加密，中間人即使竊取到了數據，此時中間人確實無法解出客戶端形成的密鑰C，因為只有服務器有私鑰S’。

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

• 服務器具有非對稱加密算法的公鑰S，私鑰S’；

• 中間人具有非對稱加密算法的公鑰M，私鑰M’；

• 客戶端向服務器發起請求，服務器明文傳送公鑰S給客戶端；

• 此時中間人劫持數據報報文，提取公鑰S并保存好，然后將被劫持報?中的公鑰S替換成為自己的公鑰M，并將偽造報文發給客戶端；

• 客戶端收到報文，提取公鑰M(自己當然不知道公鑰被更換過了)，自己形成對稱秘鑰C，用公鑰M加密C，形成報文發送給服務器；

• 中間人劫持后，直接用自己的私鑰M’進行解密，得到通信秘鑰C，再用曾經保存的服務端公鑰S加密后，將報文推送給服務器；

• 服務器拿到報文，用自己的私鑰S’解密，得到通信秘鑰C；

• 雙方開始采用C進行對稱加密，進行通信。但是?切都在中間人的掌握中，劫持數據，進?竊聽甚至修改，都是可以的；

上面的攻擊方案，同樣適用于方案2，方案3；問題本質出在哪里了呢？客戶端無法確定收到的含有公鑰的數據報文，就是目標服務器發送過來的！

CA認證

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

這個證書可以理解成是?個結構化的字符串，里面包含了以下信息：

• 證書發布機構
• 證書有效期
• 公鑰
• 證書所有者
• 簽名
• …

需要注意的是：申請證書的時候，需要在特定平臺生成查，會同時生成一對密鑰對，即公鑰和私鑰。這對密鑰對就是用來在網絡通信中進行明文加密的。

其中公鑰會隨著CSR文件，?起發給CA進行權威認證，私鑰服務端自己保留，用來后續進行通信（其實主要就是用來交換對稱秘鑰）。

理解數據簽名

那么客戶端該如何驗證證書是合法的呢？在服務端給我們返回證書的時候，中間人也可以篡改證書中的內容呀。

首先我們先理解一下簽名的過程，服務端首先將用戶的請求，即提交上來的數據打包成 .csr 文件，并附上自己形成的公鑰等信息向 CA機構 申請認證，這個認證過程如下：

首先將提交上來的數據通過散列函數形成數據摘要，然后 CA機構 使用自己的私鑰 CA’ 進行加密，該數據摘要使用私鑰 CA’ 加密后稱為簽名，簽名和數據加在一起就稱為證書！該證書就返回給服務端，然后服務端就把該證書返回給客戶端！

那么當服務端給客戶端返回證書的時候，中間人也可以對證書的內容篡改呀，怎么保證客戶端收到的證書就是服務端發送過來的而沒有被篡改過呢？這時候客戶端就需要將該證書進行拆分，將明文部分和簽名進行拆分。先對明文部分使用同樣的散列函數 md5 形成數據摘要；我們知道，簽名是經過數據摘要和 CA機構 的私鑰 CA‘ 加密過的，那么 CA機構 的公鑰在哪呢？CA機構 會公開自己形成證書簽名時所用的公鑰！怎么公開呢？客戶端當中會內置很多權威 CA機構 的公鑰！所以客戶端就可以使用 CA機構 在自己內置的公鑰 CA 對該簽名進行解密，得到加密前的數據摘要！然后將證書中的明文部分和數據摘要進行對比就能確保該證書的權威性！如下圖：

5. 非對稱加密 + 對稱加密 + 證書認證

所以正確的方案應該是 非對稱加密 + 對稱加密 + 證書認證，如下圖：

如果有中間人對該證書中的公鑰進行的更換，那么也就是修改了證書的明文部分，那么當客戶端使用 CA機構 的公鑰解簽名的時候，得到的數據摘要和明文部分不匹配，那么就會認證失敗。