一文看懂https如何保證數據傳輸的安全性的

經過漫畫的形式由淺入深帶你讀懂htts是如何保證一臺主機把數據安全發給另外一臺主機的

對稱加密

一禪：在每次發送真實數據以前，服務器先生成一把密鑰，而後先把密鑰傳輸給客戶端。以後服務器給客戶端發送真實數據的時候，會用這把密鑰對數據進行加密，客戶端收到加密數據以後，用剛纔收到的密鑰進行解密。如圖：

固然，若是客戶端要給服務器發送數據，也是採用這把密鑰來加密，這裏爲了方便，我採用單方向傳輸的形式

小白：那萬一密鑰在傳輸的過程當中被別人截取了怎麼吧?

例如：

假如服務器用明文的方式傳輸密鑰給客戶端，而後密鑰被中間人給捕獲了，那麼在以後服務器和客戶端的加密傳輸過程當中，中間人也能夠用他捕獲的密鑰進行解密。這樣的話，加密的數據在中間人看來和明文沒啥兩樣

非對稱加密

一禪：這種方法就是，讓客戶端和服務器都擁有兩把鑰匙，一把鑰匙是公開的(全世界知道都不要緊)，咱們稱之爲公鑰；另外一把鑰匙則是保密的(只有本身本人才知道)，咱們稱之爲私鑰。這且，用公鑰加密的數據，只有對應的私鑰才能解密；用私鑰加密的數據，只有對應的公鑰才能解密。

這樣，服務器在給客戶端傳輸數據的過程當中，能夠用客戶端明文給他的公鑰進行加密，而後客戶端收到後，再用本身的私鑰進行解密。客戶端給服務器發送數據的時候也同樣採起這樣的方式。這樣就能保持數據的安全傳輸了。畫個圖理解一下：

一禪：處理方式就是結合 對稱加密+非對稱加密這兩種方式，咱們能夠用非對稱加密的方式來傳輸對稱加密過程當中的密鑰，以後咱們就能夠採起對稱加密的方式來傳輸數據了。具體是這樣子的：

服務器用明文的方式給客戶端發送本身的公鑰，客戶端收到公鑰以後，會生成一把密鑰(對稱加密用的)，而後用服務器的公鑰對這把密鑰進行加密，以後再把密鑰傳輸給服務器，服務器收到以後進行解密，最後服務器就能夠安全着獲得這把密鑰了，而客戶端也有一樣一把密鑰，他們就能夠進行對稱加密了。

小白：例如：

服務器以明文的方式給客戶端傳輸公鑰的時候，中間人截取了這把屬於服務器的公鑰，而且把中間人本身的公鑰冒充服務器的公鑰傳輸給了客戶端。

以後客戶端就會用中間人的公鑰來加密本身生成的密鑰。而後把被加密的密鑰傳輸給服務器，這個時候中間人又把密鑰給截取了，中間人用本身的私鑰對這把被加密的密鑰進行解密，解密後中間人就能夠得到這把密鑰了。

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

毫無疑問，在這個過程當中，中間人獲取了對稱加密中的密鑰，在以後服務器和客戶端的對稱加密傳輸中，這些加密的數據對中間人來講，和明文沒啥區別。

數字證書登場

在剛纔的講解中，咱們知道，之因此非對稱加密會不安全，是由於客戶端不知道這把公鑰是不是服務器的，所以，咱們須要找到一種策略來證實這把公鑰就是服務器的，而不是別人冒充的。

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

咱們須要找到一個擁有公信力、你們都承認的認證中心(CA)。

服務器在給客戶端傳輸公鑰的過程當中，會把公鑰以及服務器的我的信息經過Hash算法生成信息摘要。如圖

爲了防止信息摘要被人調換，服務器還會用CA提供的私鑰對信息摘要進行加密來造成數字簽名。如圖:

而且，最後還會把原來沒Hash算法以前的我的信息以及公鑰 和 數字簽名合併在一塊兒，造成數字證書。如圖

當客戶端拿到這份數字證書以後，就會用CA提供的公鑰來對數字證書裏面的數字簽名進行解密來獲得信息摘要，而後對數字證書裏服務器的公鑰以及我的信息進行Hash獲得另一份信息摘要。最後把兩份信息摘要進行對比，若是同樣，則證實這我的是服務器，不然就不是。如圖：

這樣，就能夠保證服務器的公鑰安全着交給客戶端了。

其實，(有些)服務器一開始就向認證中心申請了這些證書了(有沒有看過沒有證書的網站在地址欄會被標出警告？)，而客戶端是，也會內置這些證書。如圖：

當客戶端收到服務器傳輸過來的數據數字證書時，就會在內置的證書列表裏，查看是否有解開該數字證書的公鑰，若是有則...，若是沒有則....

有收穫?不妨點個贊，讓更多的人看到這篇文章！

文章首發於個人公衆號「苦逼的碼農」，更多精彩文章能夠關注下我哦。