目錄

一，HTTPS是什么

二，兩種加密方式

三，HTTPS的加密過程

3.1 引入對稱加密

3.2 引入非對稱加密

3.3 引入證書

---

一，HTTPS是什么

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

也就是說使用HTTP協議進行網絡傳輸是不安全的，所以現在使用HTTPS協議來進一步確保用戶的信息安全。

二，兩種加密方式

加密就是把明文通過一系列的變換，生成密文，解密就是把密文再通過一系列的變換，還原成明文

加密的兩種方式：

1）對稱加密：加密和解密使用的密鑰是同一個密鑰

• 明文 + 密鑰 => 密文
• 密文 + 密鑰 => 明文。

2）非對稱加密：加密和解密使用的密鑰是一對密鑰，分為公鑰和私鑰，這兩者是可以互換的，使用公鑰加密，就使用私鑰解密，使用私鑰加密，就使用公鑰解密

• 明文 + 公鑰 => 密文 /?明文 + 私鑰 => 密文
• 密文 + 私鑰 => 明文 /?密文 + 公鑰 => 明文

三，HTTPS的加密過程

3.1 引入對稱加密

仔細思考，上面的模型還存在一個重大問題，服務器不是只和一個客戶端通信，那么這些客戶端使用的密鑰是相同的嗎？很明顯，每個客戶端的密鑰必須是不同的，這樣彼此之間才不知道對方的密鑰是啥。

既然要求每個客戶端的密鑰都不相同，那么就需要在每個客戶端與服務器建立連接的時候，把密鑰生成出來(這里涉及到一些隨機數機制來確保密鑰互不相同)，然后客戶端再把生成出來的密鑰通過網絡發給服務器。

但是這里又出現了一個問題，客戶端發送給服務器的密鑰也是沒有加密的，也就是說密鑰是可以被黑客截獲的，這樣就又回到了最初的問題，如何加密？所以這時我們就引入了另一種加密方式 —— 非對稱加密。

3.2 引入非對稱加密

通過上述過程，客戶端生成的密鑰就不會被黑客獲取到，接下來就可以通過密鑰來進行通信了。這時候就會有人問了，既然可以使用非對稱密鑰加密，那為什么還要使用對稱加密，直接全部使用非對稱加密不就行了嗎？

這是因為非對稱加密/解密，運算成本是很高的，運算速度也比較慢，而對稱加密/解密，運算成本低，速度快。所以非對稱加密通常是在一些比較關鍵的環節使用(傳遞密鑰)，成本就比較可控，后續傳輸大量的業務數據，都是使用效率更高的對稱加密。這樣整體的傳輸效率也會得到提高。

但是上述流程還存在一個漏洞，畫個圖理解一下：

?在上述流程中，客戶端的對稱密鑰就會被黑客獲取到，之后客戶端與服務器之間的通信也就會一覽無余了。那么要如何解決這種 "中間人" 問題呢？這時候就需要引入第三方公正機構。

3.3 引入證書

會發生上述 "中間人" 問題的原因是客戶端無法區分這個公鑰究竟是不是黑客偽造的，因此在這里就要引入第三方，即一個被大家信任的"公正機構"，如果公正機構說這個公鑰是正確的，不是被偽造的，我們就可以使用這個公鑰進行加密。

將這個流程畫個圖理解一下：

公正機構針對證書中的各個屬性，計算出來的一個校驗和，并對這個校驗和進行加密，就得到了數字簽名，這里的加密是指公正機構使用自己生成的一對非對稱密鑰加密，公正機構會使用自己持有的私鑰對校驗和進行加密，公鑰會發布到各個客戶端設備中（往往公鑰是內置到系統中，安裝了系統，就會自導公正機構的公鑰）。

當客戶端拿到數字簽名，就可以通過系統內置的公正機構的公鑰進行解密，得到最初的校驗和，然后客戶端在重新計算一遍校驗和，看看和解密出來的校驗和是否一樣，如果一致，就說明證書沒有被篡改，公鑰是可信的。

在上述機制下，黑客就無法對證書內容進行篡改了，或者說篡改了也會被發現：

1. 如果黑客篡改了里面服務器的公鑰，替換成自己的，那么客戶端在進行校驗和驗證的時候，就會發現校驗和不一致，客戶端就認為公鑰被篡改了
2. 如果黑客不止替換了公鑰，還將數字簽名給替換了，那么由于黑客沒有私鑰，無法對其篡改后的數據進行加密，或者說，使用自己的私鑰加密后，客戶端無法對其進行解密，而公正機構的公鑰是客戶端系統自帶的，黑客無法替換
3. 如果黑客自己申請一個證書，完全替換掉服務器的證書呢？這也是行不通的，因為申請證書是需要提交材料的，其中就有網站的主域名，認證機構會對這個域名是否歸你所有進行認證。

綜上所述，只要通過證書的檢驗，就說明公鑰是服務器的公鑰了