HTTPS加密那點事對稱非對稱加密數字證書

**：【漫畫】https 加密那點事

首先，http協議的缺點：沒有對資料進行加密，都是明文傳輸的。如果要改進這種明文傳輸的協議，該如何做呢？

在每次傳送真實資料之前，伺服器先生成一把金鑰，然後先把金鑰傳輸給客戶端。之後伺服器給客戶端傳送真實資料的時候，會用這把金鑰對資料進行加密，客戶端收到加密資料之後，用剛才收到的金鑰進行解密。如圖：

當然，如果客戶端要給伺服器傳送資料，也是採用這把金鑰來加密，這裡為了方便，我採用單方向傳輸的形式

但這樣做的話有乙個問題，萬一金鑰在傳輸的過程中被別人擷取了怎麼吧?

例如：假如伺服器用明文的方式傳輸金鑰給客戶端，然後金鑰被中間人給捕獲了，那麼在之後伺服器和客戶端的加密傳輸過程中，中間人也可以用他捕獲的金鑰進行解密。這樣的話，加密的資料在中間人看來和明文沒啥兩樣。

所以對稱加密的問題出在了怎麼把秘鑰安全的傳給客戶端。

這種方法就是，讓客戶端和伺服器都擁有兩把鑰匙，一把鑰匙是公開的(全世界知道都沒關係)，我們稱之為公鑰；另一把鑰匙則是保密的(只有自己本人才知道)，我們稱之為私鑰。這且，用公鑰加密的資料，只有對應的私鑰才能解密；用私鑰加密的資料，只有對應的公鑰才能解密。

這樣，伺服器在給客戶端傳輸資料的過程中，可以用客戶端明文給他的公鑰進行加密，然後客戶端收到後，再用自己的私鑰進行解密。客戶端給伺服器傳送資料的時候也一樣採取這樣的方式。這樣就能保持資料的安全傳輸了。畫個圖理解一下：

但非對稱加密也有個缺點：非對稱加密在加密的時候特別慢，比對稱加密慢了上百倍。

所以繼續優化：

對稱加密之所以不安全，是因為金鑰無法安全交付給客戶端，所以採用結合對稱加密+非對稱加密這兩種方式，我們可以用非對稱加密的方式來傳輸對稱加密過程中的金鑰，之後我們就可以採取對稱加密的方式來傳輸資料了。具體是這樣子的：

伺服器用明文的方式給客戶端傳送自己的公鑰，客戶端收到公鑰之後，會生成一把金鑰(對稱加密用的)，然後用伺服器的公鑰對這把金鑰進行加密，之後再把金鑰傳輸給伺服器，伺服器收到之後進行解密，最後伺服器就可以安全得到這把金鑰了，而客戶端也有同樣一把金鑰，他們就可以進行對稱加密了。

其實，非對稱加密也並非是傳輸安全的：

例如：伺服器以明文的方式給客戶端傳輸公鑰的時候，中間人擷取了這把屬於伺服器的公鑰，並且把中間人自己的公鑰冒充伺服器的公鑰傳輸給了客戶端。

之後客戶端就會用中間人的公鑰來加密自己生成的金鑰。然後把被加密的金鑰傳輸給伺服器，這個時候中間人又把金鑰給擷取了，中間人用自己的私鑰對這把被加密的金鑰進行解密，解密後中間人就可以獲得這把金鑰了。

最後中間人再對這把金鑰用剛才伺服器的公鑰進行加密，再發給伺服器。如圖：

毫無疑問，在這個過程中，中間人獲取了對稱加密中的金鑰，在之後伺服器和客戶端的對稱加密傳輸中，這些加密的資料對中間人來說，和明文沒啥區別。

與對稱加密不同，非對稱加密之所以不安全，是因為客戶端不知道這把公鑰是不是屬於伺服器的。

我們知道，之所以非對稱加密會不安全，是因為客戶端不知道這把公鑰是否是伺服器的，因此，我們需要找到一種策略來證明這把公鑰就是伺服器的，而不是別人冒充的。

解決這個問題的方式就是使用數字證書，具體是這樣的：

我們需要找到乙個擁有公信力、大家都認可的認證中心(ca)。

伺服器在給客戶端傳輸公鑰的過程中，會把公鑰以及伺服器的個人資訊通過hash演算法生成資訊摘要。如圖

為了防止資訊摘要被人調換，伺服器還會用ca提供的私鑰對資訊摘要進行加密來形成數字簽名。如圖:

並且，最後還會把原來沒hash演算法之前的個人資訊以及公鑰和數字簽名合併在一起，形成數字證書。如圖：

當客戶端拿到這份數字證書之後，就會用ca提供的公鑰來對數字證書裡面的數字簽名進行解密來得到資訊摘要，然後對數字證書裡伺服器的公鑰以及個人資訊進行hash得到另外乙份資訊摘要。最後把兩份資訊摘要進行對比，如果一樣，則證明這個人是伺服器，否則就不是。如圖：

這樣，就可以保證伺服器的公鑰安全著交給客戶端了。

但是ca的公鑰是怎麼拿給客戶端的呢？伺服器又怎麼有ca的私鑰的呢？

當客戶端收到伺服器傳輸過來的資料數字證書時，就會在內建的證書列表裡，檢視是否有解開該數字證書的公鑰，如果有則...，如果沒有則....

HTTPS加密那點事 對稱 非對稱加密 數字證書