• 正文
    • 1、為什么說(shuō)HTTP不安全?
    • 2、HTTPS如何保證數(shù)據(jù)安全的呢?
    • 3、HTTPS的請(qǐng)求過(guò)程
    • 4、如何防止數(shù)字證書(shū)被篡改
  • 相關(guān)推薦
申請(qǐng)入駐 產(chǎn)業(yè)圖譜

HTTPS如何保證數(shù)據(jù)安全?講得很細(xì)

加入交流群
掃碼加入
獲取工程師必備禮包
參與熱點(diǎn)資訊討論

雖然現(xiàn)在許多網(wǎng)站都會(huì)用到HTTP和HTTPS,但是大家極力倡導(dǎo)使用的卻是更為安全的HTTPS,今天我們就來(lái)了解一下HTTPS是如何保證數(shù)據(jù)傳輸的安全性的。

本篇概要:

1.HTTP的缺點(diǎn)

2.HTTPS如何保證數(shù)據(jù)安全

3.對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密

4.HTTPS的請(qǐng)求過(guò)程

5.如何防止數(shù)字證書(shū)被篡改

6.單雙向認(rèn)證

1、為什么說(shuō)HTTP不安全?

HTTP本質(zhì)上就是一個(gè)TCP連接,只不過(guò)協(xié)議規(guī)定了使用80端口,以及發(fā)送命令或數(shù)據(jù)的格式,而TCP本身是沒(méi)有加密的功能。致命的是,HTTP在數(shù)據(jù)傳輸過(guò)程中,數(shù)據(jù)就是以明文的方式傳輸?shù)?,由于?shù)據(jù)沒(méi)有被加密,所以很容易出現(xiàn)數(shù)據(jù)竊聽(tīng)、篡改或者是身份偽造的不安全的行為。

有什么優(yōu)化的方法?

既然使用明文進(jìn)行數(shù)據(jù)傳輸不安全,那我們可以嘗試一下對(duì)數(shù)據(jù)進(jìn)行加密處理。比如,通信雙方可以約定一種算法,首先將需要發(fā)送的數(shù)據(jù)按照一定的規(guī)則進(jìn)行加密,然后對(duì)方接收到消息后按照相同的規(guī)則進(jìn)行解密。這個(gè)就是對(duì)稱(chēng)加密的體現(xiàn)形式了。

所謂對(duì)稱(chēng)加密,即原文和密文可使用一個(gè)相同的密鑰進(jìn)行加密和解密,即使用同一把密匙對(duì)原文加密得到密文或者是對(duì)密文解密獲取到原文。其優(yōu)點(diǎn)是加密解密效率較高。

但是使用對(duì)稱(chēng)加密有一個(gè)關(guān)鍵點(diǎn),那就是這個(gè)對(duì)稱(chēng)密鑰,應(yīng)該如何來(lái)確定呢?在HTTP請(qǐng)求中,加密密鑰協(xié)商,還是個(gè)難題。

2、HTTPS如何保證數(shù)據(jù)安全的呢?

 

在HTTPS數(shù)據(jù)傳輸過(guò)程中對(duì)數(shù)據(jù)進(jìn)行加密處理,HTTPS是使用對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密、簽名算法(簽名算法不是用來(lái)做加密的)以及證書(shū)機(jī)制來(lái)對(duì)消息進(jìn)行處理,以此達(dá)到一個(gè)安全的有效傳輸。

HTTPS是基于HTTP的上層添加了一個(gè)叫做TLS的安全層,對(duì)數(shù)據(jù)的加密等操作都是在這個(gè)安全層中進(jìn)行處理的,其底層還是應(yīng)用的HTTP。HTTPS通信先是使用非對(duì)稱(chēng)加密進(jìn)行密鑰的協(xié)商,協(xié)商出一個(gè)對(duì)稱(chēng)加密的密鑰,之后的通信則采用這個(gè)對(duì)稱(chēng)密鑰進(jìn)行對(duì)稱(chēng)加密密文傳輸。因?yàn)榉菍?duì)稱(chēng)加密其算法極其復(fù)雜,導(dǎo)致解密效率低下,而對(duì)稱(chēng)加密效率則明顯高出百倍。

在上面我們提到過(guò),對(duì)明文使用同一把密鑰進(jìn)行加密和解密是屬于對(duì)稱(chēng)加密。那么非對(duì)稱(chēng)加密又是怎樣的呢?

非對(duì)稱(chēng)加密

非對(duì)稱(chēng)加密,即原文加密和密文加密使用的是兩個(gè)不同的密鑰,一把稱(chēng)之為公鑰,一把稱(chēng)之為私鑰,使用公鑰加密的內(nèi)容可以通過(guò)私鑰進(jìn)行解密,同樣,使用私鑰加密的內(nèi)容使用公鑰可以進(jìn)行解密。公鑰和私鑰是相對(duì)而言的,通常而言,保留在己方不對(duì)外泄露稱(chēng)之為私鑰,可公布公開(kāi)的稱(chēng)之為公鑰。

非對(duì)稱(chēng)加密對(duì)明文進(jìn)行加密和解密是使用的不同的密鑰。但是,我們?cè)谏厦嫣徇^(guò),在使用加密時(shí),其難點(diǎn)就在于密鑰協(xié)商過(guò)程,那么,HTTPS是如何處理這個(gè)密鑰協(xié)商過(guò)程呢。

在這里,我們需要引入一個(gè)新的名詞:數(shù)字證書(shū)。

數(shù)字證書(shū)

所謂數(shù)字證書(shū),就是一份類(lèi)似于身份證一樣的網(wǎng)絡(luò)通信憑證,以證明所請(qǐng)求對(duì)象的身份信息不被篡改并且是真實(shí)有效的,當(dāng)我們請(qǐng)求某個(gè)網(wǎng)站時(shí),先去請(qǐng)求網(wǎng)站的數(shù)字證書(shū),然后檢查證書(shū)的真實(shí)性和有效性,從而一步步進(jìn)行身份驗(yàn)證,具體過(guò)程會(huì)在后面進(jìn)行圖解。

所謂證書(shū),就是服務(wù)端從網(wǎng)站公證處備案申請(qǐng)的一個(gè)身份證這樣的一個(gè)東西,里面包含有有效期開(kāi)始時(shí)間、結(jié)束時(shí)間、證書(shū)持有人、簽名以及最關(guān)鍵的持有人的公鑰信息等。通常情況下,我們會(huì)為服務(wù)端配置SSL證書(shū),SSL證書(shū)是數(shù)字證書(shū)的一種,由受信任的數(shù)字證書(shū)頒發(fā)機(jī)構(gòu)(簡(jiǎn)稱(chēng)CA)頒發(fā),具有服務(wù)器身份驗(yàn)證和數(shù)據(jù)傳輸加密的功能。

就好比我們?cè)L問(wèn)億佰特網(wǎng)站,我們?cè)趺粗牢覀冊(cè)L問(wèn)的億佰特網(wǎng)站是否是一個(gè)假的呢,所以我們通常在訪問(wèn)時(shí),先去獲取對(duì)方網(wǎng)站的證書(shū)信息,然后和本地瀏覽器載入的證書(shū)進(jìn)行比較看是否是安全的。

HTTPS通信在客戶(hù)端請(qǐng)求服務(wù)端時(shí),先去獲取服務(wù)端的證書(shū),然后將證書(shū)在本地進(jìn)行對(duì)比校驗(yàn)(通常瀏覽器中會(huì)內(nèi)置很多證書(shū),如上圖);當(dāng)驗(yàn)證通過(guò)時(shí),則表示是一個(gè)安全的證書(shū),否則瀏覽器狀態(tài)欄會(huì)提示“不安全”。

3、HTTPS的請(qǐng)求過(guò)程

 

在上面我們簡(jiǎn)單介紹了一下HTTPS和數(shù)字證書(shū),但是它們是如何來(lái)解決HTTP中存在的數(shù)據(jù)竊聽(tīng)、數(shù)據(jù)篡改、身份偽造問(wèn)題的呢?

上圖是HTTPS簡(jiǎn)單的請(qǐng)求模型,使用這個(gè)模型可以完美的解決上面提到的三個(gè)問(wèn)題點(diǎn)。

在第一次請(qǐng)求時(shí),客戶(hù)端先去請(qǐng)求服務(wù)端的數(shù)字證書(shū),并且生成一個(gè)隨機(jī)數(shù)R1,將隨機(jī)數(shù)和自己支持的加密算法告訴服務(wù)端。

服務(wù)端收到客戶(hù)端的請(qǐng)求后,選擇雙方共同支持的加密算法,并且生成新的隨機(jī)數(shù)R2,將服務(wù)器的數(shù)字證書(shū)及加密算法、隨機(jī)數(shù)一并返回給客戶(hù)端。

客戶(hù)端收到服務(wù)端的數(shù)字證書(shū),然后使用瀏覽器內(nèi)置的CA證書(shū)進(jìn)行解密獲取到證書(shū)中的服務(wù)端的公鑰及服務(wù)端的認(rèn)證信息,從而確保證書(shū)沒(méi)有被人篡改過(guò)。然后生成新的隨機(jī)數(shù)R3,使用服務(wù)端的公鑰對(duì)隨機(jī)數(shù)R3進(jìn)行加密后返回給服務(wù)端并將隨機(jī)數(shù)R1、R2、R3組合成一串密鑰用作對(duì)稱(chēng)加密用。

 
服務(wù)端收到客戶(hù)端加密后的隨機(jī)數(shù)R3,使用自己的私鑰對(duì)密文進(jìn)行解密獲取到隨機(jī)數(shù)R3,組合R1、R2、R3獲取到一串密鑰(和客戶(hù)端一致);然后開(kāi)始使用對(duì)稱(chēng)加密進(jìn)行通信。

上述就是HTTPS對(duì)密鑰協(xié)商的過(guò)程,由于非對(duì)稱(chēng)加密一方密匙加密后只能使用另一方密匙解密,所以在前兩次數(shù)據(jù)傳輸中即使被竊聽(tīng)也不怕,因?yàn)樵诘谌蝹鬟f隨機(jī)數(shù)R3時(shí)是使用公鑰加密的,只有服務(wù)端的私鑰才能解密,從而確保密鑰的安全性。

4、如何防止數(shù)字證書(shū)被篡改

 
在上面的請(qǐng)求模型中,如何防止客戶(hù)端返回的數(shù)字證書(shū)被篡改呢?

我們?cè)谏暾?qǐng)數(shù)字證書(shū)時(shí),會(huì)提供我們的基本信息以及企業(yè)域名信息等,證書(shū)頒發(fā)機(jī)構(gòu)CA會(huì)根據(jù)證書(shū)中的這些信息以及所提供的簽名算法對(duì)內(nèi)容進(jìn)行摘要,得到一個(gè)消息摘要(散列hash串),即使用Hash算法獲取到的一個(gè)唯一標(biāo)識(shí),然后CA機(jī)構(gòu)會(huì)使用自己的私鑰對(duì)摘要進(jìn)行加密,獲取到一個(gè)密文,即數(shù)字簽名,也叫做指紋;表示其唯一性。然后證書(shū)頒發(fā)機(jī)構(gòu)對(duì)整個(gè)明文數(shù)字證書(shū)使用證書(shū)頒發(fā)機(jī)構(gòu)CA自己的私鑰進(jìn)行加密,得到數(shù)字證書(shū)。

 

當(dāng)數(shù)字證書(shū)中的內(nèi)容被篡改時(shí),使用Hash算法對(duì)內(nèi)容進(jìn)行計(jì)算獲取到新的摘要,只需要對(duì)比一下兩個(gè)摘要是否相同即可知道證書(shū)中的數(shù)據(jù)知否有被篡改。

 

當(dāng)客戶(hù)端請(qǐng)求數(shù)據(jù)從瀏覽器端獲取到數(shù)字證書(shū)后,通過(guò)瀏覽器內(nèi)置的CA證書(shū)中的公鑰對(duì)數(shù)字證書(shū)進(jìn)行解密,獲取到明文數(shù)字證書(shū)(包含企業(yè)基本信息及服務(wù)端公鑰以及數(shù)字簽名),通過(guò)如上圖所示方式來(lái)判斷證書(shū)是否有被篡改。

 

單雙向認(rèn)證

在上面的例子中,客戶(hù)端請(qǐng)求服務(wù)端獲取證書(shū)信息進(jìn)行認(rèn)證,這個(gè)就是單向認(rèn)證,只是客戶(hù)端認(rèn)證服務(wù)端,但是服務(wù)端并沒(méi)有認(rèn)證客戶(hù)端的請(qǐng)求。HTTPS支持單向認(rèn)證,也支持雙向認(rèn)證。

雙向認(rèn)證的情況通常比較少見(jiàn),常見(jiàn)于銀行等領(lǐng)域,就像我們以前使用銀行的U盾,這就是一種雙向認(rèn)證案例,還有就是在電腦上安裝支付寶的證書(shū)等;雙向認(rèn)證比單向認(rèn)證更加安全,但是需要對(duì)每一個(gè)客戶(hù)端都進(jìn)行分配證書(shū)。

相關(guān)推薦