徹底搞懂HTTPs的加密原理
連結：https://zhuanlan.zhihu.com/p/43789231
HTTPS（SSL/TLS）的加密機制雖然是大家都應瞭解的基本知識，但網上很多相關文章總會忽略一些內容，沒有闡明完整的邏輯脈絡，我當年學習它的時候也廢了挺大功夫。
對稱與非對稱加密、數字簽名、數字證書等，在學習過程中，除了瞭解“它是什麼”，你是否有想過“為什麼是它”？我認為理解了後者才真正理解了HTTPS的加密機制。
本文以問題的形式逐步展開，一步步解開HTTPS的面紗，希望能幫助你徹底搞懂HTTPS。
為什麼需要加密？
因為http的內容是明文傳輸的，明文資料會經過中間代理伺服器、路由器、wifi熱點、通訊服務運營商等多個物理節點，如果資訊在傳輸過程中被劫持，傳輸的內容就完全暴露了。劫持者還可以篡改傳輸的資訊且不被雙方察覺，這就是中間人攻擊
對稱加密 。
什麼是對稱加密？
簡單說就是有一個金鑰，它可以加密一段資訊，也可以對加密後的資訊進行解密，和我們日常生活中用的鑰匙作用差不多。
對稱加密（https://sectigostore.com/blog/types-of-encryption-what-to-know-about-symmetric-vs-asymmetric-encryption/）用對稱加密可行嗎？
如果通訊雙方都各自持有同一個金鑰，且沒有別人知道，這兩方的通訊安全當然是可以被保證的（除非金鑰被破解）。
然而最大的問題就是這個金鑰怎麼讓傳輸的雙方知曉，同時不被別人知道。如果由伺服器生成一個金鑰並傳輸給瀏覽器，那在這個傳輸過程中金鑰被別人劫持到手了怎麼辦？之後他就能用金鑰解開雙方傳輸的任何內容了，所以這麼做當然不行。
換種思路？試想一下，如果瀏覽器內部就預存了網站A的金鑰，且可以確保除了瀏覽器和網站A，不會有任何外人知道該金鑰，那理論上用對稱加密是可以的，這樣瀏覽器只要預存好世界上所有HTTPS網站的金鑰就行了！這麼做顯然不現實。
怎麼辦？所以我們就需要非對稱加密 。
什麼是非對稱加密？
簡單說就是有兩把金鑰，通常一把叫做公鑰、一把叫私鑰，用公鑰加密的內容必須用私鑰才能解開，同樣，私鑰加密的內容只有公鑰能解開。
非對稱加密（https://sectigostore.com/blog/types-of-encryption-what-to-know-about-symmetric-vs-asymmetric-encryption/）
用非對稱加密可行嗎？
鑑於非對稱加密的機制，我們可能會有這種思路：伺服器先把公鑰以明文方式傳輸給瀏覽器，之後瀏覽器向伺服器傳資料前都先用這個公鑰加密好再傳，這條資料的安全似乎可以保障了！因為只有伺服器有相應的私鑰能解開公鑰加密的資料。
然而反過來由伺服器到瀏覽器的這條路怎麼保障安全？如果伺服器用它的私鑰加密資料傳給瀏覽器，那麼瀏覽器用公鑰可以解密它，而這個公鑰是一開始通過明文傳輸給瀏覽器的，若這個公鑰被中間人劫持到了，那他也能用該公鑰解密伺服器傳來的資訊了。所以目前似乎只能保證由瀏覽器向伺服器傳輸資料的安全性（其實仍有漏洞，下文會說），那利用這點你能想到什麼解決方案嗎？
改良的非對稱加密方案，似乎可以？
我們已經理解通過一組公鑰私鑰，可以保證單個方向傳輸的安全性，那用兩組公鑰私鑰，是否就能保證雙向傳輸都安全了？請看下面的過程：
- 某網站伺服器擁有公鑰A與對應的私鑰A’；瀏覽器擁有公鑰B與對應的私鑰B’。
- 瀏覽器把公鑰B明文傳輸給伺服器。
- 伺服器把公鑰A明文給傳輸瀏覽器。
- 之後瀏覽器向伺服器傳輸的內容都用公鑰A加密，伺服器收到後用私鑰A’解密。由於只有伺服器擁有私鑰A’，所以能保證這條資料的安全。
- 同理，伺服器向瀏覽器傳輸的內容都用公鑰B加密，瀏覽器收到後用私鑰B’解密。同上也可以保證這條資料的安全。
的確可以！拋開這裡面仍有的漏洞不談（下文會講），HTTPS的加密卻沒使用這種方案，為什麼？很重要的原因是非對稱加密演算法非常耗時，而對稱加密快很多。那我們能不能運用非對稱加密的特性解決前面提到的對稱加密的漏洞？
非對稱加密+對稱加密？
既然非對稱加密耗時，那非對稱加密+對稱加密結合可以嗎？而且得儘量減少非對稱加密的次數。當然是可以的，且非對稱加密、解密各只需用一次即可。
請看一下這個過程：
- 某網站擁有用於非對稱加密的公鑰A、私鑰A’。
- 瀏覽器向網站伺服器請求，伺服器把公鑰A明文給傳輸瀏覽器。
- 瀏覽器隨機生成一個用於對稱加密的金鑰X，用公鑰A加密後傳給伺服器。
- 伺服器拿到後用私鑰A’解密得到金鑰X。
- 這樣雙方就都擁有金鑰X了，且別人無法知道它。之後雙方所有資料都通過金鑰X加密解密即可。
完美！HTTPS基本就是採用了這種方案。完美？還是有漏洞的。
中間人攻擊
中間人攻擊（https://blog.pradeo.com/man-in-the-middle-attack）如果在資料傳輸過程中，中間人劫持到了資料，此時他的確無法得到瀏覽器生成的金鑰X，這個金鑰本身被公鑰A加密了，只有伺服器才有私鑰A’解開它，然而中間人卻完全不需要拿到私鑰A’就能幹壞事了。請看：
- 某網站有用於非對稱加密的公鑰A、私鑰A’。
- 瀏覽器向網站伺服器請求，伺服器把公鑰A明文給傳輸瀏覽器。
- 中間人劫持到公鑰A，儲存下來，把資料包中的公鑰A替換成自己偽造的公鑰B（它當然也擁有公鑰B對應的私鑰B’）。
- 瀏覽器生成一個用於對稱加密的金鑰X，用公鑰B（瀏覽器無法得知公鑰被替換了）加密後傳給伺服器。
- 中間人劫持後用私鑰B’解密得到金鑰X，再用公鑰A加密後傳給伺服器。
- 伺服器拿到後用私鑰A’解密得到金鑰X。
這樣在雙方都不會發現異常的情況下，中間人通過一套“狸貓換太子”的操作，掉包了伺服器傳來的公鑰，進而得到了金鑰X。根本原因是瀏覽器無法確認收到的公鑰是不是網站自己的，因為公鑰本身是明文傳輸的，難道還得對公鑰的傳輸進行加密？這似乎變成雞生蛋、蛋生雞的問題了。解法是什麼？
如何證明瀏覽器收到的公鑰一定是該網站的公鑰？
其實所有證明的源頭都是一條或多條不證自明的“公理”（可以回想一下數學上公理），由它推匯出一切。比如現實生活中，若想證明某身份證號一定是小明的，可以看他身份證，而身份證是由政府作證的，這裡的“公理”就是“政府機構可信”，這也是社會正常運作的前提。
那能不能類似地有個機構充當網際網路世界的“公理”呢？讓它作為一切證明的源頭，給網站頒發一個“身份證”？
它就是CA機構，它是如今網際網路世界正常運作的前提，而CA機構頒發的“身份證”就是數字證書。
數字證書
網站在使用HTTPS前，需要向CA機構申領一份數字證書，數字證書裡含有證書持有者資訊、公鑰資訊等。伺服器把證書傳輸給瀏覽器，瀏覽器從證書裡獲取公鑰就行了，證書就如身份證，證明“該公鑰對應該網站”。而這裡又有一個顯而易見的問題，“證書本身的傳輸過程中，如何防止被篡改”？即如何證明證書本身的真實性？身份證運用了一些防偽技術，而數字證書怎麼防偽呢？解決這個問題我們就接近勝利了！
如何放防止數字證書被篡改？
我們把證書原本的內容生成一份“簽名”，比對證書內容和簽名是否一致就能判別是否被篡改。這就是數字證書的“防偽技術”，這裡的“簽名”就叫數字簽名：
數字簽名
這部分內容建議看下圖並結合後面的文字理解，圖中左側是數字簽名的製作過程，右側是驗證過程：
數字簽名的生成與驗證（https://cheapsslsecurity.com/blog/digital-signature-vs-digital-certificate-the-difference-explained/）
數字簽名的製作過程：
- CA機構擁有非對稱加密的私鑰和公鑰。
- CA機構對證書明文資料T進行hash。
- 對hash後的值用私鑰加密，得到數字簽名S。
明文和數字簽名共同組成了數字證書，這樣一份數字證書就可以頒發給網站了。
那瀏覽器拿到伺服器傳來的數字證書後，如何驗證它是不是真的？（有沒有被篡改、掉包）
瀏覽器驗證過程：
- 拿到證書，得到明文T，簽名S。
- 用CA機構的公鑰對S解密（由於是瀏覽器信任的機構，所以瀏覽器保有它的公鑰。詳情見下文），得到S’。
- 用證書裡指明的hash演算法對明文T進行hash得到T’。
- 顯然通過以上步驟，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://publib.boulder.ibm.com/tividd/td/TRM/GC32-1323-00/en_US/HTML/admin230.htm）每次進行HTTPS請求時都必須在SSL/TLS層進行握手傳輸金鑰嗎？
這也是我當時的困惑之一，顯然每次請求都經歷一次金鑰傳輸過程非常耗時，那怎麼達到只傳輸一次呢？
伺服器會為每個瀏覽器（或客戶端軟體）維護一個session ID，在TLS握手階段傳給瀏覽器，瀏覽器生成好金鑰傳給伺服器後，伺服器會把該金鑰存到相應的session ID下，之後瀏覽器每次請求都會攜帶session ID，伺服器會根據session ID找到相應的金鑰並進行解密加密操作，這樣就不必要每次重新制作、傳輸金鑰了！
總結
可以看下這張圖，梳理一下整個流程（SSL、TLS握手有一些區別，不同版本間也有區別，不過大致過程就是這樣）：
（www.extremetech.com）
至此，我們已自上而下地打通了HTTPS加密的整體脈絡以及核心知識點，不知你是否真正搞懂了HTTPS呢？
找幾個時間，多看、多想、多理解幾次就會越來越清晰的！
那麼，下面的問題你是否已經可以解答了呢？
- 為什麼要用對稱加密+非對稱加密？
- 為什麼不能只用非對稱加密？
- 為什麼需要數字證書？
- 為什麼需要數字簽名？
…