一、HTTPS的概念

HTTPS 是一種基于SSL/TLS協議加密的HTTP協議。

因為我們知道HTTP協議存在安全問題，所以才會有HTTPS。

---

二、準備概念

2.1 什么是加密和解密

加密就是把明文（要傳輸的信息）進行?系列變換，生成密文。
解密就是把密文再進行?系列變換，還原成明文。

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

不知道大家知不知道藏頭詩，一般是一個人想將自己需要的表達的意思不那么被看出來，假設一個男生想要跟自己的女朋友說我想你了，但是不想在給她女朋友時，被人知道自己需要表達的意思，所以他生成了一首藏頭詩，并將這首詩交給了自己的女朋友，女朋友知道是藏頭詩，就提取每行詩的第一個字，再組合起來，就知道了這個男生的寫的什么了。

我本疏頑固當爾，
想得陽關更西路。
你天丈人之寶書，
了然不覺清心魂。

以這個例子來理解加密和解密：

• 明文：我想你了
• 密文：男生生成的詩
• 密鑰：藏頭詩的規則

---

2.2 為什么要加密

對于為什么要進行加密，就需要講到運營商劫持了。

不知道大家有沒有經歷過，自己在瀏覽器中想要下載應用A，最后下載完畢后，下載的卻是應用B，這就是運營商劫持，對用戶的下載鏈接進行了修改。

由于我們通過網絡傳輸的任何的數據包都會經過運營商的網絡設備（路由器，交換機等），那么運營商的網絡設備就可以解析出你傳輸的數據內容，并進行篡改。

點擊"下載按鈕"。其實就是在給服務器發送了?個HTTP請求，獲取到的HTTP響應其實就包含了該APP的下載鏈接。運營商劫持之后，就發現這個請求是要下載應用A，那么就?動的把交給用戶的響應給篡改成應用B的下載地址了。

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

HTTPS就是在HTTP的基礎上進行了加密，進?步的來保證用戶的信息安全。

---

2.3 常見的加密方式

2.3.1 對稱加密

采用單鑰密碼系統的加密方法，同?個密鑰可以同時用作信息的加密和解密，這種加密方法稱為對稱加密，也稱為單密鑰加密，特征：加密和解密所用的密鑰是相同的

• 常見對稱加密算法：DES、3DES、AES、TDEA、Blowfish、RC2等
• 特點：算法公開、計算量小、加密速度快、加密效率?

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

假設用戶A需要發送給用戶B一個數字9，單并不希望其他人看到，用戶A就將9異或上5得到的結果12發送給了用戶B，用戶B再將獲得的12異或上5得到9。這就是簡單的對稱加密。

---

2.3.1 非對稱加密

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

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

非對稱加密要用到兩個密鑰，?個叫做"公鑰"，?個叫做"私鑰"。
公鑰和私鑰是配對的。最?的缺點就是運算速度非常慢，比對稱加密要慢很多。

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

也可以反著用

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

---

2.4 數據摘要&&數據指紋

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

• 常見摘要算法：有MD5、SHA1、SHA256、SHA512等，算法把無限的映射成有限，因此可能會有碰撞（兩個不同的信息，算出的摘要相同，但是概率非常低）
• 摘要特征：和加密算法的區別是，摘要嚴格意義不是加密，因為沒有解密，只不過從摘要很難反推原信息，通常用來進行數據對比

---

三、HTTPS理解過程

3.1 只使用對稱加密

假設通信雙方都各自持有同?個密鑰A，且沒有別人知道，這兩方的通信安全是可以被保證的（除非密鑰被破解）。引入對稱加密之后，即使數據被截獲，由于中間人不知道密鑰是啥，因此就無法進行解密，也就不知道請求的真實內容是啥了。

但是服務器需要同時向很多的客戶端進行服務。

• 假設每個客戶端的密鑰都相同，那么中間人就知道了密鑰。
• 假設每個客戶端的密鑰都不同，則服務器在服務之前還需要將密鑰管理起來，顯然是不合理的
• 假設生成動態密鑰，在響應中包含動態密鑰，那動態密鑰需不需要加密呢？如果說加密，加密的動態密鑰怎么解密呢？如果說不加密，中間人就能拿到動態密鑰。

所以僅僅使用對稱加密是不行的。

---

3.2 只使用非對稱加密

假設服務器有公鑰A和私鑰B，當用戶第一次請求時，服務器會將公鑰發送給客戶端，注意中間人此時也拿到了公鑰。

然后客戶端使用公鑰將請求進行加密生成密文，由于密文只能使用私鑰才能解密，所以中間人無法對密文進行解密，當服務器拿到密文后，對密文進行了解密并且將自己的響應使用私鑰進行加密生成 密文’ 發送給客戶端，此時由于中間人和客戶端都有公鑰，所以導致中間人也可以對服務器的 密文’ 進行解密，導致信息泄露。

所以只使用非對稱加密也是不行的，它只能解決單向信息安全。

---

3.3 雙方都使用非對稱加密

前面只有服務器使用非對稱加密，只能保證客戶端發送請求時的信息安全，也就是只能保證單向信息安全，是不是客戶端也使用非對稱加密就能解決信息安全的問題呢？這里我們來做一些實驗。

假設客戶端有 公鑰A 和 私鑰A’ ，服務器有 公鑰B 和 私鑰B’ 。

當用戶首次發送請求時，就將公鑰A發送給了服務器，此時中間人也會獲得公鑰A，當服務器獲取到公鑰A后，就進行響應并將公鑰B發送給客戶端，此時中間人也獲得了公鑰B。

然后客戶端就將請求使用密鑰B進行加密生成密文發送給服務器，由于密文只能使用 密鑰B’ 才能夠解密，所以中間人無法進行解密，服務器則通過 密鑰B’ 進行解密獲得請求，然后將響應通過 密鑰A 生成 密文’ 發送給客戶端，同樣 密文’ 只能使用 密鑰A’ 才能夠解密，所以中間人無法進行解密，客戶端則通過 密鑰A’ 解密獲得響應。

看似雙方都使用非對稱加密解決了信息泄露的問題，實際上由于非對稱加密的特性，可能會導致效率低下，并且依舊存在信息安全的問題，這個問題會在3.5中進行講解。

---

3.4 對稱加密 + 非對稱加密

假設服務器有 公鑰B 和 私鑰B’ ，當用戶第一次請求時，服務器會將公鑰發送給客戶端，注意中間人此時也拿到了公鑰B。

此時客戶端動態生成密鑰A并使用公鑰B進行加密生成密文發送給服務器，由于中間人沒有私鑰B’，所以無法解密獲得密鑰A，服務器收到密文后，使用 私鑰B’ 進行解密，獲得密鑰A，從此之后客戶端和服務器就使用密鑰A進行加密和解密。

由于雙方只有一次請求和響應的時候使用非對稱加密，其他請求和回應的時候都是使用對稱加密，所以效率高。并且次方案看起來沒有信息安全問題，但實際上該方案還是存在與3.3一樣的還是存在信息安全的問題，這個問題會在3.5中進行講解。

---

3.5 中間人攻擊

上面3.3和3.4的方案看似沒有問題，那是因為當時舉例的時候，是讓客戶端和服務器交換完后，中間人才開始竊取信息，但是如果中間人在一開始就竊取信息會發生什么呢（這里以3.4的例子為例）？

假設服務器有 公鑰B 和 私鑰B’ ，中間人有 公鑰X 和 私鑰X’ 。

當用戶第一次請求時，服務器會將公鑰B發送給客戶端，此時中間人竊取服務器的響應，獲得了公鑰B，并且修改響應中公鑰B為公鑰X發送給了客戶端，然后客戶端動態生成密鑰A并使用公鑰X進行加密生成密文1發送給服務器，由于中間人有 私鑰X’ ，所以可以對密文1進行解密，從而獲得密鑰A，中間人再使用公鑰B對密鑰A加密生成密文2發送給服務器，服務器得到密文2后解密，獲得密鑰A，從此客戶端與服務器就使用密鑰A進行加密和解密，注意此時中間人也有密鑰A，所以中間人就可以獲取到密文中的信息，甚至修改密文中的信息。

這里我們就發現了3.4這個方案存在的問題了，實際上3.2和3.3也同樣存在這個問題，導致這個問題的原因是，客戶端無法辨別它第一次接收到的公鑰是否來自于服務器，也就無法判斷公鑰的合法性，3.6和3.7將會講解如何解決這個問題。

---

3.6 證書

前面我講到了客戶端無法判斷收到公鑰的相應是否來自于服務器，導致中間人可以竊取信息，甚至修改信息，所以就需要“身份證”來證明響應是否來自服務器。

3.6.1 CA認證

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

相信大家都遇到過下面這種情況，說該網站的證書有問題、或者過期了，這就證明了證書確實存在。

這里我就來講述一下申請CA證書的過程。

首先服務器所在的公司需要填寫申請信息，然后生成公鑰和私鑰，公司將私鑰保存好，將公鑰和申請信息打包到一起生成.csr文件，發送給CA機構。

然后CA機構收到后，就會對公司的一些基本信息、申請人信息等進行審核。

最后申請通過后就將證書發送給公司。證書中包括明文信息和數字簽名，明文信息中包括了申請證書時包含的一些信息和一些其他信息，數字簽名在下面后講解。

此后客戶端請求后，服務器的響應中就會包含證書，用來證明響應確實來自服務器。

---

3.6.2 簽名和數字簽名

簽名：簽名是用來判斷報文中的數據是否被修改。數據通過一個特定哈希算法獲得一個散列值，再將這個散列值通過私鑰進行加密獲得的簽名。接收方可以通過使用公鑰對簽名解密獲得哈希值，數據再使用同樣的哈希算法獲得一個散列值，通過判斷兩個散列值是否相同，判斷報文中的數據是否被修改。

數字簽名：數字簽名就是簽名的一種具體應用場景，用來判斷證書中的明文數據是否被修改，保證證書的完整性和真實性。先將上圖中的明文信息通過一個特定哈希算法獲得一個散列值，再將這個散列值通過CA機構的私鑰進行加密獲得的值。接收方可以通過使用CA機構的公鑰對簽名解密獲得哈希值，數據再使用同樣的哈希算法獲得一個散列值，通過判斷兩個散列值是否相同，判斷報文的完整性和真實性。

---

3.6.3 證書為什么能夠解決中間人攻擊

客戶端和服務器進行通信時，會被中間人竊取信息的主要原因就是客戶端無法判斷報文是否來自服務器，也就無法判斷其中的公鑰的合法性，這里我就來講述為什么證書能夠解決這個問題。

1. 中間人只修改數據
   若中間人只修改響應報文中的數據，則客戶端對簽名解密獲得的散列值幾乎不可能與報文數據使用相同Hash函數獲得的散列值相同，所以客戶端就能判斷出這個響應報文被修改過了，就會將這個報文舍棄。

2. 中間人只修改簽名
   中間人需要將響應報文中的公鑰改成自己的，才能夠在后序過程中竊取客戶端和服務器的信息，所以這樣做沒有意義，并且只需要證書也會被客戶端使用上面的方法發現。

3. 中間人同時修改數據和簽名

   • 首先，中間人是沒有CA的私鑰的，所以將數據修改后，中間人是無法對修改后的數據形成的散列值進行加密的。
   • 然后，假設中間人有自己的私鑰，將數據修改后，在使用自己的私鑰進行加密，這也是不行的，因為客戶端只會使用CA的公鑰對簽名進行解密，得出的結果幾乎不可能與修改后數據得到的散列值相同。
   • 最后，如果中間人想要騙過客戶端，那么中間人就需要使用真的證書，使用自己的證書替換掉響應中的證書，那么這樣做，中間人的信息就會暴露，并且證書中的明文信息中，有一個字段叫做域名，替換后證書的域名與客戶端訪問的域名一定是不相同的，此時客戶端就會發出警告。

---

3.6.4 在瀏覽器中查看證書

1. 點擊瀏覽器中的設置
   

2. 點擊隱私、搜索和服務中的安全性

3. 點擊管理證書

---

3.7 對稱加密 + 非對稱加密 + 證書（最終方案）

假設服務器有 公鑰B 和 私鑰B’ ，中間人有 公鑰X 和 私鑰X’ 。

當用戶第一次請求時，服務器會將證書發送給客戶端，此時中間人竊取服務器的響應，獲得了公鑰B，接下來就要分為兩種情況了：

1. 中間人修改了證書，則客戶端收到證書后，會判斷出證書不合法，將響應報文拋棄。
2. 中間人不修改證書，則客戶端收到證書后，會判斷出證書合法，并解密獲得公鑰B，此時客戶端動態生成密鑰A并使用公鑰B進行加密生成密文發送給服務器，由于中間人沒有私鑰B’，所以無法解密獲得密鑰A，服務器收到密文后，使用 私鑰B’ 進行解密，獲得密鑰A，從此之后客戶端和服務器就使用密鑰A進行加密和解密。

這就是HTTPS最終使用的方案。

---

3.8 CSR 生成

大家可以使用CSR 在線生成工具這個網站在線生成CSR

---

結尾

如果有什么建議和疑問，或是有什么錯誤，大家可以在評論區中提出。
希望大家以后也能和我一起進步！！🌹🌹
如果這篇文章對你有用的話，希望大家給一個三連支持一下！！🌹🌹