HTTP 與 HTTPS 有哪些區(qū)別？

1. HTTP 是超文本傳輸協(xié)議，信息是明文傳輸，存在安全風(fēng)險(xiǎn)的問(wèn)題。HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP 網(wǎng)絡(luò)層之間加入了 SSL/TLS 安全協(xié)議，使得報(bào)文能夠加密傳輸。
2. HTTP 連接建立相對(duì)簡(jiǎn)單， TCP 三次握手之后便可進(jìn)行 HTTP 的報(bào)文傳輸。而 HTTPS 在 TCP 三次握手之后，還需進(jìn)行 SSL/TLS 的握手過(guò)程，才可進(jìn)入加密報(bào)文傳輸。
3. HTTP 的端口號(hào)是 80，HTTPS 的端口號(hào)是 443。
4. HTTPS 協(xié)議需要向 CA（證書權(quán)威機(jī)構(gòu)）申請(qǐng)數(shù)字證書，來(lái)保證服務(wù)器的身份是可信的。

本文以問(wèn)題的形式逐步展開(kāi)，一步步解開(kāi)HTTPS的面紗，希望能幫助你徹底搞懂HTTPS！

為什么需要加密？

因?yàn)閔ttp的內(nèi)容是明文傳輸?shù)模魑臄?shù)據(jù)會(huì)經(jīng)過(guò)中間代理服務(wù)器、路由器、wifi熱點(diǎn)、通信服務(wù)運(yùn)營(yíng)商等多個(gè)物理節(jié)點(diǎn)，如果信息在傳輸過(guò)程中被劫持，傳輸?shù)膬?nèi)容就完全暴露了。劫持者還可以篡改傳輸?shù)男畔⑶也槐浑p方察覺(jué)，這就是中間人攻擊。所以我們才需要對(duì)信息進(jìn)行加密。最容易理解的就是對(duì)稱加密 。

什么是對(duì)稱加密？

簡(jiǎn)單說(shuō)就是有一個(gè)密鑰，它可以加密一段信息，也可以對(duì)加密后的信息進(jìn)行解密，和我們?nèi)粘Ｉ钪杏玫蔫€匙作用差不多。

用對(duì)稱加密可行嗎？

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

然而最大的問(wèn)題就是這個(gè)密鑰怎么讓傳輸?shù)碾p方知曉，同時(shí)不被別人知道。如果由服務(wù)器生成一個(gè)密鑰并傳輸給瀏覽器，那在這個(gè)傳輸過(guò)程中密鑰被別人劫持到手了怎么辦？之后他就能用密鑰解開(kāi)雙方傳輸?shù)娜魏蝺?nèi)容了，所以這么做當(dāng)然不行。

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

什么是非對(duì)稱加密？

簡(jiǎn)單說(shuō)就是有兩把密鑰，通常一把叫做公鑰、一把叫私鑰，用公鑰加密的內(nèi)容必須用私鑰才能解開(kāi)，同樣，私鑰加密的內(nèi)容只有公鑰能解開(kāi)。

用非對(duì)稱加密可行嗎？

鑒于非對(duì)稱加密的機(jī)制，我們可能會(huì)有這種思路：服務(wù)器先把公鑰以明文方式傳輸給瀏覽器，之后瀏覽器向服務(wù)器傳數(shù)據(jù)前都先用這個(gè)公鑰加密好再傳，這條數(shù)據(jù)的安全似乎可以保障了！因?yàn)橹挥蟹?wù)器有相應(yīng)的私鑰能解開(kāi)公鑰加密的數(shù)據(jù)。

然而反過(guò)來(lái)由服務(wù)器到瀏覽器的這條路怎么保障安全？如果服務(wù)器用它的私鑰加密數(shù)據(jù)傳給瀏覽器，那么瀏覽器用公鑰可以解密它，而這個(gè)公鑰是一開(kāi)始通過(guò)明文傳輸給瀏覽器的，若這個(gè)公鑰被中間人劫持到了，那他也能用該公鑰解密服務(wù)器傳來(lái)的信息了。所以目前似乎只能保證由瀏覽器向服務(wù)器傳輸數(shù)據(jù)的安全性（其實(shí)仍有漏洞，下文會(huì)說(shuō)），那利用這點(diǎn)你能想到什么解決方案嗎？

改良的非對(duì)稱加密方案，似乎可以？

我們已經(jīng)理解通過(guò)一組公鑰私鑰，可以保證單個(gè)方向傳輸?shù)陌踩裕怯脙山M公鑰私鑰，是否就能保證雙向傳輸都安全了？請(qǐng)看下面的過(guò)程：

1. 某網(wǎng)站服務(wù)器擁有公鑰A與對(duì)應(yīng)的私鑰A’；瀏覽器擁有公鑰B與對(duì)應(yīng)的私鑰B’。
2. 瀏覽器把公鑰B明文傳輸給服務(wù)器。
3. 服務(wù)器把公鑰A明文給傳輸瀏覽器。
4. 之后瀏覽器向服務(wù)器傳輸?shù)膬?nèi)容都用公鑰A加密，服務(wù)器收到后用私鑰A’解密。由于只有服務(wù)器擁有私鑰A’，所以能保證這條數(shù)據(jù)的安全。
5. 同理，服務(wù)器向?yàn)g覽器傳輸?shù)膬?nèi)容都用公鑰B加密，瀏覽器收到后用私鑰B’解密。同上也可以保證這條數(shù)據(jù)的安全。

的確可以！拋開(kāi)這里面仍有的漏洞不談（下文會(huì)講），HTTPS的加密卻沒(méi)使用這種方案，為什么？很重要的原因是非對(duì)稱加密算法非常耗時(shí)，而對(duì)稱加密快很多。那我們能不能運(yùn)用非對(duì)稱加密的特性解決前面提到的對(duì)稱加密的漏洞？

非對(duì)稱加密+對(duì)稱加密？

既然非對(duì)稱加密耗時(shí)，那非對(duì)稱加密+對(duì)稱加密結(jié)合可以嗎？而且得盡量減少非對(duì)稱加密的次數(shù)。當(dāng)然是可以的，且非對(duì)稱加密、解密各只需用一次即可。
請(qǐng)看一下這個(gè)過(guò)程：

1. 某網(wǎng)站擁有用于非對(duì)稱加密的公鑰A、私鑰A’。
2. 瀏覽器向網(wǎng)站服務(wù)器請(qǐng)求，服務(wù)器把公鑰A明文給傳輸瀏覽器。
3. 瀏覽器隨機(jī)生成一個(gè)用于對(duì)稱加密的密鑰X，用公鑰A加密后傳給服務(wù)器。
4. 服務(wù)器拿到后用私鑰A’解密得到密鑰X。
5. 這樣雙方就都擁有密鑰X了，且別人無(wú)法知道它。之后雙方所有數(shù)據(jù)都通過(guò)密鑰X加密解密即可。

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

中間人攻擊

中間人攻擊（https://blog.pradeo.com/man-in-the-middle-attack）

如果在數(shù)據(jù)傳輸過(guò)程中，中間人劫持到了數(shù)據(jù)，此時(shí)他的確無(wú)法得到瀏覽器生成的密鑰X，這個(gè)密鑰本身被公鑰A加密了，只有服務(wù)器才有私鑰A’解開(kāi)它，然而中間人卻完全不需要拿到私鑰A’就能干壞事了。請(qǐng)看：

1. 某網(wǎng)站有用于非對(duì)稱加密的公鑰A、私鑰A’。
2. 瀏覽器向網(wǎng)站服務(wù)器請(qǐng)求，服務(wù)器把公鑰A明文給傳輸瀏覽器。
3. 中間人劫持到公鑰A，保存下來(lái)，把數(shù)據(jù)包中的公鑰A替換成自己偽造的公鑰B（它當(dāng)然也擁有公鑰B對(duì)應(yīng)的私鑰B’）。
4. 瀏覽器生成一個(gè)用于對(duì)稱加密的密鑰X，用公鑰B（瀏覽器無(wú)法得知公鑰被替換了）加密后傳給服務(wù)器。
5. 中間人劫持后用私鑰B’解密得到密鑰X，再用公鑰A加密后傳給服務(wù)器。
6. 服務(wù)器拿到后用私鑰A’解密得到密鑰X。

這樣在雙方都不會(huì)發(fā)現(xiàn)異常的情況下，中間人通過(guò)一套“貍貓換太子”的操作，掉包了服務(wù)器傳來(lái)的公鑰，進(jìn)而得到了密鑰X。根本原因是瀏覽器無(wú)法確認(rèn)收到的公鑰是不是網(wǎng)站自己的，因?yàn)楣€本身是明文傳輸?shù)模y道還得對(duì)公鑰的傳輸進(jìn)行加密？這似乎變成雞生蛋、蛋生雞的問(wèn)題了。解法是什么？

如何證明瀏覽器收到的公鑰一定是該網(wǎng)站的公鑰？

其實(shí)所有證明的源頭都是一條或多條不證自明的“公理”（可以回想一下數(shù)學(xué)上公理），由它推導(dǎo)出一切。比如現(xiàn)實(shí)生活中，若想證明某身份證號(hào)一定是小明的，可以看他身份證，而身份證是由政府作證的，這里的“公理”就是“政府機(jī)構(gòu)可信”，這也是社會(huì)正常運(yùn)作的前提。

那能不能類似地有個(gè)機(jī)構(gòu)充當(dāng)互聯(lián)網(wǎng)世界的“公理”呢？讓它作為一切證明的源頭，給網(wǎng)站頒發(fā)一個(gè)“身份證”？

它就是CA機(jī)構(gòu)，它是如今互聯(lián)網(wǎng)世界正常運(yùn)作的前提，而CA機(jī)構(gòu)頒發(fā)的“身份證”就是數(shù)字證書。

數(shù)字證書

網(wǎng)站在使用HTTPS前，需要向CA機(jī)構(gòu)申領(lǐng)一份數(shù)字證書，數(shù)字證書里含有證書持有者信息、公鑰信息等。服務(wù)器把證書傳輸給瀏覽器，瀏覽器從證書里獲取公鑰就行了，證書就如身份證，證明“該公鑰對(duì)應(yīng)該網(wǎng)站”。而這里又有一個(gè)顯而易見(jiàn)的問(wèn)題，“證書本身的傳輸過(guò)程中，如何防止被篡改”？即如何證明證書本身的真實(shí)性？身份證運(yùn)用了一些防偽技術(shù)，而數(shù)字證書怎么防偽呢？解決這個(gè)問(wèn)題我們就接近勝利了！

如何防止數(shù)字證書被篡改？

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

數(shù)字簽名

這部分內(nèi)容建議看下圖并結(jié)合后面的文字理解，圖中左側(cè)是數(shù)字簽名的制作過(guò)程，右側(cè)是驗(yàn)證過(guò)程：

數(shù)字簽名的制作過(guò)程：

1. CA機(jī)構(gòu)擁有非對(duì)稱加密的私鑰和公鑰。
2. CA機(jī)構(gòu)對(duì)證書明文數(shù)據(jù)T進(jìn)行hash。
3. 對(duì)hash后的值用私鑰加密，得到數(shù)字簽名S。

明文和數(shù)字簽名共同組成了數(shù)字證書，這樣一份數(shù)字證書就可以頒發(fā)給網(wǎng)站了。那瀏覽器拿到服務(wù)器傳來(lái)的數(shù)字證書后，如何驗(yàn)證它是不是真的？（有沒(méi)有被篡改、掉包）

瀏覽器驗(yàn)證過(guò)程：

1. 拿到證書，得到明文T，簽名S。
2. 用CA機(jī)構(gòu)的公鑰對(duì)S解密（由于是瀏覽器信任的機(jī)構(gòu)，所以瀏覽器保有它的公鑰。詳情見(jiàn)下文），得到S’。
3. 用證書里指明的hash算法對(duì)明文T進(jìn)行hash得到T’。
4. 顯然通過(guò)以上步驟，T’應(yīng)當(dāng)?shù)扔赟‘，除非明文或簽名被篡改。所以此時(shí)比較S’是否等于T’，等于則表明證書可信。

為何么這樣可以保證證書可信呢？我們來(lái)仔細(xì)想一下。

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

假設(shè)中間人篡改了證書的原文，由于他沒(méi)有CA機(jī)構(gòu)的私鑰，所以無(wú)法得到此時(shí)加密后簽名，無(wú)法相應(yīng)地篡改簽名。瀏覽器收到該證書后會(huì)發(fā)現(xiàn)原文和簽名解密后的值不一致，則說(shuō)明證書已被篡改，證書不可信，從而終止向服務(wù)器傳輸信息，防止信息泄露給中間人。

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

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

假設(shè)有另一個(gè)網(wǎng)站B也拿到了CA機(jī)構(gòu)認(rèn)證的證書，它想劫持網(wǎng)站A的信息。于是它成為中間人攔截到了A傳給瀏覽器的證書，然后替換成自己的證書，傳給瀏覽器，之后瀏覽器就會(huì)錯(cuò)誤地拿到B的證書里的公鑰了，這確實(shí)會(huì)導(dǎo)致上文“中間人攻擊”那里提到的漏洞？

其實(shí)這并不會(huì)發(fā)生，因?yàn)樽C書里包含了網(wǎng)站A的信息，包括域名，瀏覽器把證書里的域名與自己請(qǐng)求的域名比對(duì)一下就知道有沒(méi)有被掉包了。

為什么制作數(shù)字簽名時(shí)需要hash一次？

我初識(shí)HTTPS的時(shí)候就有這個(gè)疑問(wèn)，因?yàn)樗坪跄抢锏膆ash有點(diǎn)多余，把hash過(guò)程去掉也能保證證書沒(méi)有被篡改。

最顯然的是性能問(wèn)題，前面我們已經(jīng)說(shuō)了非對(duì)稱加密效率較差，證書信息一般較長(zhǎng)，比較耗時(shí)。而hash后得到的是固定長(zhǎng)度的信息（比如用md5算法hash后可以得到固定的128位的值），這樣加解密就快很多。

當(dāng)然也有安全上的原因，這部分內(nèi)容相對(duì)深一些，感興趣的可以看這篇解答：
crypto.stackexchange.com/a/12780

怎么證明CA機(jī)構(gòu)的公鑰是可信的？

你們可能會(huì)發(fā)現(xiàn)上文中說(shuō)到CA機(jī)構(gòu)的公鑰，我?guī)缀跻还P帶過(guò)，“瀏覽器保有它的公鑰”，這是個(gè)什么保有法？怎么證明這個(gè)公鑰是否可信？

讓我們回想一下數(shù)字證書到底是干啥的？沒(méi)錯(cuò)，為了證明某公鑰是可信的，即“該公鑰是否對(duì)應(yīng)該網(wǎng)站”，那CA機(jī)構(gòu)的公鑰是否也可以用數(shù)字證書來(lái)證明？沒(méi)錯(cuò)，操作系統(tǒng)、瀏覽器本身會(huì)預(yù)裝一些它們信任的根證書，如果其中會(huì)有CA機(jī)構(gòu)的根證書，這樣就可以拿到它對(duì)應(yīng)的可信公鑰了。

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

另外，不知你們是否遇到過(guò)網(wǎng)站訪問(wèn)不了、提示需安裝證書的情況？這里安裝的就是根證書。說(shuō)明瀏覽器不認(rèn)給這個(gè)網(wǎng)站頒發(fā)證書的機(jī)構(gòu)，那么你就得手動(dòng)下載安裝該機(jī)構(gòu)的根證書（風(fēng)險(xiǎn)自己承擔(dān)XD）。安裝后，你就有了它的公鑰，就可以用它驗(yàn)證服務(wù)器發(fā)來(lái)的證書是否可信了。

每次進(jìn)行HTTPS請(qǐng)求時(shí)都必須在SSL/TLS層進(jìn)行握手傳輸密鑰嗎？

這也是我當(dāng)時(shí)的困惑之一，顯然每次請(qǐng)求都經(jīng)歷一次密鑰傳輸過(guò)程非常耗時(shí)，那怎么達(dá)到只傳輸一次呢？

服務(wù)器會(huì)為每個(gè)瀏覽器（或客戶端軟件）維護(hù)一個(gè)session ID，在TLS握手階段傳給瀏覽器，瀏覽器生成好密鑰傳給服務(wù)器后，服務(wù)器會(huì)把該密鑰存到相應(yīng)的session ID下，之后瀏覽器每次請(qǐng)求都會(huì)攜帶session ID，服務(wù)器會(huì)根據(jù)session ID找到相應(yīng)的密鑰并進(jìn)行解密加密操作，這樣就不必要每次重新制作、傳輸密鑰了！

總結(jié)

整個(gè)非對(duì)稱加密過(guò)程都是為了最后的對(duì)稱加密服務(wù)的，最終目的是證明證書中的公鑰是安全且未篡改。使用公鑰來(lái)加密一個(gè)秘鑰，并把秘鑰傳給后端，后端使用私鑰解密秘鑰，這樣兩端都擁有同一個(gè)秘鑰，從而進(jìn)行對(duì)稱加密。所以私鑰是絕對(duì)不能泄漏的，不然完蛋。

可以看下這張圖，梳理一下整個(gè)流程（SSL、TLS握手有一些區(qū)別，不同版本間也有區(qū)別，不過(guò)大致過(guò)程就是這樣）：

SSL/TLS 協(xié)議基本流程：

• 客戶端向服務(wù)器索要并驗(yàn)證服務(wù)器的公鑰。
• 雙方協(xié)商生產(chǎn)「會(huì)話秘鑰」。
• 雙方采用「會(huì)話秘鑰」進(jìn)行加密通信。