深入理解Https如何保證通信安全
點(diǎn)擊上方藍(lán)色字體，選擇“標(biāo)星公眾號(hào)”
優(yōu)質(zhì)文章，第一時(shí)間送達(dá)
作為一名ABC搬運(yùn)工，我相信很多人都知道Https，也都知道它是用來(lái)保證通信安全的，但是如果你沒(méi)有深入了解過(guò)Https，可能并不知道它是如何保證通信安全的。我也是借著這次機(jī)會(huì)，和大家分享下我深入了解的一個(gè)過(guò)程。
本文主要帶著以下幾個(gè)問(wèn)題進(jìn)行探討：
1、什么是Https？
2、Https和Http有什么區(qū)別？
3、Https是如何保證通信安全的，它解決了哪些問(wèn)題？
1.離不開(kāi)的Https基礎(chǔ)理論
HTTPS是以安全為目標(biāo)的 HTTP 通道，在HTTP的基礎(chǔ)上通過(guò)傳輸加密和身份認(rèn)證保證了傳輸過(guò)程的安全性。
通過(guò)上面的定義，我們關(guān)注到兩點(diǎn)：傳輸加密、身份認(rèn)證。那我們先來(lái)了解下Https中將要用到的加密技術(shù)和認(rèn)證技術(shù)。
1）對(duì)稱加密
加密數(shù)據(jù)，需要秘鑰對(duì)（加密秘鑰和解密秘鑰），對(duì)稱加密很容易理解，即：通信雙方分別持有的加密秘鑰和解密秘鑰是一樣的。
2）非對(duì)稱加密
非對(duì)稱加密從字面上理解，即：通信雙方分別持有的加密秘鑰和解密秘鑰是不一樣的。我們將私人持有的秘鑰稱為私鑰，將公開(kāi)的允許大多數(shù)人持有的秘鑰稱為公鑰，現(xiàn)實(shí)場(chǎng)景中，通常是使用公鑰加密通信數(shù)據(jù)，然后私鑰解密保證數(shù)據(jù)安全性。
3）數(shù)字簽名
保證數(shù)據(jù)傳輸?shù)耐暾院桶l(fā)送方可信。數(shù)字簽名是非對(duì)稱密鑰加密技術(shù)與數(shù)字摘要技術(shù)的應(yīng)用，通常使用hash算法對(duì)數(shù)據(jù)進(jìn)行數(shù)字摘要（生成一段唯一的數(shù)據(jù)標(biāo)識(shí)，該過(guò)程不可逆），然后使用私鑰對(duì)數(shù)字摘要進(jìn)行加密；接收方收到數(shù)據(jù)后，使用發(fā)送放提供的公鑰對(duì)數(shù)據(jù)解密，確保數(shù)據(jù)是發(fā)送方發(fā)送的（如果不能解密，說(shuō)明發(fā)送方并不是真實(shí)的），然后使用相同的hash算法對(duì)解密的數(shù)據(jù)進(jìn)行數(shù)字摘要，比較前后兩次數(shù)字摘要信息，如果相同則說(shuō)明數(shù)據(jù)未被修改，從而確保數(shù)據(jù)完整性。
4）數(shù)字證書(shū)
數(shù)字證書(shū)又稱數(shù)字標(biāo)識(shí)，由用戶申請(qǐng)，證書(shū)簽證機(jī)關(guān)CA對(duì)其核實(shí)簽發(fā)，對(duì)用戶的公鑰認(rèn)證。前面提到的幾種技術(shù)都是在發(fā)送方正確的情況下所做的加密認(rèn)證技術(shù)，然而當(dāng)發(fā)送方本身就是偽造的，那么后續(xù)的加密認(rèn)證必然沒(méi)有意義。而證書(shū)簽證機(jī)構(gòu)一般都是權(quán)威機(jī)構(gòu)，通過(guò)其簽發(fā)的證書(shū)確保了發(fā)送方提供的公鑰是可信的。
上面的理論描述可能理解起來(lái)不是很直接，大家可以繼續(xù)跟著后面的分析過(guò)程，逐步滲透理解。
2.和Http區(qū)別
Https和Http的區(qū)別，我們?cè)谶@里不做詳細(xì)描述，主要通過(guò)一張圖了解一下：
通過(guò)上圖我們可以直觀的發(fā)現(xiàn)，HTTPS是在HTTP的基礎(chǔ)上加了SSL安全協(xié)議層，通俗的理解HTTPS=HTTP+SSL，SSL安全協(xié)議保證了通信過(guò)程的安全性。
主要體現(xiàn)在以下幾方面：
1）信息加密安全
2）信息完整性
3）身份認(rèn)證
3.如何保證通信安全
我們先來(lái)看下HTTP的一次數(shù)據(jù)通信過(guò)程。TCP建立連接和斷開(kāi)連接的過(guò)程，這里就不再描述了。
圖一
存在的安全性問(wèn)題：
1）圖一過(guò)程①和②都有可能被黑客截取，用戶的信息暴露，非常危險(xiǎn)。
HTTPS為了解決這個(gè)問(wèn)題，允許通信雙方共同約定一種加解密方式，即對(duì)稱加密技術(shù)，僅通信雙方知曉密鑰以確保傳輸數(shù)據(jù)的安全；可是依然存在一個(gè)問(wèn)題：通行雙方如何交互這個(gè)密鑰呢？
于是又提出通過(guò)非對(duì)稱加密技術(shù)實(shí)現(xiàn)密鑰的交互，即服務(wù)端向客戶端提供自己的公鑰，然后客戶端通過(guò)公鑰加密秘鑰傳輸給服務(wù)端，服務(wù)端收到后使用私鑰解密，獲取密鑰，后續(xù)通信雙方通過(guò)該對(duì)稱密鑰進(jìn)行通信。
圖二
2）圖二中的過(guò)程②，如果被黑客攔截會(huì)發(fā)生什么？
黑客可以偽造成服務(wù)器，將黑客自己的公鑰分發(fā)給客戶端，也就是說(shuō)“服務(wù)器”本身就是個(gè)假的，這樣的話圖二中過(guò)程③客戶端加密的密鑰就很容易被黑客獲取，顯然后續(xù)的通信過(guò)程一直被黑客監(jiān)聽(tīng)，信息完全暴露。
HTTPS為了解決這個(gè)問(wèn)題提出了“數(shù)字證書(shū)”，由于數(shù)字證書(shū)是權(quán)威機(jī)構(gòu)頒發(fā)的，申請(qǐng)者需要提交很多資料審核，正常情況下偽造者很難申請(qǐng)到證書(shū)，因此也就保證了服務(wù)端提供的公鑰是安全可信的。
圖三
3)圖三中的過(guò)程②頒發(fā)的證書(shū)，被黑客攔截篡改怎么辦？
如果證書(shū)被黑客攔截了。雖然黑客拿著證書(shū)也沒(méi)啥用，但是萬(wàn)一黑客搗亂把證書(shū)信息篡改了，那么客戶端接收后就根本不知道了，同樣存在安全隱患。
所以，CA機(jī)構(gòu)在生成證書(shū)的時(shí)候就使用了“數(shù)字簽名”，保證了證書(shū)的完整性。
原理：CA機(jī)構(gòu)使用Hash算法得到證書(shū)明文信息的“信息摘要”，然后使用自己的私鑰對(duì)“信息摘要”加密，生成數(shù)字簽名一同放在數(shù)字證書(shū)中；當(dāng)客戶端收到服務(wù)器發(fā)送的證書(shū)時(shí)，可以通過(guò)證書(shū)中的Hash算法對(duì)證書(shū)信息簽名得到“信息摘要”，然后使用CA機(jī)構(gòu)的公鑰對(duì)原證書(shū)中的簽名信息解密，如果解密后的“信息摘要”和自簽名得到的一致，則說(shuō)明沒(méi)問(wèn)題。（CA機(jī)構(gòu)一般都是權(quán)威性的，所以通常它的公鑰都是內(nèi)置在客戶端系統(tǒng)中的）
4）同樣的問(wèn)題，客戶端和服務(wù)端在通信過(guò)程中，雖然黑客沒(méi)有“會(huì)話密鑰”無(wú)法獲取真實(shí)的傳輸信息，但是黑客可以“修改數(shù)據(jù)”，比如刪除一段信息，這樣通信雙方拿到數(shù)據(jù)后，并不知道數(shù)據(jù)被修改了。
HTTPS為了保證數(shù)據(jù)的完整性，同樣使用了“數(shù)字簽名”，使用的是HMAC算法進(jìn)行簽名，保證了通行過(guò)程中的信息完整性。
至此，HTTPS已經(jīng)幫我們實(shí)現(xiàn)了通信雙方之間的安全通信。
作者 | 跳躍的鍵盤(pán)手
來(lái)源 | cnblogs.com/chenxf1117/p/15127479.html
