#為什麼需要加密？

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

#什麼是對稱加密？

簡單說就是有一個密鑰，它可以加密一段信息，也可以對加密後的信息進行解密，和我們日常生活中用的鑰匙作用差不多。

#用對稱加密可行嗎？

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

然而最大的問題就是這個密鑰怎麼讓傳輸的雙方知曉，同時不被別人知道。如果由服務器生成一個密鑰並傳輸給瀏覽器，那在這個傳輸過程中密鑰被別人劫持到手了怎麼辦？之後他就能用密鑰解開雙方傳輸的任何內容了，所以這麼做當然不行。

換種思路？試想一下，如果瀏覽器內部就預存了網站 A 的密鑰，且可以確保除了瀏覽器和網站 A，不會有任何外人知道該密鑰，那理論上用對稱加密是可以的，這樣瀏覽器只要預存好世界上所有 HTTPS 網站的密鑰就行了！這麼做顯然不現實。
怎麼辦？所以我們就需要非對稱加密 。

#什麼是非對稱加密？

簡單說就是有兩把密鑰，通常一把叫做公鑰、一把叫私鑰，用公鑰加密的內容必須用私鑰才能解開，同樣，私鑰加密的內容只有公鑰能解開。

#用非對稱加密可行嗎？

鑒於非對稱加密的機制，我們可能會有這種思路：服務器先把公鑰以明文方式傳輸給瀏覽器，之後瀏覽器向服務器傳數據前都先用這個公鑰加密好再傳，這條數據的安全似乎可以保障了！因為只有服務器有相應的私鑰能解開公鑰加密的數據。

然而反過來由服務器到瀏覽器的這條路怎麼保障安全？如果服務器用它的私鑰加密數據傳給瀏覽器，那麼瀏覽器用公鑰可以解密它，而這個公鑰是一開始通過明文傳輸給瀏覽器的，若這個公鑰被中間人劫持到了，那他也能用該公鑰解密服務器傳來的信息了。所以目前似乎只能保證由瀏覽器向服務器傳輸數據的安全性（其實仍有漏洞，下文會說），那利用這點你能想到什麼解決方案嗎？

#改良的非對稱加密方案，似乎可以？

我們已經理解通過一組公鑰私鑰，可以保證單個方向傳輸的安全性，那用兩組公鑰私鑰，是否就能保證雙向傳輸都安全了？請看下麵的過程：

1. 某網站服務器擁有公鑰 A 與對應的私鑰 A’；瀏覽器擁有公鑰 B 與對應的私鑰 B’。
2. 瀏覽器把公鑰 B 明文傳輸給服務器。
3. 服務器把公鑰 A 明文給傳輸瀏覽器。
4. 之後瀏覽器向服務器傳輸的內容都用公鑰 A 加密，服務器收到後用私鑰 A’解密。由於只有服務器擁有私鑰 A’，所以能保證這條數據的安全。
5. 同理，服務器向瀏覽器傳輸的內容都用公鑰 B 加密，瀏覽器收到後用私鑰 B’解密。同上也可以保證這條數據的安全。

的確可以！拋開這裡面仍有的漏洞不談（下文會講），HTTPS 的加密卻沒使用這種方案，為什麼？很重要的原因是非對稱加密演算法非常耗時，而對稱加密快很多。那我們能不能運用非對稱加密的特性解決前面提到的對稱加密的漏洞？

#非對稱加密+對稱加密？

既然非對稱加密耗時，那非對稱加密+對稱加密結合可以嗎？而且得盡量減少非對稱加密的次數。當然是可以的，且非對稱加密、解密各只需用一次即可。
請看一下這個過程：

1. 某網站擁有用於非對稱加密的公鑰 A、私鑰 A’。
2. 瀏覽器向網站服務器請求，服務器把公鑰 A 明文給傳輸瀏覽器。
3. 瀏覽器隨機生成一個用於對稱加密的密鑰 X，用公鑰 A 加密後傳給服務器。
4. 服務器拿到後用私鑰 A’解密得到密鑰 X。
5. 這樣雙方就都擁有密鑰 X 了，且別人無法知道它。之後雙方所有數據都通過密鑰 X 加密解密即可。

完美！HTTPS 基本就是採用了這種方案。完美？還是有漏洞的。

#中間人攻擊

如果在數據傳輸過程中，中間人劫持到了數據，此時他的確無法得到瀏覽器生成的密鑰 X，這個密鑰本身被公鑰 A 加密了，只有服務器才有私鑰 A’解開它，然而中間人卻完全不需要拿到私鑰 A’就能乾壞事了。請看：

1. 某網站有用於非對稱加密的公鑰 A、私鑰 A’。
2. 瀏覽器向網站服務器請求，服務器把公鑰 A 明文給傳輸瀏覽器。
3. 中間人劫持到公鑰 A，保存下來，把數據包中的公鑰 A 替換成自己偽造的公鑰 B（它當然也擁有公鑰 B 對應的私鑰 B’）。
4. 瀏覽器生成一個用於對稱加密的密鑰 X，用公鑰 B（瀏覽器無法得知公鑰被替換了）加密後傳給服務器。
5. 中間人劫持後用私鑰 B’解密得到密鑰 X，再用公鑰 A 加密後傳給服務器。
6. 服務器拿到後用私鑰 A’解密得到密鑰 X。

這樣在雙方都不會發現異常的情況下，中間人通過一套“狸貓換太子”的操作，掉包了服務器傳來的公鑰，進而得到了密鑰 X。**根本原因是瀏覽器無法確認收到的公鑰是不是網站自己的，**因為公鑰本身是明文傳輸的，難道還得對公鑰的傳輸進行加密？這似乎變成雞生蛋、蛋生雞的問題了。解法是什麼？

#如何證明瀏覽器收到的公鑰一定是該網站的公鑰？

其實所有證明的源頭都是一條或多條不證自明的“公理”（可以回想一下數學上公理），由它推導出一切。比如現實生活中，若想證明某身份證號一定是小明的，可以看他身份證，而身份證是由政府作證的，這里的“公理”就是“政府機構可信”，這也是社會正常運作的前提。

那能不能類似地有個機構充當網際網路世界的“公理”呢？讓它作為一切證明的源頭，給網站頒發一個“身份證”？

它就是CA 機構，它是如今網際網路世界正常運作的前提，而 CA 機構頒發的“身份證”就是數字證書。

#數字證書

網站在使用 HTTPS 前，需要向CA 機構申領一份數字證書，數字證書里含有證書持有者信息、公鑰信息等。服務器把證書傳輸給瀏覽器，瀏覽器從證書里獲取公鑰就行了，證書就如身份證，證明“該公鑰對應該網站”。而這里又有一個顯而易見的問題，“證書本身的傳輸過程中，如何防止被篡改”？即如何證明證書本身的真實性？身份證運用了一些防偽技術，而數字證書怎麼防偽呢？解決這個問題我們就接近勝利了！

#如何放防止數字證書被篡改？

我們把證書原本的內容生成一份“簽名”，比對證書內容和簽名是否一致就能判別是否被篡改。這就是數字證書的“防偽技術”，這里的“簽名”就叫數字簽名：

#數字簽名

數字簽名的製作過程：

1. CA 機構擁有非對稱加密的私鑰和公鑰。
2. CA 機構對證書明文數據 T 進行 hash。
3. 對 hash 後的值用私鑰加密，得到數字簽名 S。

明文和數字簽名共同組成了數字證書，這樣一份數字證書就可以頒發給網站了。
那瀏覽器拿到服務器傳來的數字證書後，如何驗證它是不是真的？（有沒有被篡改、掉包）

瀏覽器驗證過程：

1. 拿到證書，得到明文 T，簽名 S。
2. 用 CA 機構的公鑰對 S 解密（由於是瀏覽器信任的機構，所以瀏覽器保有它的公鑰。詳情見下文），得到 S’。
3. 用證書里指明的 hash 演算法對明文 T 進行 hash 得到 T’。
4. 顯然通過以上步驟，T’應當等於 S‘，除非明文或簽名被篡改。所以此時比較 S’是否等於 T’，等於則表明證書可信。

為何麼這樣可以保證證書可信呢？我們來仔細想一下。

#中間人有可能篡改該證書嗎？

假設中間人篡改了證書的原文，由於他沒有 CA 機構的私鑰，所以無法得到此時加密後簽名，無法相應地篡改簽名。瀏覽器收到該證書後會發現原文和簽名解密後的值不一致，則說明證書已被篡改，證書不可信，從而終止向服務器傳輸信息，防止信息泄露給中間人。

既然不可能篡改，那整個證書被掉包呢？

#中間人有可能把證書掉包嗎？

假設有另一個網站 B 也拿到了 CA 機構認證的證書，它想劫持網站 A 的信息。於是它成為中間人攔截到了 A 傳給瀏覽器的證書，然後替換成自己的證書，傳給瀏覽器，之後瀏覽器就會錯誤地拿到 B 的證書里的公鑰了，這確實會導致上文“中間人攻擊”那裡提到的漏洞？

其實這並不會發生，因為證書里包含了網站 A 的信息，包括功能變數名稱，瀏覽器把證書里的功能變數名稱與自己請求的功能變數名稱比對一下就知道有沒有被掉包了。

#為什麼製作數字簽名時需要 hash 一次？

我初識 HTTPS 的時候就有這個疑問，因為似乎那裡的 hash 有點多餘，把 hash 過程去掉也能保證證書沒有被篡改。

最顯然的是性能問題，前面我們已經說了非對稱加密效率較差，證書信息一般較長，比較耗時。而 hash 後得到的是固定長度的信息（比如用 md5 演算法 hash 後可以得到固定的 128 位的值），這樣加解密就快很多。

當然也有安全上的原因，這部分內容相對深一些，感興趣的可以看這篇解答：crypto.stackexchange.com/a/12780

#怎麼證明 CA 機構的公鑰是可信的？

你們可能會發現上文中說到 CA 機構的公鑰，我幾乎一筆帶過，“瀏覽器保有它的公鑰”，這是個什麼保有法？怎麼證明這個公鑰是否可信？

讓我們回想一下數字證書到底是乾啥的？沒錯，為了證明某公鑰是可信的，即“該公鑰是否對應該網站”，那 CA 機構的公鑰是否也可以用數字證書來證明？沒錯，操作系統、瀏覽器本身會預裝一些它們信任的根證書，如果其中會有 CA 機構的根證書，這樣就可以拿到它對應的可信公鑰了。

實際上證書之間的認證也可以不止一層，可以 A 信任 B，B 信任 C，以此類推，我們把它叫做信任鏈或數字證書鏈。也就是一連串的數字證書，由根證書為起點，透過層層信任，使終端實體證書的持有者可以獲得轉授的信任，以證明身份。

另外，不知你們是否遇到過網站訪問不了、提示需安裝證書的情況？這里安裝的就是根證書。說明瀏覽器不認給這個網站頒發證書的機構，那麼你就得手動下載安裝該機構的根證書（風險自己承擔 XD）。安裝後，你就有了它的公鑰，就可以用它驗證服務器發來的證書是否可信了。

#每次進行 HTTPS 請求時都必須在 SSL/TLS 層進行握手傳輸密鑰嗎？

這也是我當時的困惑之一，顯然每次請求都經歷一次密鑰傳輸過程非常耗時，那怎麼達到只傳輸一次呢？

服務器會為每個瀏覽器（或客戶端軟體）維護一個 session ID，在 TLS 握手階段傳給瀏覽器，瀏覽器生成好密鑰傳給服務器後，服務器會把該密鑰存到相應的 session ID 下，之後瀏覽器每次請求都會攜帶 session ID，服務器會根據 session ID 找到相應的密鑰並進行解密加密操作，這樣就不必要每次重新製作、傳輸密鑰了！

#總結

至此，我們已自上而下地打通了 HTTPS 加密的整體脈絡以及核心知識點，不知你是否真正搞懂了 HTTPS 呢？
找幾個時間，多看、多想、多理解幾次就會越來越清晰的！
那麼，下麵的問題你是否已經可以解答了呢？

1. 為什麼要用對稱加密+非對稱加密？
2. 為什麼不能只用非對稱加密？
3. 為什麼需要數字證書？
4. 為什麼需要數字簽名？
   …

當然，由於篇幅和能力所限，一些更深入的內容沒有覆蓋到。但我認為一般對於前後端開發人員來說，瞭解到這步就夠了，有興趣的可以再深入研究~如有疏漏之處，歡迎指出。