HTTPS（SSL/TLS）的加密機制雖然是大家都應了解的基本知識，但網上很多相關文章總會忽略一些內容，沒有闡明完整的邏輯脈絡，我學習它的時候也曾廢了些功夫。
對稱與非對稱加密、數字簽名、數字證書等，在學習過程中，除了了解“它是什麼”，你是否有想過“為什麼是它”？我認為有必要搞清楚後者，否則你可能只是單純地記住了被灌輸的知識，而未真正理解它。
本文以問題的形式逐步展開，一步步解開HTTPS的面紗，希望能幫助你徹底搞懂HTTPS！
（閱讀完需要花些時間，歡迎收藏、點贊~）
為什麼需要加密？
因為http的內容是明文傳輸的，明文數據會經過中間代理服務器、路由器、wifi熱點、通信服務運營商等多個物理節點，如果信息在傳輸過程中被劫持，傳輸的內容就完全暴露了。劫持者還可以篡改傳輸的信息且不被雙方察覺，這就是中间人攻击。所以我們才需要對信息進行加密。最容易理解的就是對稱加密。
什麼是對稱加密？
簡單說就是有一個密鑰，它可以加密一段信息，也可以對加密後的信息進行解密，和我們日常生活中用的鑰匙作用差不多。
SSL單向驗證
用非對稱加密可行嗎？
鑑於非對稱加密的機制，我們可能會有這種思路：服務器先把公鑰以明文方式傳輸給瀏覽器，之後瀏覽器向服務器傳數據前都先用這個公鑰加密好再傳，這條數據的安全似乎可以保障了！因為只有服務器有相應的私鑰能解開公鑰加密的數據。
然而反過來由服務器到瀏覽器的這條路怎麼保障安全？如果服務器用它的私鑰加密數據傳給瀏覽器，那麼瀏覽器用公鑰可以解密它，而這個公鑰是一開始通過明文傳輸給瀏覽器的，若這個公鑰被中間人劫持到了，那他也能用該公鑰解密服務器傳來的信息了。所以目前似乎只能保證由瀏覽器向服務器傳輸數據的安全性（其實仍有漏洞，下文會說），那利用這點你能想到什麼解決方案嗎？
改良的非對稱加密方案，似乎可以？
我們已經理解通過一組公鑰私鑰，可以保證單個方向傳輸的安全性，那用兩組公鑰私鑰，是否就能保證雙向傳輸都安全了？請看下面的過程：
- 某網站服務器擁有公鑰A與對應的私鑰A’；瀏覽器擁有公鑰B與對應的私鑰B’。
- 瀏覽器把公鑰B明文傳輸給服務器。
- 服務器把公鑰A明文給傳輸瀏覽器。
- 之後瀏覽器向服務器傳輸的內容都用公鑰A加密，服務器收到後用私鑰A’解密。由於只有服務器擁有私鑰A’，所以能保證這條數據的安全。
- 同理，服務器向瀏覽器傳輸的內容都用公鑰B加密，瀏覽器收到後用私鑰B’解密。同上也可以保證這條數據的安全。
的確可以！拋開這裡面仍有的漏洞不談（下文會講），HTTPS的加密卻沒使用這種方案，為什麼？很重要的原因是非對稱加密算法非常耗時，而對稱加密快很多。那我們能不能運用非對稱加密的特性解決前面提到的對稱加密的漏洞？
非對稱加密+對稱加密？
既然非對稱加密耗時，那非對稱加密+對稱加密結合可以嗎？而且得盡量減少非對稱加密的次數。當然是可以的，且非對稱加密、解密各只需用一次即可。
請看一下這個過程：
- 某網站擁有用於非對稱加密的公鑰A、私鑰A’。
- 瀏覽器向網站服務器請求，服務器把公鑰A明文給傳輸瀏覽器。
- 瀏覽器隨機生成一個用於對稱加密的密鑰X，用公鑰A加密後傳給服務器。
- 服務器拿到後用私鑰A’解密得到密鑰X。
- 這樣雙方就都擁有密鑰X了，且別人無法知道它。之後雙方所有數據都通過密鑰X加密解密即可。
完美！HTTPS基本就是採用了這種方案。完美？還是有漏洞的。
中間人攻擊
如果在數據傳輸過程中，中間人劫持到了數據，此時他的確無法得到瀏覽器生成的密鑰X，這個密鑰本身被公鑰A加密了，只有服務器才有私鑰A’解開它，然而中間人卻完全不需要拿到私鑰A’就能幹壞事了。請看：
- 某網站有用於非對稱加密的公鑰A、私鑰A’。
- 瀏覽器向網站服務器請求，服務器把公鑰A明文給傳輸瀏覽器。
- 中間人劫持到公鑰A，保存下來，把數據包中的公鑰A替換成自己偽造的公鑰B（它當然也擁有公鑰B對應的私鑰B’）。
- 瀏覽器生成一個用於對稱加密的密鑰X，用公鑰B（瀏覽器無法得知公鑰被替換了）加密後傳給服務器。
- 中間人劫持後用私鑰B’解密得到密鑰X，再用公鑰A加密後傳給服務器。
- 服務器拿到後用私鑰A’解密得到密鑰X。
這樣在雙方都不會發現異常的情況下，中間人通過一套“狸貓換太子”的操作，掉包了服務器傳來的公鑰，進而得到了密鑰X。根本原因是瀏覽器無法確認收到的公鑰是不是網站自己的，因為公鑰本身是明文傳輸的，難道還得對公鑰的傳輸進行加密？這似乎變成雞生蛋、蛋生雞的問題了。解法是什麼？
如何證明瀏覽器收到的公鑰一定是該網站的公鑰？
其實所有證明的源頭都是一條或多條不證自明的“公理”（可以回想一下數學上公理），由它推導出一切。比如現實生活中，若想證明某身份證號一定是小明的，可以看他身份證，而身份證是由政府作證的，這裡的“公理”就是“政府機構可信”，這也是社會正常運作的前提。
那能不能類似地有個機構充當互聯網世界的“公理”呢？讓它作為一切證明的源頭，給網站頒發一個“身份證”？
它就是CA機構，它是如今互聯網世界正常運作的前提，而CA機構頒發的“身份證”就是數字證書。
數字證書
“網站在使用HTTPS前，需要向CA機構申領一份數字證書，數字證書裡含有證書持有者信息、公鑰信息等。服務器把證書傳輸給瀏覽器，瀏覽器從證書裡獲取公鑰就行了，證書就如身份證，證明“該公鑰對應該網站”。而這裡又有一個顯而易見的問題，“證書本身的傳輸過程中，如何防止被篡改”？即如何證明證書本身的真實性？身份證運用了一些防偽技術，而數字證書怎麼防偽呢？解決這個問題我們就接近勝利了！
如何放防止數字證書被篡改？
我們把證書原本的內容生成一份“簽名”，比對證書內容和簽名是否一致就能判別是否被篡改。這就是數字證書的“防偽技術”，這裡的“簽名”就叫数字签名：
數字簽名
這部分內容建議看下圖並結合後面的文字理解，圖中左側是數字簽名的製作過程，右側是驗證過程：
數字簽名的製作過程：
- 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請求時都必須在SSL/TLS層進行握手傳輸密鑰嗎？
這也是我當時的困惑之一，顯然每次請求都經歷一次密鑰傳輸過程非常耗時，那怎麼達到只傳輸一次呢？
服務器會為每個瀏覽器（或客戶端軟件）維護一個session ID，在TLS握手階段傳給瀏覽器，瀏覽器生成好密鑰傳給服務器後，服務器會把該密鑰存到相應的session ID下，之後瀏覽器每次請求都會攜帶session ID，服務器會根據session ID找到相應的密鑰並進行解密加密操作，這樣就不必要每次重新製作、傳輸密鑰了！
總結
可以看下這張圖，梳理一下整個流程（SSL、TLS握手有一些區別，不同版本間也有區別，不過大致過程就是這樣）：
Keep Reading...
