對稱加密與非對稱加密再理解

文章目錄

• 對稱加密與非對稱加密再理解
• • 一、對稱加密與非對稱加密
  • • 對稱加密
    • 非對稱加密
  • 二、混合加密
  • 三、添加數(shù)字證書 + 混合加密
  • • https的真正請求流程
  • 四、數(shù)字證書
  • • 服務器獲取證書？
    • 摘要
    • 簽名

一、對稱加密與非對稱加密

HTTPS 的安全性是由 TLS 來保證的。

加密可以分為兩大類：對稱加密和非對稱加密。

對稱加密

對稱加密的方法是，雙方使用同一個秘鑰對數(shù)據(jù)進行加密和解密。但是對稱加密的存在一個問題，就是如何保證秘鑰傳輸?shù)陌踩?#xff0c;因為秘鑰還是會通過網(wǎng)絡傳輸?shù)?#xff0c;一旦秘鑰被其他人獲取到，那么整個加密過程就毫無作用了。 這就要用到非對稱加密的方法。速度要比非對稱加密快。

非對稱加密

非對稱加密的方法是，我們擁有兩個秘鑰，一個是公鑰，一個是私鑰。公鑰是公開的，私鑰是保密的。用私鑰加密的數(shù)據(jù)，只有對應的公鑰才能解密，用公鑰加密的數(shù)據(jù)，只有對應的私鑰才能解密。我們可以將公鑰公布出去，任何想和我們通信的客戶， 都可以使用我們提供的公鑰對數(shù)據(jù)進行加密，這樣我們就可以使用私鑰進行解密，這樣就能保證數(shù)據(jù)的安全了。但是非對稱加密有一個缺點就是加密的過程很慢，因此如果每次通信都使用非對稱加密的方式的話，反而會造成等待時間過長的問題。

二、混合加密

對稱加密和非對稱加密搭配使用。

基于以上兩點原因，最終選擇了一個更加完美的方案，那就是在傳輸數(shù)據(jù)階段依然使用對稱加密，但是對稱加密的密鑰我們采用非對稱加密來傳輸。

https使用混合加密，并且還要配合數(shù)字證書來實現(xiàn)安全性。

從圖中可以看出，改造后的流程是這樣的：

• 首先瀏覽器向服務器發(fā)送對稱加密套件列表、非對稱加密套件列表和隨機數(shù) client-random；
• 服務器保存隨機數(shù) client-random，選擇對稱加密和非對稱加密的套件，然后生成隨機數(shù) service-random，向瀏覽器發(fā)送選擇的加密套件、service-random 和公鑰；
• 瀏覽器保存公鑰，并利用 client-random 和 service-random 計算出來 pre-master，然后利用公鑰對 pre-master 加密，并向服務器發(fā)送加密后的數(shù)據(jù)；
• 最后服務器拿出自己的私鑰，解密出 pre-master 數(shù)據(jù)，并返回確認消息。

到此為止，服務器和瀏覽器就有了共同的 client-random、service-random 和 pre-master，然后服務器和瀏覽器會使用這三組隨機數(shù)生成對稱密鑰，因為服務器和瀏覽器使用同一套方法來生成密鑰，所以最終生成的密鑰也是相同的。

有了對稱加密的密鑰之后，雙方就可以使用對稱加密的方式來傳輸數(shù)據(jù)了。

需要特別注意的一點，pre-master 是經(jīng)過公鑰加密之后傳輸?shù)?#xff0c;所以黑客無法獲取到 pre-master，這樣黑客就無法生成密鑰，也就保證了黑客無法破解傳輸過程中的數(shù)據(jù)了

注：什么是加密套件？

加密套件（CipherList）是指在ssl通信中，服務器和客戶端所使用的加密算法的組合。在ssl握手初期，客戶端將自身支持的加密套件列表發(fā)送給服務器；在握手階段，服務器根據(jù)自己的配置從中盡可能的選出一個套件，作為之后所要使用的加密方式。

其實就是服務器選擇一個雙方要使用的加密方法。

三、添加數(shù)字證書 + 混合加密

對稱加密和非對稱加密，以及兩者結(jié)合起來的混合加密，實現(xiàn)了機密性。
但僅有機密性，離安全還差的很遠。

黑客雖然拿不到會話密鑰，無法破解密文，但可以通過竊聽收集到足夠多的密文，再嘗試著修改、重組后發(fā)給網(wǎng)站。因為沒有完整性保證，服務器只能“照單全收”，然后他就可以通過服務器的響應獲取進一步的線索，最終就會破解出明文。

另外，黑客也可以偽造身份發(fā)布公鑰。如果你拿到了假的公鑰，混合加密就完全失效了。你以為自己是在和“某寶”通信，實際上網(wǎng)線的另一端卻是黑客，銀行卡號、密碼等敏感信息就在“安全”的通信過程中被竊取了。

所以，在機密性的基礎上還必須加上完整性、身份認證等特性，才能實現(xiàn)真正的安全。

https的真正請求流程

https使用混合加密，并且還要配合數(shù)字證書來實現(xiàn)安全性。

• 客戶端向服務器發(fā)起請求，請求中包含使用的TLS版本號、生成的一個隨機數(shù)、以及客戶端支持的加密方法。
• 服務器端接收到請求后，確認雙方使用的加密方法和TLS版本號、并給出服務器的證書、以及一個服務器生成的隨機數(shù)。
• 客戶端確認服務器證書有效后，生成一個新的隨機數(shù)，并使用數(shù)字證書中解密拿到的服務器公鑰，加密這個隨機數(shù)，然后發(fā)給服務器。
• 服務器使用自己的私鑰，來解密客戶端發(fā)送過來的隨機數(shù)。這樣服務器就拿到了第三個隨機數(shù)。而且只有客戶端和服務器端知道這第三個隨機數(shù)，因為第三個隨機數(shù)是通過加密傳輸?shù)摹?/li>
• 客戶端和服務器端根據(jù)約定的加密方法使用前面的三個隨機數(shù)，生成會話秘鑰，以后的對話過程都使用這個秘鑰（即會話秘鑰）來加密信息。
• 以后客戶端和服務器端都使用這個會話秘鑰來加密。

四、數(shù)字證書

服務器獲取證書？

• 首先，服務器先用Hash算法將自己的公鑰和其他信息(例如認證時長，服務器域名…)進行加密，生成一個信息摘要，傳遞給認證機構(gòu)，并且認證機構(gòu)也會有自己的公鑰和私鑰，并且認證機構(gòu)會將自己的公鑰給了瀏覽器。
• 然后認證機構(gòu)會用自己的私鑰對已經(jīng)拿到的瀏覽器摘要進行加密，生成簽名，簽名和信息摘要合在一起稱為數(shù)字證書，（認證機構(gòu)生成的簽名是證書的關鍵，有了這個認證機構(gòu)的簽名，證書就合法了）。
• 然后再把這個證書傳遞給服務器，服務器會保存自己的證書，服務器并且也會把證書傳遞給瀏覽器。
• 瀏覽器用認證機構(gòu)傳給自己的公鑰對證書進行解密拿到摘要A，并讀取證書中相關的明文信息，采用 CA 簽名時相同的 Hash 函數(shù)來計算并得到摘要B，對比信息摘要 A 和信息摘要 B，如果一致，則可以確認證書是合法的，同時在摘要A中也拿到了服務器的公鑰。

摘要

給計算機一篇文章，計算機用摘要算法（主要是哈希類算法）生成一個字符串，如果文章內(nèi)容改變，哪怕是一個字，一個標點符號，摘要也會完全改變。和完全加密一篇文章相比，摘要的體積很小，因此非常有利于存儲和傳輸。

通常對于一個給定的摘要算法，無論你的文章多大，有多少字節(jié)，最終生成摘要的字節(jié)數(shù)是固定的。

摘要是對原文的證明，從原文到摘要是一個不可逆的過程。

通過原文可以計算出摘要，一旦原文發(fā)生變化，哪怕是一個標點符號，摘要也會發(fā)生變化。而已知一個摘要，想要反推出原文，幾乎是不可能的。因為摘要和原文并不是一對一的關系，是多個原文對應一個摘要。而且，想要找到兩個摘要碰撞的原文是非常困難的發(fā)生概率相當于買彩票中大獎 。而且就算黑客找到了碰撞的原文，也未必可以起到作用。

簽名

如果張三將合同生成摘要，再用自己的私鑰加密摘要，得到一個密文串，那么這個串就是張三對合同的數(shù)字簽名

總結(jié)

以上是生活随笔為你收集整理的【https】对称加密与非对称加密再理解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。