HTTPS使用什么加密方式？對(duì)稱(chēng)加密還是非對(duì)稱(chēng)加密?

我們這一次來(lái)討論一下有關(guān)于https的相關(guān)知識(shí)。其中最重要的就是有關(guān)于加密方式的知識(shí)。https中到底是對(duì)稱(chēng)加密還是非對(duì)稱(chēng)加密?為什么要選用對(duì)稱(chēng)加密，或者是非對(duì)稱(chēng)加密？玄機(jī)何在？這一小節(jié)，我們一起來(lái)看一看。

有關(guān)于加密，我們首先來(lái)看一下不加密的情況，一般在計(jì)算機(jī)中，不加密我們成為'裸奔'。如果數(shù)據(jù)不加密，則很容易被黑客竊取到。如下圖所示：

所以針對(duì)這樣的情況，我們應(yīng)該在數(shù)據(jù)傳輸?shù)倪^(guò)程中進(jìn)行對(duì)應(yīng)的加密，那么問(wèn)題來(lái)了，我們應(yīng)該選擇哪種加密方式呢?我們知道:常見(jiàn)的加密方式有對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密之分，例如我們這里選擇對(duì)稱(chēng)加密的形式。則如下圖所示：

我們可以把data數(shù)據(jù)，配合秘鑰，進(jìn)行f()函數(shù)運(yùn)算，進(jìn)而得到密文:XXX，再把XXX傳遞到服務(wù)器端，從而使數(shù)據(jù)的傳輸進(jìn)行加密，但是這樣也面臨一些對(duì)應(yīng)的問(wèn)題，我們知道，對(duì)稱(chēng)加密的秘鑰是由后端生成的，但是該秘鑰往往只有一個(gè)，因?yàn)楹蠖瞬豢赡転槊恳粋€(gè)人設(shè)置一個(gè)秘鑰，否則后端存儲(chǔ)的秘鑰就太多了。既然秘鑰只有一個(gè)，那么前端想要解密就需要獲取該秘鑰。這也就是不安全的地方了。因?yàn)楹诳鸵部梢詡窝b成良民(普通的客戶(hù)端)，拿取到對(duì)應(yīng)的秘鑰，從而對(duì)獲取的數(shù)據(jù)進(jìn)行解密處理。所以對(duì)稱(chēng)加密的方式其實(shí)是不安全的。雖然進(jìn)行了加密但是黑客可以很容易就進(jìn)行解密。

對(duì)稱(chēng)加密這么不安全，那么非對(duì)稱(chēng)加密呢?是不是非常安全。接下來(lái)讓我們一起來(lái)看一下:

從上圖我們可以知道，使用非對(duì)稱(chēng)加密有兩種加密方式：公鑰加密，私鑰解密，私鑰加密，公鑰解密。

一開(kāi)始服務(wù)端生成一對(duì)公私鑰(pk，sk)。我們要想進(jìn)行密文通訊，需要客戶(hù)端獲取對(duì)應(yīng)的公鑰(pk)。所以客戶(hù)端會(huì)發(fā)送請(qǐng)求，請(qǐng)求公鑰?？蛻?hù)端獲取到pk后，會(huì)把數(shù)據(jù)放到f()方法中進(jìn)行對(duì)應(yīng)的加密，所用的秘鑰就是剛剛獲取的pk。加密后得到的XXX就是密文。所以我們可以把數(shù)據(jù)傳輸給服務(wù)器端。

這個(gè)時(shí)候，如果黑客截取了對(duì)應(yīng)的XXX數(shù)據(jù)，黑客將沒(méi)法獲取對(duì)應(yīng)的明文數(shù)據(jù)，因?yàn)樗麤](méi)有獲取對(duì)應(yīng)的公鑰(pk)。

但是非對(duì)稱(chēng)加密的缺點(diǎn)來(lái)了:如果服務(wù)端想要給客戶(hù)端傳遞數(shù)據(jù)，也需要加密該怎么辦呢?如果使用私鑰加密，把加密的字段YYY傳輸給客戶(hù)端，看似沒(méi)有問(wèn)題，但是細(xì)細(xì)想一下，我們就會(huì)知道黑客也是可以充當(dāng)良民從而獲取公鑰(pk)的。也就是說(shuō)，只要是使用私鑰(sk)加密的方法，黑客都可以對(duì)其進(jìn)行解密。

總結(jié)發(fā)現(xiàn)：?jiǎn)为?dú)使用對(duì)稱(chēng)加密，不安全，單獨(dú)使用非對(duì)稱(chēng)加密，也不安全。那么應(yīng)該怎么解決呢?

經(jīng)過(guò)科學(xué)家的努力。我們就想到了能不能把兩者結(jié)合到一起呢?

例如下面的圖片顯示：

通過(guò)上面的圖片，我們知道，先通過(guò)請(qǐng)求，獲取服務(wù)端的pk，拿到之后，我們可以在客戶(hù)端隨機(jī)產(chǎn)生一個(gè)key，然后通過(guò)f(pk，key)=XXX的方式，把XXX傳輸給服務(wù)端，這樣服務(wù)端就可以通過(guò)私鑰(sk)對(duì)XXX進(jìn)行解密，從而得到key。以后我們就可以通過(guò)key，作為秘鑰，進(jìn)行對(duì)稱(chēng)加密了。

這樣的方式是非常棒的。通過(guò)這樣的方式我們會(huì)覺(jué)得數(shù)據(jù)是非常安全的。

但是真的安全嗎?

其實(shí)是不對(duì)的，如果我們?cè)O(shè)想一下。黑客如果從最開(kāi)始就對(duì)我們的通訊進(jìn)行了監(jiān)聽(tīng)。那么我們獲取公鑰的過(guò)程也會(huì)被監(jiān)聽(tīng)到。而我們知道，非對(duì)稱(chēng)加密的公鑰(pk)，黑客也是可以獲取的。所以一旦公鑰泄露。key就會(huì)泄露，key泄露，則后面的全部對(duì)稱(chēng)加密都稱(chēng)不上是安全的。所以后面很安全，但是如何保證pk的傳輸也是安全的就至關(guān)重要了。

那么該如何解決這個(gè)問(wèn)題呢?

我們可以對(duì)上面的內(nèi)容再次進(jìn)行優(yōu)化，例如我們這里引入一個(gè)'CA機(jī)構(gòu)'，'CA機(jī)構(gòu)'是一種信用機(jī)構(gòu)。主要靠信用賺錢(qián)，一般來(lái)說(shuō)都是全球的大型機(jī)構(gòu)。這類(lèi)機(jī)構(gòu)也會(huì)有自己的公鑰(cpk)和私鑰(csk)，可以使用csk對(duì)于pk公鑰進(jìn)行加密，從而得到證書(shū)，我們可以把證書(shū)傳遞給前端，讓前端利用瀏覽器內(nèi)部自帶的公鑰(cpk)對(duì)證書(shū)進(jìn)行解密，如果解密成功，則可以獲取到pk，隨后再利用pk對(duì)前端生成的key進(jìn)行加密。重復(fù)之前的步驟。

通過(guò)上面的步驟，其實(shí)我們就能夠得到完整的，安全的通訊方式了。這個(gè)其實(shí)就是https通訊方式中的最主要的加密方式介紹。

好了。通過(guò)上面的學(xué)習(xí)，我們可以知道https通訊其實(shí)使用了非對(duì)稱(chēng)加密和對(duì)稱(chēng)加密的多種方式來(lái)進(jìn)行的。

猜你喜歡：
python培訓(xùn)課程
HTTPS與HTTP有什么區(qū)別?
HTTP請(qǐng)求方式有哪些?