HTTPS是怎么保證安全的？

作者：碼工是小希 2021-07-07 12:36:10

網(wǎng)絡(luò) 網(wǎng)絡(luò)管理

HTTPS這并不是應(yīng)用層的一種新協(xié)議。只是HTTP通信接口部分使用SSL(安全套階層)和TLS(安全傳輸層協(xié)議)協(xié)議代替而已。

[[409906]]

本文轉(zhuǎn)載自微信公眾號(hào)「碼工是小希」，作者碼工是小希。轉(zhuǎn)載本文請(qǐng)聯(lián)系碼工是小希公眾號(hào)。

"噔噔噔......"傳來(lái)一陣敲門(mén)聲，把我從睡夢(mèng)中驚醒了。

朦朧間聽(tīng)到有人在說(shuō)活"提莫，在家不?”

“來(lái)了來(lái)了”，推門(mén)一看，原來(lái)是“李青”。

「李青」:自稱(chēng)武術(shù)大師，所有因?yàn)樗察o冥想的舉動(dòng)而掉以輕心敵人都將會(huì)品嘗他燃燒的拳頭和熾烈的回旋踢，人送外號(hào)“盲僧”。

瞧瞧HTTPS

「提莫」：HTTPS這并不是應(yīng)用層的一種新協(xié)議。只是HTTP通信接口部分使用SSL(安全套階層)和TLS(安全傳輸層協(xié)議)協(xié)議代替而已。

HTTP是直接和TCP通信的。如果你用SSL，就變成先和SSL通信，SSL再和TCP通信了。簡(jiǎn)單來(lái)說(shuō)，與SSL組合使用的HTTP被稱(chēng)為HTTPS(超文本傳輸安全協(xié)議)或HTTP over SSL。

你用了SSL，HTTP就有了HTTPS的加密、證書(shū)和完整性保護(hù)這些功能了。SSL是獨(dú)立于HTTP的協(xié)議，所以不光是HTTP協(xié)議，其它運(yùn)行在應(yīng)用層的SMTP和Telnet等協(xié)議也要配合SSL協(xié)議的使用。可以說(shuō)SSL是世界上應(yīng)用最為廣泛的網(wǎng)絡(luò)安全技術(shù)。

步驟1：客戶端通過(guò)發(fā)Client Hello報(bào)文開(kāi)始SSL通信。報(bào)文中包含客戶端支持的SSL的指定版本、加密組件列表(所使用的加密算法及密鑰長(zhǎng)度等)。

步驟2：服務(wù)器可進(jìn)行SSL通信時(shí)，會(huì)以Server Hello報(bào)文作為應(yīng)答。和客戶端一樣，在報(bào)文中包含SSL版本和加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩出來(lái)的。

步驟3：之后服務(wù)器發(fā)送Certificate報(bào)文。報(bào)文中包含公開(kāi)密鑰證書(shū)。

步驟4：最后服務(wù)器發(fā)Server Hello Done報(bào)文通知客戶端，最初階段的SSL握手協(xié)商就結(jié)束了。

步驟5：SSL第一次握手結(jié)束之后，客戶端以Client Key Exchange報(bào)文最為回應(yīng)。報(bào)文中包含通信加密中使用的一種被稱(chēng)作Pre-master secret的隨機(jī)密碼串。該報(bào)文已用步驟3中的公開(kāi)密鑰進(jìn)行加密。

步驟6：接著客戶端繼續(xù)發(fā)送Change Cipher Spec報(bào)文。該報(bào)文會(huì)提示服務(wù)器，在此報(bào)文之后的通信會(huì)采用Pre-master secret密鑰加密。

步驟7：客戶端發(fā)送Finished報(bào)文。該報(bào)文包含連接至今全部報(bào)文的整體效驗(yàn)值。這次握手協(xié)商是否能夠成功，是以服務(wù)器是否能夠正確解密該報(bào)文作為判定標(biāo)準(zhǔn)。

步驟8：服務(wù)器同樣發(fā)送Change Cipher Spec報(bào)文。

步驟9：服務(wù)器同樣發(fā)送Finished報(bào)文。

步驟10：服務(wù)器和客戶端的Finished報(bào)文交換完畢之后，SSL連接就算建立完成，當(dāng)然，通信會(huì)受到SSL的保護(hù)。從此處開(kāi)始進(jìn)行應(yīng)用層協(xié)議的通信，即發(fā)送HTTP請(qǐng)求。

步驟11：應(yīng)用層協(xié)議通信，即發(fā)送HTTP響應(yīng)。

步驟12：最后由客戶端斷開(kāi)連接。斷開(kāi)連接時(shí)，發(fā)送close_notify報(bào)文。上圖做了一些省略，這步之后再發(fā)送TCP FIN報(bào)文來(lái)關(guān)閉與TCP的通信。

在以上流程中，應(yīng)用層發(fā)送數(shù)據(jù)時(shí)會(huì)附加一種叫做MAC(Message Authentication Code)的報(bào)文摘要。MAC能夠知道報(bào)文是否遭到篡改，從而保護(hù)報(bào)文的完整性。

「提莫」：每次發(fā)送真實(shí)數(shù)據(jù)之前，服務(wù)器這邊先生成一把密鑰，接著把密鑰傳給客戶端。后面服務(wù)器給客戶端發(fā)送真實(shí)數(shù)據(jù)的時(shí)候，會(huì)拿這把密鑰對(duì)數(shù)據(jù)加密，客戶端收到加密數(shù)據(jù)之后，用剛才收到的密鑰進(jìn)行解密。當(dāng)然，如果客戶端要給服務(wù)器發(fā)數(shù)據(jù)，也是用這把密鑰來(lái)加密，這里為了方便，我就用單方向傳輸?shù)男问絹?lái)表示。如圖：

「盲僧」：你看哈服務(wù)器是用明文方式傳密鑰給客戶端，然后密鑰被中間人給偷了，那么在之后服務(wù)器和客戶端的加密傳輸過(guò)程中，中間人也可以用他偷的密鑰來(lái)解密啊。這樣的話，加密的數(shù)據(jù)在中間人看來(lái)和明文那沒(méi)啥兩樣了啊。

「提莫」：這種方法是讓客戶端和服務(wù)器都擁有兩把鑰匙，一把鑰匙是公開(kāi)的(全世界都知道都沒(méi)關(guān)系)，我們稱(chēng)之為公鑰;另一把鑰匙則是保密的(只有自己本人才知道)，我們稱(chēng)之為私鑰。當(dāng)然，用公鑰加密的數(shù)據(jù)，只有對(duì)應(yīng)的私鑰才能解密;用私鑰加密的數(shù)據(jù)，只有對(duì)應(yīng)的公鑰才能解密。

這樣，服務(wù)器在給客戶端傳數(shù)據(jù)的過(guò)程中，可以用客戶端明文給他的公鑰進(jìn)行加密，然后客戶端收到后，再用自己的私鑰來(lái)解密。客戶端給服務(wù)器發(fā)送數(shù)據(jù)的時(shí)候也可以采取這種方式。這樣能保持?jǐn)?shù)據(jù)的安全傳輸了。上圖：

「提莫」：就是對(duì)稱(chēng)加密+非對(duì)稱(chēng)加密這兩種方式，我們可以用非對(duì)稱(chēng)加密的方式來(lái)傳輸對(duì)稱(chēng)加密過(guò)程中的密鑰，之后我們就可以采取對(duì)稱(chēng)加密的方式來(lái)傳輸數(shù)據(jù)了呀。具體是這樣子：

服務(wù)器用明文的方式給客戶端發(fā)送自己的公鑰，客戶端收到公鑰之后，會(huì)生成一把密鑰(對(duì)稱(chēng)加密用的)，然后用服務(wù)器的公鑰對(duì)這把密鑰進(jìn)行加密，接著再把密鑰傳給服務(wù)器，服務(wù)器收到后進(jìn)行解密，最后服務(wù)器就可以安全著得到這把密鑰了，而客戶端也有同樣一把的密鑰，他們就可以進(jìn)行對(duì)稱(chēng)加密了，是不是很神奇呀，大師。

「盲僧」：服務(wù)器用明文的方式給客戶端傳輸公鑰的時(shí)候，中間人截取了這本屬于服務(wù)器的公鑰，并且把中間人自己的公鑰冒充服務(wù)器的公鑰傳給了客戶端。

之后客戶端就會(huì)用中間人的公鑰來(lái)加密自己生成的密鑰。然后把被加密的密鑰再傳給服務(wù)器，這個(gè)時(shí)候中間人又把密鑰給截取了，中間人用自己的私鑰對(duì)這把被加密的密鑰進(jìn)行解密，解密后中間人就可以獲得這把密鑰了，這你沒(méi)想到吧!

最后中間人再對(duì)這把密鑰用剛才服務(wù)器的公鑰進(jìn)行加密，再發(fā)給服務(wù)器。如圖：

數(shù)字證書(shū)上場(chǎng)

在剛才的講解中，我們知道了，之所以非對(duì)稱(chēng)加密會(huì)不安全，是因?yàn)榭蛻舳瞬恢肋@把公鑰是不是服務(wù)器的，因此，我們需要找到一種策略來(lái)證明這把公鑰就是服務(wù)器的，而不是別人冒充的。

解決這個(gè)問(wèn)題的方式就是使用數(shù)字證書(shū)，具體是這樣的：

我們需要找到一個(gè)擁有公信力、大家都認(rèn)可的認(rèn)證中心(CA)。

服務(wù)器在給客戶端傳輸公鑰的過(guò)程中，會(huì)把公鑰以及服務(wù)器的個(gè)人信息通過(guò)Hash算法生成信息摘要。如圖:

為了防止信息摘要被人調(diào)換，服務(wù)器還會(huì)用CA提供的私鑰對(duì)信息摘要進(jìn)行加密來(lái)形成數(shù)字簽名。如圖:

并且，最后還會(huì)把原來(lái)沒(méi)Hash算法之前的個(gè)人信息以及公鑰和數(shù)字簽名合并在一起，形成數(shù)字證書(shū)。如圖：

當(dāng)客戶端拿到這份數(shù)字證書(shū)之后，就會(huì)用CA提供的公鑰來(lái)對(duì)數(shù)字證書(shū)里面的數(shù)字簽名進(jìn)行解密來(lái)得到信息摘要，然后對(duì)數(shù)字證書(shū)里服務(wù)器的公鑰以及個(gè)人信息進(jìn)行Hash得到另外一份信息摘要。最后把兩份信息摘要進(jìn)行對(duì)比，如果一樣，則證明這個(gè)人是服務(wù)器，否則那就不是。如圖：

其實(shí)，某些服務(wù)器一開(kāi)始就向認(rèn)證中心申請(qǐng)了這些證書(shū)了(有沒(méi)有看過(guò)沒(méi)有證書(shū)的網(wǎng)站在地址欄會(huì)被標(biāo)出警告?)，而客戶端是，也會(huì)內(nèi)置這些證書(shū)。如圖：