??"Echo"??
作者:Mylvzi
文章主要內(nèi)容:網(wǎng)絡(luò)原理(5)–HTTPS是如何進(jìn)行加密的
在網(wǎng)絡(luò)原理(4)中介紹了HTTP協(xié)議的相關(guān)內(nèi)容,HTTP協(xié)議在傳輸?shù)倪^(guò)程中存在著安全問(wèn)題,實(shí)際上現(xiàn)在的網(wǎng)絡(luò)中基本不再使用HTTP,而是使用一種更加安全的協(xié)議HTTPS
一.前言
HTTPS是基于HTTP,之前學(xué)習(xí)過(guò)的有關(guān)HTTP協(xié)議的相關(guān)內(nèi)容在HTTPS上都是同樣適用的,HTTPS是在HTTP的基礎(chǔ)之上引入了加密機(jī)制
之所以會(huì)有HTTPS的出現(xiàn),主要還是因?yàn)镠TTP協(xié)議在傳輸?shù)倪^(guò)程中遇到了安全問(wèn)題,比如隨便連接公共WiFi就有可能導(dǎo)致數(shù)據(jù)的丟失,黑客可以對(duì)公共WIFI所在的路由器進(jìn)行抓包分析,獲得你上網(wǎng)的一些相關(guān)信息(比如支付寶密碼),甚至說(shuō)黑客都可以偽裝成公共WiFi的路由器
如果一些敏感數(shù)據(jù)不進(jìn)行加密,就相當(dāng)于數(shù)據(jù)在網(wǎng)絡(luò)中裸奔傳輸,被黑客獲取到就會(huì)帶來(lái)風(fēng)險(xiǎn).實(shí)際上,像支付寶密碼這樣的敏感數(shù)據(jù),支付寶的官方都是進(jìn)行了加密,黑客拿到的數(shù)據(jù)是加密過(guò)后的密文,黑客無(wú)法進(jìn)行解密~
為了解決HTTP在傳輸過(guò)程中的不安全性,HTTPS中就引入了加密機(jī)制,保證數(shù)據(jù)在傳輸?shù)倪^(guò)程中不是裸奔傳輸
二.HTTPS的加密機(jī)制
1.基本概念
要了解HTTPS的加密機(jī)制,需要先了解是哪個(gè)基本概念:密文,明文,密鑰
明文:要傳輸?shù)脑紨?shù)據(jù),比如你要發(fā)送"你好",你好這兩個(gè)字就是明文
密鑰:對(duì)明文加密,對(duì)密文解密的工具
密文:對(duì)明文進(jìn)行密鑰加密過(guò)后的數(shù)據(jù) 比如將原始數(shù)據(jù)"你好"加密為"nh","nh"就是密文,傳輸過(guò)程中密文在網(wǎng)絡(luò)中進(jìn)行傳輸
明文 + 密鑰 => 密文
密文 + 密鑰 =>明文
2.加密機(jī)制
HTTPS中進(jìn)行加密的機(jī)制主要有兩種:對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密
1.對(duì)稱(chēng)加密
對(duì)稱(chēng)加密就是在加密的過(guò)程中使用同一把密鑰進(jìn)行加密解密的過(guò)程
假設(shè)密鑰是 key
,那么;
明文 + key => 密文
密文 + 可以=> 明文
2.非對(duì)稱(chēng)加密
非對(duì)稱(chēng)加密就是在加密的過(guò)程中使用兩把不同的密鑰進(jìn)行加密解密的過(guò)程,一把被稱(chēng)為公鑰(可以被公開(kāi)出來(lái)的),一把被稱(chēng)為私鑰(自己?jiǎn)为?dú)享有的),使用那一把加密/解密都是相同的,比如假設(shè)公鑰是key1
,私鑰是key2
,使用公鑰進(jìn)行加密,使用私鑰進(jìn)行解密
明文 + key1 => 密文
密文 + key2 => 明文
三.HTTPS的加密機(jī)制的工作過(guò)程
HTTPS的加密主要是對(duì)HTTP報(bào)文中的頭部和body進(jìn)行加密
1.對(duì)稱(chēng)加密
對(duì)稱(chēng)加密在加密解密的過(guò)程中使用的是同一把密鑰進(jìn)行加密解密
加密的具體過(guò)程如下:
- 客戶(hù)端產(chǎn)生一個(gè)明文請(qǐng)求,使用產(chǎn)生的對(duì)稱(chēng)密鑰對(duì)明文請(qǐng)求進(jìn)行加密,得到密文請(qǐng)求
- 客戶(hù)端將產(chǎn)生的密文請(qǐng)求經(jīng)運(yùn)營(yíng)商路由器傳輸給服務(wù)器
- 服務(wù)器得到密文請(qǐng)求,使用相同的對(duì)稱(chēng)密鑰進(jìn)行解密,得到原始的明文請(qǐng)求
想一個(gè)問(wèn)題,服務(wù)器不是只和一個(gè)客戶(hù)端進(jìn)行通信,是和很多客戶(hù)端進(jìn)行通信,每一個(gè)客戶(hù)端的對(duì)稱(chēng)密鑰是否都相同呢?肯定是不同的,如果相同,黑客就可以作為客戶(hù)端得到對(duì)稱(chēng)密鑰,就可以利用這個(gè)對(duì)稱(chēng)密鑰進(jìn)行解密了
實(shí)際上,對(duì)稱(chēng)密鑰是客戶(hù)端再和服務(wù)器連接時(shí)就要提前產(chǎn)生的,這個(gè)對(duì)稱(chēng)密鑰利用隨機(jī)數(shù)的相關(guān)機(jī)制產(chǎn)生,保證每個(gè)客戶(hù)端的對(duì)稱(chēng)密鑰都不相同
上述機(jī)制真的沒(méi)有問(wèn)題么?其實(shí)存在一個(gè)致命缺陷,對(duì)稱(chēng)密鑰是通過(guò)客戶(hù)端利用隨機(jī)數(shù)機(jī)制產(chǎn)生的,服務(wù)器也要持有相同的對(duì)稱(chēng)密鑰,客戶(hù)端通過(guò)網(wǎng)絡(luò)傳輸
傳輸給服務(wù)器,黑客就可能把對(duì)稱(chēng)密鑰也給截獲,就可以利用截獲的密鑰進(jìn)行解密,此時(shí)不就加密了個(gè)寂寞么?
有人可能會(huì)說(shuō),那我就對(duì)產(chǎn)生的對(duì)稱(chēng)密鑰進(jìn)行加密不就行了么?但是對(duì)對(duì)稱(chēng)密鑰加密的密鑰不也得通過(guò)網(wǎng)絡(luò)傳輸給服務(wù)器么?這個(gè)方法肯定是行不通的,再仔細(xì)想想,對(duì)稱(chēng)加密存在安全問(wèn)題的關(guān)鍵在于對(duì)稱(chēng)密鑰是赤裸裸的在網(wǎng)絡(luò)中進(jìn)行傳輸?shù)?/strong>,密鑰就像是秘密,秘密很關(guān)鍵,很重要,所以應(yīng)該自己持有,不應(yīng)該公布出去,這樣的密鑰就是私鑰,這也是非對(duì)稱(chēng)加密的關(guān)鍵!
2.非對(duì)稱(chēng)加密
非對(duì)稱(chēng)加密在加密解密的過(guò)程中使用的是一套密鑰,公鑰和私鑰進(jìn)行加密解密
公鑰私鑰由服務(wù)器產(chǎn)生,公鑰通過(guò)網(wǎng)絡(luò)傳輸給客戶(hù)端,私鑰只有服務(wù)器自己持有,不在網(wǎng)絡(luò)中進(jìn)行傳輸,此時(shí)就可以使用公鑰進(jìn)行加密,使用私鑰解密
加密的具體過(guò)程如下:
- 服務(wù)器產(chǎn)生一套密鑰 公鑰+私鑰 通過(guò)網(wǎng)絡(luò)將公鑰傳輸給客戶(hù)端,私鑰自己持有
- 客戶(hù)端產(chǎn)生明文請(qǐng)求和對(duì)稱(chēng)密鑰,使用公鑰對(duì)對(duì)稱(chēng)密鑰加密,使用對(duì)稱(chēng)密鑰對(duì)明文請(qǐng)求進(jìn)行加密–>得到密文請(qǐng)求
- 客戶(hù)端將產(chǎn)生的密文請(qǐng)求經(jīng)運(yùn)營(yíng)商路由器傳輸給服務(wù)器
- 服務(wù)器收到密文請(qǐng)求,首先使用私鑰對(duì)對(duì)稱(chēng)密鑰進(jìn)行解密,得到對(duì)稱(chēng)密鑰,再利用對(duì)稱(chēng)密鑰對(duì)密文請(qǐng)求進(jìn)行解密,得到明文請(qǐng)求
在這個(gè)過(guò)程中,黑客由于不持有私鑰,就無(wú)法獲取到對(duì)稱(chēng)密鑰,進(jìn)而無(wú)法進(jìn)行解密
注意:為什么有非對(duì)稱(chēng)密鑰了還要使用對(duì)稱(chēng)密鑰,直接把所有的數(shù)據(jù)通過(guò)非對(duì)稱(chēng)密鑰進(jìn)行傳輸不行么?其實(shí)也可以,但是效率太低,成本也太高
非對(duì)稱(chēng)密鑰由于其復(fù)雜性,在傳輸?shù)倪^(guò)程中傳輸成本高,運(yùn)算效率低,而對(duì)稱(chēng)密鑰傳輸成本低,運(yùn)算效率高,為了保證傳輸?shù)男?使用非對(duì)稱(chēng)密鑰傳輸關(guān)鍵數(shù)據(jù)
(如密鑰),剩余的大量的業(yè)務(wù)數(shù)據(jù)通過(guò)更加快速的對(duì)稱(chēng)密鑰進(jìn)行傳輸
可以說(shuō),非對(duì)稱(chēng)密鑰引入安全性,必然要降低傳輸效率(就和TCP引入可靠性效率降低一樣)
以上就是非對(duì)稱(chēng)加密機(jī)制保證數(shù)據(jù)傳輸安全的機(jī)制,核心在于:黑客不持有私鑰,無(wú)法對(duì)由客戶(hù)端傳輸過(guò)來(lái)的通過(guò)公鑰加密的對(duì)稱(chēng)密鑰進(jìn)行解密
但就算這樣做還是存在安全漏洞(你不得不佩服黑客):黑客要想辦法能夠?qū)?code>對(duì)稱(chēng)密鑰進(jìn)行解密,怎么解密呢?讓對(duì)稱(chēng)密鑰的密鑰不是服務(wù)器生成的公鑰,自己產(chǎn)生一對(duì)公鑰和私鑰,讓客戶(hù)端通過(guò)自己產(chǎn)生的公鑰對(duì)對(duì)稱(chēng)密鑰進(jìn)行加密,這樣黑客就能拿到對(duì)稱(chēng)密鑰,緊接著,再使用服務(wù)器產(chǎn)生的公鑰對(duì)數(shù)據(jù)進(jìn)行加密,傳輸給服務(wù)器,服務(wù)器收到數(shù)據(jù)也能解密,整個(gè)過(guò)程看起來(lái)沒(méi)有被解密過(guò),實(shí)際上被黑客瞞天過(guò)海了
,但是~服務(wù)器產(chǎn)生的公鑰根本沒(méi)有傳輸?shù)娇蛻?hù)端,而是被黑客截取了!
這種機(jī)制也被叫做"中間人攻擊問(wèn)題"!
3.中間人攻擊
圖解:
具體過(guò)程:
- 服務(wù)器產(chǎn)生一對(duì)密鑰:公鑰(pub1) 私鑰(pri1),并將公鑰(pub1)經(jīng)過(guò)網(wǎng)絡(luò)傳輸給客戶(hù)端
- 黑客截取服務(wù)器傳輸?shù)墓€(pub1),自己產(chǎn)生一對(duì)公鑰(pub2)和私鑰(pri2),并將自己產(chǎn)生的pub2傳輸給客戶(hù)端,自己保留pri2
- 客戶(hù)端收到黑客產(chǎn)生的公鑰(pub2),利用這個(gè)公鑰對(duì)產(chǎn)生的對(duì)稱(chēng)密鑰進(jìn)行加密,然后生成密文請(qǐng)求,將密文請(qǐng)求發(fā)送給服務(wù)器
- 黑客截取產(chǎn)生的密文請(qǐng)求,利用自己產(chǎn)生的私鑰(pri2)解密對(duì)稱(chēng)密鑰,得到對(duì)稱(chēng)密鑰,解密密文請(qǐng)求
- 黑客將得到的明文請(qǐng)求使用服務(wù)器產(chǎn)生的公鑰(pub1)進(jìn)行加密,傳輸給服務(wù)器
- 服務(wù)器收到經(jīng)pub1加密的密文請(qǐng)求,使用pri1解密,得到明文請(qǐng)求
整個(gè)過(guò)程黑客成功實(shí)現(xiàn)了瞞天過(guò)海,服務(wù)器收到經(jīng)pub1加密的數(shù)據(jù),就認(rèn)為傳輸?shù)倪^(guò)程中沒(méi)有發(fā)生解密的過(guò)程,實(shí)際上黑客利用自己產(chǎn)生的一對(duì)密鑰進(jìn)行了調(diào)包
那如何解決中間人問(wèn)題呢–引入公正機(jī)構(gòu)
中間人問(wèn)題產(chǎn)生的原因在于客戶(hù)端沒(méi)有判別能力,他不知道傳輸過(guò)來(lái)的公鑰屬于黑客還是屬于服務(wù)器,第三方機(jī)構(gòu)就讓客戶(hù)端擁有了判別能力
4.公正機(jī)構(gòu)(數(shù)字簽名)解決中間人問(wèn)題
首先,網(wǎng)站的開(kāi)發(fā)者在搭建網(wǎng)站時(shí),生成一對(duì)服務(wù)器的公鑰和私鑰,并向公正機(jī)構(gòu)申請(qǐng)一個(gè)證書(shū),服務(wù)器需要提供一些服務(wù)器相關(guān)的數(shù)據(jù)(網(wǎng)站域名/服務(wù)器公鑰等),公正機(jī)構(gòu)根據(jù)這些信息進(jìn)行審核,審核通過(guò)產(chǎn)生一個(gè)證書(shū),證書(shū)不是紙質(zhì)的,而是一段結(jié)構(gòu)化數(shù)據(jù)
,證書(shū)內(nèi)部有很多屬性,比如網(wǎng)站域名,公鑰,證書(shū)的過(guò)期時(shí)間等,其中最重要
的屬性是數(shù)字簽名
,數(shù)字簽名是一個(gè)被加密過(guò)的校驗(yàn)和
,通過(guò)證書(shū)中的屬性計(jì)算出一個(gè)校驗(yàn)和,再利用公正機(jī)構(gòu)自己產(chǎn)生的私鑰
進(jìn)行加密,就得到了數(shù)字簽名,這個(gè)屬性,將是客戶(hù)端驗(yàn)證公鑰的關(guān)鍵!公正機(jī)構(gòu)產(chǎn)生的公鑰一般都是內(nèi)置在客戶(hù)端的操作系統(tǒng)之中
客戶(hù)端在和服務(wù)器進(jìn)行通信時(shí),也會(huì)向服務(wù)器申請(qǐng)服務(wù)器的證書(shū),證書(shū)中包含服務(wù)器產(chǎn)生的公鑰
客戶(hù)端收到傳輸過(guò)來(lái)的公鑰(服務(wù)器產(chǎn)生),就可以利用數(shù)字簽名來(lái)校驗(yàn)公鑰是否被替換過(guò),這個(gè)過(guò)程也被稱(chēng)作證書(shū)的校驗(yàn),核心就是計(jì)算這里面的校驗(yàn)和
客戶(hù)端利用操作系統(tǒng)內(nèi)置的公正機(jī)構(gòu)的公鑰對(duì)數(shù)字簽名進(jìn)行解密,得到證書(shū)的校驗(yàn)和
,客戶(hù)端重新對(duì)證書(shū)進(jìn)行校驗(yàn)和的計(jì)算,得到一個(gè)新的校驗(yàn)和,將這個(gè)計(jì)算出的校驗(yàn)和和解密得到的校驗(yàn)和進(jìn)行對(duì)比,如果相同,就證明服務(wù)器的公鑰沒(méi)有被篡改,證書(shū)是可信的
如果黑客使用自己的公鑰替換了服務(wù)器的公鑰,那么客戶(hù)端計(jì)算出的校驗(yàn)和就會(huì)解密出的校驗(yàn)和不一致,此時(shí)就會(huì)警告客戶(hù)端(往往是彈出一個(gè)小框,顯示有風(fēng)險(xiǎn))
同時(shí),黑客也無(wú)法修改證書(shū)之中的數(shù)字簽名,數(shù)字簽名的解密需要通過(guò)公正機(jī)構(gòu)的公鑰,但是這個(gè)公鑰是客戶(hù)端操作系統(tǒng)內(nèi)置的,黑客無(wú)法獲取
那黑客不能自己申請(qǐng)一個(gè)證書(shū)么?不能,如果要申請(qǐng)證書(shū),就要向公正機(jī)構(gòu)提供服務(wù)器的域名和持有者信息,黑客不是服務(wù)器的持有者,從而就無(wú)法申請(qǐng)證書(shū)
上述就是HTTPS加密的整個(gè)過(guò)程,看得出來(lái)攻擊和防御
是"相輔相成"的,網(wǎng)絡(luò)安全在現(xiàn)在也是一個(gè)巨大的挑戰(zhàn)!
總結(jié):HTTPS的加密文章來(lái)源:http://www.zghlxwxcb.cn/news/detail-825802.html
- 對(duì)稱(chēng)密鑰,加密業(yè)務(wù)數(shù)據(jù)
- 非對(duì)稱(chēng)密鑰,加密對(duì)稱(chēng)密鑰
- 中間人攻擊
- 使用證書(shū)的數(shù)字簽名,校驗(yàn)服務(wù)器的公鑰
以上就是<<網(wǎng)絡(luò)原理(5)–HTTPS是如何進(jìn)行加密的>>的所有內(nèi)容,至此,網(wǎng)絡(luò)原理章節(jié)完結(jié)撒花!文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-825802.html
到了這里,關(guān)于網(wǎng)絡(luò)原理(5)--HTTPS是如何進(jìn)行加密的的文章就介紹完了。如果您還想了解更多內(nèi)容,請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!