https對稱加密、非對稱加密、數字證書的理解以及爲何安全

你們都知道https。是http協議上多加了一層SSL協議進行加密的，只知道它安全確不瞭解它爲何安全，那今天就來簡單說一下：

HTTP：

首先http是不安全的，明文傳輸數據，容易被黑客抓包抓到，那麼怎麼辦呢？須要對數據進行加密，那如何進行加密？

對稱加密：

在客戶端發送數據以前，服務器就生成的密鑰傳輸給客戶端，在以後客戶端發送數據的時候使用該密鑰進行加密。以後客戶端與服務端的數據傳輸就使用該密鑰進行加解密。那這樣帶來的問題就是密鑰自己也是明文傳輸的，那黑客也一樣能劫取到密鑰，而後使用密鑰對用戶的數據進行解密，那和明文傳輸有什麼分別？(黑客：哈哈，你這不是逗我呢)接下來引入另外一個主角「非對稱加密」

非對稱加密

加密的方法仍是須要傳輸密鑰，可問題出在了如何將密鑰安全傳輸到服務器。而後就出現了公鑰和私鑰這種東西，我叫他「陰陽鑰",而且讓客戶端和服務器都擁有兩把鑰匙，一把鑰匙是公開的(公鑰)，一把鑰匙是私密的（私鑰）。兩把鑰匙，用公鑰加密的數據，必須對應的私鑰才能解密。相反，用私鑰加密的數據，必須是對應的公鑰才能解密。
在傳輸數據的時候客戶端先發送本身的公鑰給服務器，而後服務器使用該公鑰對數據進行加密。客戶端收到之後再用本身的私鑰進行解密。相反客戶端向服務器傳輸也是同樣。這下終於能保證數據的安全傳輸了。但是又出現了另一個棘手的問題：加密的速度慢了不少倍。這可怎麼辦？幾個程序員討論了半天 結合了兩種方式：」對稱加密+非對稱加密「

對稱加密+非對稱加密

使用非對稱加密的方式來加密「密鑰」，而後使用對稱加密的方式來加密傳輸的數據。

具體流程：服務器先明文發送本身的公鑰給客戶端，而後客戶端在發送數據前會生成一把密鑰而且使用服務端的公鑰來加密。如此一來，這把加密後的密鑰就只能服務器來解密。相反，客戶端也有本身的」陰陽鑰「，服務器用客戶端的公鑰來加密，客戶端用本身的私鑰來解密。這就達到了安全傳輸數據的目的。以上說得可能有點繞，要弄懂公鑰、私鑰、密鑰之間的關係。可這真的安全嗎？(黑客：有兩下子，可是我用本身作的公鑰冒充服務器的公鑰發給你進行欺騙，那我就獲得你的密鑰，依然在我掌控之中哈哈)

幾個程序員有點懵，可是冷靜下來思考發現存在的問題就是 沒法保證公鑰的來源是否真是服務器。通過幾天的討論，推出了一種新的方式：數字證書。

數字證書

首先成立了一個有公信力的認證中心（CA）值得信任的第三者：服務器在一開始就須要向CA申請證書（下載一個證書到服務器上）。固然客戶端收到服務端的證書會存儲在本地(有個容器專門存儲證書)。

當在服務器給客戶端傳輸公鑰的過程當中，會把公鑰和服務器的我的信息經過本身的hash算法生成信息摘要。爲了防止被人調換，服務器會用CA的私鑰對摘要進行加密造成」數字簽名「，最後把沒進行hash算法生成的公鑰及我的信息與這個加密後的數字簽名合併在一塊兒，就造成了所謂的數字證書。
在客戶端收到數字證書後，就會用去本地證書列表裏找合適的公鑰來對證書裏面的數字簽名進行解密以及hash算法獲得信息摘要，而後把數字證書裏面的摘要和外面的摘要進行對比，若是同樣，就證實這個來源必定是服務器。這樣就能安心的使用服務器的公鑰進行加密了，保證了公鑰的安全性。(黑客：糟糕，解不開數字簽名，冒充不了，可惡的第三者)

關於服務端搭建https及自動跳轉https的內容能夠關注個人其餘文章。