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

雖然現(xiàn)在許多網(wǎng)站都會用到HTTP和HTTPS，但是大家極力倡導(dǎo)使用的卻是更為安全的HTTPS，今天我們就來了解一下HTTPS是如何保證數(shù)據(jù)傳輸?shù)陌踩缘摹?/p>

本篇概要：1.HTTP的缺點(diǎn)2.HTTPS如何保證數(shù)據(jù)安全性3.對稱加密和非對稱加密4.HTTPS的請求過程5.如何防止數(shù)字證書被篡改6.單雙向認(rèn)證

1為什么說HTTP不安全?

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

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

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

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

但是使用對稱加密有一個關(guān)鍵點(diǎn)，那就是這個對稱密鑰，應(yīng)該如何來確定呢?在HTTP請求中，加密密鑰協(xié)商，還是個難題。

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

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

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

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

非對稱加密

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

非對稱加密對明文進(jìn)行加密和解密是使用的不同的密鑰。但是，我們在上面提過，在使用加密時，其難點(diǎn)就在于密鑰協(xié)商過程，那么，HTTPS是如何處理這個密鑰協(xié)商過程呢。

在這里，我們需要引入一個新的名詞：數(shù)字證書。

數(shù)字證書

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

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

就好比我們訪問億佰特網(wǎng)站，我們怎么知道我們訪問的億佰特網(wǎng)站是否是一個假的呢，所以我們通常在訪問時，先去獲取對方網(wǎng)站的證書信息，然后和本地瀏覽器載入的證書進(jìn)行比較看是否是安全的。

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

3HTTPS的請求過程

在上面我們簡單介紹了一下HTTPS和數(shù)字證書，但是它們是如何來解決HTTP中存在的數(shù)據(jù)竊聽、數(shù)據(jù)篡改、身份偽造問題的呢?

上圖是HTTPS簡單的請求模型，使用這個模型可以完美的解決上面提到的三個問題點(diǎn)。

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

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

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

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

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

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

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

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

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

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

單雙向認(rèn)證

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

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

審核編輯：湯梓紅