HTTPS使用什么加密方式？對稱加密還是非對稱加密?

我們這一次來討論一下有關于https的相關知識。其中最重要的就是有關于加密方式的知識。https中到底是對稱加密還是非對稱加密?為什么要選用對稱加密，或者是非對稱加密？玄機何在？這一小節(jié)，我們一起來看一看。

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

所以針對這樣的情況，我們應該在數(shù)據(jù)傳輸?shù)倪^程中進行對應的加密，那么問題來了，我們應該選擇哪種加密方式呢?我們知道:常見的加密方式有對稱加密和非對稱加密之分，例如我們這里選擇對稱加密的形式。則如下圖所示：

我們可以把data數(shù)據(jù)，配合秘鑰，進行f()函數(shù)運算，進而得到密文:XXX，再把XXX傳遞到服務器端，從而使數(shù)據(jù)的傳輸進行加密，但是這樣也面臨一些對應的問題，我們知道，對稱加密的秘鑰是由后端生成的，但是該秘鑰往往只有一個，因為后端不可能為每一個人設置一個秘鑰，否則后端存儲的秘鑰就太多了。既然秘鑰只有一個，那么前端想要解密就需要獲取該秘鑰。這也就是不安全的地方了。因為黑客也可以偽裝成良民(普通的客戶端)，拿取到對應的秘鑰，從而對獲取的數(shù)據(jù)進行解密處理。所以對稱加密的方式其實是不安全的。雖然進行了加密但是黑客可以很容易就進行解密。

對稱加密這么不安全，那么非對稱加密呢?是不是非常安全。接下來讓我們一起來看一下:

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

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

這個時候，如果黑客截取了對應的XXX數(shù)據(jù)，黑客將沒法獲取對應的明文數(shù)據(jù)，因為他沒有獲取對應的公鑰(pk)。

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

總結發(fā)現(xiàn)：單獨使用對稱加密，不安全，單獨使用非對稱加密，也不安全。那么應該怎么解決呢?

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

例如下面的圖片顯示：

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

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

但是真的安全嗎?

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

那么該如何解決這個問題呢?

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

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

好了。通過上面的學習，我們可以知道https通訊其實使用了非對稱加密和對稱加密的多種方式來進行的。

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