本文以問題的形式逐步展開，一步步解開HTTPS的面紗，希望能幫助你徹底搞懂HTTPS！
(資料圖片)
因為http的內容是明文傳輸?shù)?，明文?shù)據(jù)會經(jīng)過中間代理服務器、路由器、wifi熱點、通信服務運營商等多個物理節(jié)點，如果信息在傳輸過程中被劫持，傳輸?shù)膬热菥屯耆┞读?。劫持者還可以篡改傳輸?shù)男畔⑶也槐浑p方察覺，這就是中間人攻擊。所以我們才需要對信息進行加密。最容易理解的就是對稱加密。
什么是對稱加密？簡單說就是有一個密鑰，它可以加密一段信息，也可以對加密后的信息進行解密，和我們日常生活中用的鑰匙作用差不多。
用對稱加密可行嗎？如果通信雙方都各自持有同一個密鑰，且沒有別人知道，這兩方的通信安全當然是可以被保證的（除非密鑰被破解）。
然而最大的問題就是這個密鑰怎么讓傳輸?shù)碾p方知曉，同時不被別人知道。如果由服務器生成一個密鑰并傳輸給瀏覽器，那在這個傳輸過程中密鑰被別人劫持到手了怎么辦？之后他就能用密鑰解開雙方傳輸?shù)娜魏蝺热萘?，所以這么做當然不行。
換種思路？試想一下，如果瀏覽器內部就預存了網(wǎng)站A的密鑰，且可以確保除了瀏覽器和網(wǎng)站A，不會有任何外人知道該密鑰，那理論上用對稱加密是可以的，這樣瀏覽器只要預存好世界上所有HTTPS網(wǎng)站的密鑰就行了！這么做顯然不現(xiàn)實。怎么辦？所以我們就需要非對稱加密。
什么是非對稱加密？簡單說就是有兩把密鑰，通常一把叫做公鑰、一把叫私鑰，用公鑰加密的內容必須用私鑰才能解開，同樣，私鑰加密的內容只有公鑰能解開。
用非對稱加密可行嗎？鑒于非對稱加密的機制，我們可能會有這種思路：服務器先把公鑰以明文方式傳輸給瀏覽器，之后瀏覽器向服務器傳數(shù)據(jù)前都先用這個公鑰加密好再傳，這條數(shù)據(jù)的安全似乎可以保障了！因為只有服務器有相應的私鑰能解開公鑰加密的數(shù)據(jù)。
然而反過來由服務器到瀏覽器的這條路怎么保障安全？如果服務器用它的私鑰加密數(shù)據(jù)傳給瀏覽器，那么瀏覽器用公鑰可以解密它，而這個公鑰是一開始通過明文傳輸給瀏覽器的，若這個公鑰被中間人劫持到了，那他也能用該公鑰解密服務器傳來的信息了。所以目前似乎只能保證由瀏覽器向服務器傳輸數(shù)據(jù)的安全性（其實仍有漏洞，下文會說），那利用這點你能想到什么解決方案嗎？
改良的非對稱加密方案，似乎可以？我們已經(jīng)理解通過一組公鑰私鑰，可以保證單個方向傳輸?shù)陌踩?，那用兩組公鑰私鑰，是否就能保證雙向傳輸都安全了？請看下面的過程：
某網(wǎng)站服務器擁有公鑰A與對應的私鑰A’；瀏覽器擁有公鑰B與對應的私鑰B’。瀏覽器把公鑰B明文傳輸給服務器。服務器把公鑰A明文給傳輸瀏覽器。之后瀏覽器向服務器傳輸?shù)膬热荻加霉€A加密，服務器收到后用私鑰A’解密。由于只有服務器擁有私鑰A’，所以能保證這條數(shù)據(jù)的安全。同理，服務器向瀏覽器傳輸?shù)膬热荻加霉€B加密，瀏覽器收到后用私鑰B’解密。同上也可以保證這條數(shù)據(jù)的安全。的確可以！拋開這里面仍有的漏洞不談（下文會講），HTTPS的加密卻沒使用這種方案，為什么？很重要的原因是非對稱加密算法非常耗時，而對稱加密快很多。那我們能不能運用非對稱加密的特性解決前面提到的對稱加密的漏洞？
非對稱加密+對稱加密？既然非對稱加密耗時，那非對稱加密+對稱加密結合可以嗎？而且得盡量減少非對稱加密的次數(shù)。當然是可以的，且非對稱加密、解密各只需用一次即可。請看一下這個過程：
某網(wǎng)站擁有用于非對稱加密的公鑰A、私鑰A’。瀏覽器向網(wǎng)站服務器請求，服務器把公鑰A明文給傳輸瀏覽器。瀏覽器隨機生成一個用于對稱加密的密鑰X，用公鑰A加密后傳給服務器。服務器拿到后用私鑰A’解密得到密鑰X。這樣雙方就都擁有密鑰X了，且別人無法知道它。之后雙方所有數(shù)據(jù)都通過密鑰X加密解密即可。完美！HTTPS基本就是采用了這種方案。完美？還是有漏洞的。
中間人攻擊中間人攻擊（https://blog.pradeo.com/man-in-the-middle-attack）
如果在數(shù)據(jù)傳輸過程中，中間人劫持到了數(shù)據(jù)，此時他的確無法得到瀏覽器生成的密鑰X，這個密鑰本身被公鑰A加密了，只有服務器才有私鑰A’解開它，然而中間人卻完全不需要拿到私鑰A’就能干壞事了。請看：
某網(wǎng)站有用于非對稱加密的公鑰A、私鑰A’。瀏覽器向網(wǎng)站服務器請求，服務器把公鑰A明文給傳輸瀏覽器。中間人劫持到公鑰A，保存下來，把數(shù)據(jù)包中的公鑰A替換成自己偽造的公鑰B（它當然也擁有公鑰B對應的私鑰B’）。瀏覽器生成一個用于對稱加密的密鑰X，用公鑰B（瀏覽器無法得知公鑰被替換了）加密后傳給服務器。中間人劫持后用私鑰B’解密得到密鑰X，再用公鑰A加密后傳給服務器。服務器拿到后用私鑰A’解密得到密鑰X。這樣在雙方都不會發(fā)現(xiàn)異常的情況下，中間人通過一套“貍貓換太子”的操作，掉包了服務器傳來的公鑰，進而得到了密鑰X。根本原因是瀏覽器無法確認收到的公鑰是不是網(wǎng)站自己的，因為公鑰本身是明文傳輸?shù)?，難道還得對公鑰的傳輸進行加密？這似乎變成雞生蛋、蛋生雞的問題了。解法是什么？
如何證明瀏覽器收到的公鑰一定是該網(wǎng)站的公鑰？其實所有證明的源頭都是一條或多條不證自明的“公理”（可以回想一下數(shù)學上公理），由它推導出一切。比如現(xiàn)實生活中，若想證明某身份證號一定是小明的，可以看他身份證，而身份證是由政府作證的，這里的“公理”就是“政府機構可信”，這也是社會正常運作的前提。
那能不能類似地有個機構充當互聯(lián)網(wǎng)世界的“公理”呢？讓它作為一切證明的源頭，給網(wǎng)站頒發(fā)一個“身份證”？
它就是CA機構，它是如今互聯(lián)網(wǎng)世界正常運作的前提，而CA機構頒發(fā)的“身份證”就是數(shù)字證書。
數(shù)字證書網(wǎng)站在使用HTTPS前，需要向CA機構申領一份數(shù)字證書，數(shù)字證書里含有證書持有者信息、公鑰信息等。服務器把證書傳輸給瀏覽器，瀏覽器從證書里獲取公鑰就行了，證書就如身份證，證明“該公鑰對應該網(wǎng)站”。而這里又有一個顯而易見的問題，“證書本身的傳輸過程中，如何防止被篡改”？即如何證明證書本身的真實性？身份證運用了一些防偽技術，而數(shù)字證書怎么防偽呢？解決這個問題我們就接近勝利了！
如何放防止數(shù)字證書被篡改？我們把證書原本的內容生成一份“簽名”，比對證書內容和簽名是否一致就能判別是否被篡改。這就是數(shù)字證書的“防偽技術”，這里的“簽名”就叫數(shù)字簽名：
數(shù)字簽名這部分內容建議看下圖并結合后面的文字理解，圖中左側是數(shù)字簽名的制作過程，右側是驗證過程：
數(shù)字簽名的制作過程：
CA機構擁有非對稱加密的私鑰和公鑰。CA機構對證書明文數(shù)據(jù)T進行hash。對hash后的值用私鑰加密，得到數(shù)字簽名S。明文和數(shù)字簽名共同組成了數(shù)字證書，這樣一份數(shù)字證書就可以頒發(fā)給網(wǎng)站了。那瀏覽器拿到服務器傳來的數(shù)字證書后，如何驗證它是不是真的？（有沒有被篡改、掉包）
瀏覽器驗證過程：
拿到證書，得到明文T，簽名S。用CA機構的公鑰對S解密（由于是瀏覽器信任的機構，所以瀏覽器保有它的公鑰。詳情見下文），得到S’。用證書里指明的hash算法對明文T進行hash得到T’。顯然通過以上步驟，T’應當?shù)扔赟‘，除非明文或簽名被篡改。所以此時比較S’是否等于T’，等于則表明證書可信。為何么這樣可以保證證書可信呢？我們來仔細想一下。
中間人有可能篡改該證書嗎？假設中間人篡改了證書的原文，由于他沒有CA機構的私鑰，所以無法得到此時加密后簽名，無法相應地篡改簽名。瀏覽器收到該證書后會發(fā)現(xiàn)原文和簽名解密后的值不一致，則說明證書已被篡改，證書不可信，從而終止向服務器傳輸信息，防止信息泄露給中間人。
既然不可能篡改，那整個證書被掉包呢？
中間人有可能把證書掉包嗎？假設有另一個網(wǎng)站B也拿到了CA機構認證的證書，它想劫持網(wǎng)站A的信息。于是它成為中間人攔截到了A傳給瀏覽器的證書，然后替換成自己的證書，傳給瀏覽器，之后瀏覽器就會錯誤地拿到B的證書里的公鑰了，這確實會導致上文“中間人攻擊”那里提到的漏洞？
其實這并不會發(fā)生，因為證書里包含了網(wǎng)站A的信息，包括域名，瀏覽器把證書里的域名與自己請求的域名比對一下就知道有沒有被掉包了。
為什么制作數(shù)字簽名時需要hash一次？我初識HTTPS的時候就有這個疑問，因為似乎那里的hash有點多余，把hash過程去掉也能保證證書沒有被篡改。
最顯然的是性能問題，前面我們已經(jīng)說了非對稱加密效率較差，證書信息一般較長，比較耗時。而hash后得到的是固定長度的信息（比如用md5算法hash后可以得到固定的128位的值），這樣加解密就快很多。
當然也有安全上的原因，這部分內容相對深一些，感興趣的可以看這篇解答：crypto.stackexchange.com/a/12780
怎么證明CA機構的公鑰是可信的？你們可能會發(fā)現(xiàn)上文中說到CA機構的公鑰，我?guī)缀跻还P帶過，“瀏覽器保有它的公鑰”，這是個什么保有法？怎么證明這個公鑰是否可信？
讓我們回想一下數(shù)字證書到底是干啥的？沒錯，為了證明某公鑰是可信的，即“該公鑰是否對應該網(wǎng)站”，那CA機構的公鑰是否也可以用數(shù)字證書來證明？沒錯，操作系統(tǒng)、瀏覽器本身會預裝一些它們信任的根證書，如果其中會有CA機構的根證書，這樣就可以拿到它對應的可信公鑰了。
實際上證書之間的認證也可以不止一層，可以A信任B，B信任C，以此類推，我們把它叫做信任鏈或數(shù)字證書鏈。也就是一連串的數(shù)字證書，由根證書為起點，透過層層信任，使終端實體證書的持有者可以獲得轉授的信任，以證明身份。
另外，不知你們是否遇到過網(wǎng)站訪問不了、提示需安裝證書的情況？這里安裝的就是根證書。說明瀏覽器不認給這個網(wǎng)站頒發(fā)證書的機構，那么你就得手動下載安裝該機構的根證書（風險自己承擔XD）。安裝后，你就有了它的公鑰，就可以用它驗證服務器發(fā)來的證書是否可信了。
每次進行HTTPS請求時都必須在SSL/TLS層進行握手傳輸密鑰嗎？這也是我當時的困惑之一，顯然每次請求都經(jīng)歷一次密鑰傳輸過程非常耗時，那怎么達到只傳輸一次呢？
服務器會為每個瀏覽器（或客戶端軟件）維護一個session ID，在TLS握手階段傳給瀏覽器，瀏覽器生成好密鑰傳給服務器后，服務器會把該密鑰存到相應的session ID下，之后瀏覽器每次請求都會攜帶session ID，服務器會根據(jù)session ID找到相應的密鑰并進行解密加密操作，這樣就不必要每次重新制作、傳輸密鑰了！
總結整個非對稱加密過程都是為了最后的對稱加密服務的，最終目的是證明證書中的公鑰是安全且未篡改。使用公鑰來加密一個秘鑰，并把秘鑰傳給后端，后端使用私鑰解密秘鑰，這樣兩端都擁有同一個秘鑰，從而進行對稱加密。所以私鑰是絕對不能泄漏的，不然完蛋。
可以看下這張圖，梳理一下整個流程（SSL、TLS握手有一些區(qū)別，不同版本間也有區(qū)別，不過大致過程就是這樣）：
SSL/TLS 協(xié)議基本流程：
客戶端向服務器索要并驗證服務器的公鑰。雙方協(xié)商生產「會話秘鑰」。雙方采用「會話秘鑰」進行加密通信。標簽：
