https加密那點事。
這篇文章之前有寫過，不過那篇文章在排版上很差，而且有些小許的錯誤。今天，我重新修改了那篇文章。算是那篇文章的修訂版。
背景
不知道從哪天開始，一禪也陷入了程式設計這條道路.....
對稱加密
在每次傳送真實資料之前，伺服器先生成一把 金鑰 ，然後先把金鑰傳輸給客戶端。之後伺服器給客戶端傳送真實資料的時候，會用這把金鑰對資料進行加密，客戶端收到加密資料之後，用剛才收到的金鑰進行解密。如圖：
當然，如果客戶端要給伺服器傳送資料，也是採用這把金鑰來加密，這裡為了方便，我採 用單方向傳輸的形式
那萬一金鑰在傳輸的過程中被別人截取了怎麼吧?
例如：
假如伺服器用明文的方式傳輸金鑰給客戶端，然後金鑰被中間人給捕獲了，那麼在之後伺服器和客戶端的加密傳輸過程中，中間人也可以用他捕獲的金鑰進行解密。這樣的話，加密的資料在中間人看來和明文沒啥兩樣。
非對稱加密
這種方法就是，讓客戶端和伺服器都擁有兩把鑰匙，一把鑰匙是公開的(全世界知道都沒關係)，我們稱之為公鑰；另一把鑰匙則是保密的(只有自己本人才知道)，我們稱之為私鑰。這且，用公鑰加密的資料，只有對應的私鑰才能解密；用私鑰加密的資料，只有對應的公鑰才能解密。
這樣，伺服器在給客戶端傳輸資料的過程中，可以用客戶端明文給他的公鑰進行加密，然後客戶端收到後，再用自己的私鑰進行解密。客戶端給伺服器傳送資料的時候也一樣採取這樣的方式。這樣就能保持資料的安全傳輸了。畫個圖理解一下：
處理方式就是結合 對稱加密+非對稱加密 這兩種方式，我們可以用非對稱加密的方式來傳輸對稱加密過程中的金鑰，之後我們就可以採取對稱加密的方式來傳輸資料了。具體是這樣子的：
伺服器用明文的方式給客戶端傳送自己的公鑰，客戶端收到公鑰之後，會生成一把 金鑰 (對稱加密用的)，然後用伺服器的公鑰對這把金鑰進行加密，之後再把金鑰傳輸給伺服器，伺服器收到之後進行解密，最後伺服器就可以安全著得到這把金鑰了，而客戶端也有同樣一把金鑰，他們就可以進行對稱加密了。
例如：
伺服器以明文的方式給客戶端傳輸公鑰的時候，中間人截取了這把屬於伺服器的公鑰，並且把 中間人自己的公鑰冒充伺服器的公鑰 傳輸給了客戶端。
之後客戶端就會用中間人的公鑰來加密自己生成的金鑰。然後把被加密的金鑰傳輸給伺服器，這個時候中間人又把 金鑰給擷取 了，中間人用自己的私鑰對這把被加密的金鑰進行解密，解密後中間人就可以 獲得這把金鑰 了。
最後中間人再對這把金鑰用剛才伺服器的公鑰進行加密，再發給伺服器。如圖：
毫無疑問，在這個過程中，中間人獲取了對稱加密中的金鑰，在之後伺服器和客戶端的對稱加密傳輸中，這些加密的資料對中間人來說，和明文沒啥區別。
數字證書登場
在剛才的講解中，我們知道，之所以非對稱加密會不安全，是因為客戶端不知道這把公鑰是否是伺服器的，因此，我們需要找到一種策略來證明這把公鑰就是伺服器的，而不是別人冒充的。
解決這個問題的方式就是使用 數字證書 ，具體是這樣的：
我們需要找到一個擁有公信力、大家都認可的 認證中心(CA) 。
伺服器在給客戶端傳輸公鑰的過程中，會把公鑰以及伺服器的個人資訊通過 Hash演算法 生成 資訊摘要 。如圖
為了防止資訊摘要被人調換，伺服器還會用 CA提供的私鑰 對資訊摘要進行加密來形成 數字簽名 。如圖:
並且，最後還會把原來沒Hash演算法之前的個人資訊以及公鑰 和 數字簽名合併在一起，形成 數字證書 。如圖
當客戶端拿到這份數字證書之後，就會用CA提供的公鑰來對數字證書裡面的數字簽名進行解密來得到資訊摘要，然後對數字證書裡伺服器的公鑰以及個人資訊進行Hash得到 另外一份資訊摘要 。最後把 兩份資訊摘要進行對比 ，如果一樣，則證明這個人是伺服器，否則就不是。如圖：
這樣，就可以保證伺服器的公鑰安全著交給客戶端了。
其實，(有些)伺服器一開始就向認證中心申請了這些證書了(有沒有看過沒有證書的網站在位址列會被標出警告？)，而客戶端是，也會內建這些證書。如圖：
當客戶端收到伺服器傳輸過來的資料數字證書時，就會在內建的證書列表裡，檢視是否有解開該數字證書的公鑰，如果有則...，如果沒有則....
希望通過這種漫文的方式，能夠讓你更加輕鬆的讀懂某些知識。
更多原創漫畫文章，可以關注我的公眾號： 苦逼的碼農(ID:di201805)， 文章會首發於我的公眾號
本公眾號（ 苦逼的碼農 ）專注於寫【Java】、【計算機網路】、【資料結構與演算法】，力求通俗易懂，期待你加入交流。