歡迎光臨
每天分享高質量文章

【漫畫】https 加密那點事

來自:苦逼的碼農(微信號:di201805)

作者:帥地

個人簡介:一個熱愛編程的在校生,我的世界不只有coding,還有writing。目前維護訂閱號「苦逼的碼農」,專註於寫「演算法與資料結構」,「Java」,「計算機網絡」。

背景

不知道從哪天開始,一禪也陷入了編程這條道路…..

對稱加密

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

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


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

例如:

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

非對稱加密

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


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

處理方式就是結合 對稱加密+非對稱加密這兩種方式,我們可以用非對稱加密的方式來傳輸對稱加密過程中的密鑰,之後我們就可以採取對稱加密的方式來傳輸資料了。具體是這樣子的:

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

例如:

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

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

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

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

數字證書登場

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

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

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

服務器在給客戶端傳輸公鑰的過程中,會把公鑰以及服務器的個人信息通過Hash演算法生成信息摘要。如圖

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

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

當客戶端拿到這份數字證書之後,就會用CA提供的公鑰來對數字證書裡面的數字簽名進行解密來得到信息摘要,然後對數字證書里服務器的公鑰以及個人信息進行Hash得到另外一份信息摘要。最後把兩份信息摘要進行對比,如果一樣,則證明這個人是服務器,否則就不是。如圖:

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

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

當客戶端收到服務器傳輸過來的資料數字證書時,就會在內置的證書串列里,查看是否有解開該數字證書的公鑰,如果有則…,如果沒有則….

希望通過這種漫文的方式,能夠讓你更加輕鬆的讀懂某些知識。

END



編號726,輸入編號直達本文

●輸入m獲取文章目錄

推薦↓↓↓

Web開發

更多推薦18個技術類微信公眾號

涵蓋:程式人生、演算法與資料結構、黑客技術與網絡安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。

赞(0)

分享創造快樂