# 加密的問題 ## 對稱加密 HTTP的通信是明文的， 任何一個人都可以監聽上面的通信，截取里面的數據包。最容易想到的解決方法無非就是**加密。** 每次傳輸之前把消息用加密算法加密，服務器收到了以后再解密。 如下圖所示  這種**加密和解密用的是同一個密鑰的算法稱為對稱加密算法**。那么實際上**加密和解密算法是公開的，密鑰是保密的** 那么問題就來了，如果密鑰在網絡上發送的時候被截取了怎么辦，也就是說密鑰同樣不能在網絡上傳輸，但是加密雙方都必須知道。 ## 非對稱加密 之前的算法需要協商一個保密的**密鑰**，而這個密鑰在網絡上傳輸的時候存在被竊取的風險。然后出現了一個**RSA非對稱加密算法。** 這個算法有一對密鑰，一個是**私鑰，**它是保密的，一個是**公鑰**，是對外公開的。 那么用**私鑰加密的數據，只能用對應的公鑰來解密** 同樣，用**公鑰**加密的數據，只有對應的**私鑰**才能解密。 于是瀏覽器給服務器發消息的時候，瀏覽器先使用**服務器的公鑰**進行加密，然后服務器可以使用自己的**私鑰**去解密。 反之亦然，服務器給瀏覽器發信息的時候，使用瀏覽器的**公鑰**進行加密。 ## 非對稱加密 + 對稱加密 使用非對稱加密好是好，但是特別的慢。相對于非對稱加密而言，對稱加密會快很多。那么能不能折中一下呢？ 我們知道之前用對稱加密的時候，問題在于密鑰無法安全傳輸。那么現在能不能**先對密鑰使用非對稱加密**，這樣保證了密鑰的安全傳輸。等到密鑰被對方收到了以后，就使用**對稱加密**，這樣可以兼顧安全和性能呢。 # 身份認證的問題 上面說了，可以對密鑰進行非對稱加密，對報文進行對稱加密，這樣可以保證性能和安全性。但是新的問題來了，我們怎么保證對方的身份。也就是說如果服務器給瀏覽器發的**公鑰**給中間人**截取了**，然后冒充服務器給瀏覽器發了一個公鑰，這個時候，瀏覽器并不知道這一切，所以會使用中間人的公鑰進行加密，中間人當然就可以解密到消息了。 這就如同古代的時候，新上任的縣官被人半路上被綁匪給截了，然后綁匪拿著他的印信冒名頂替，下面的人并不知道此人并非真實縣官，這樣綁匪自然可以竊取各種機密。 所以**問題在于公鑰是公開的，完全可以被冒名頂替** ## 公證處 所以問題根源在于，**如何證明這個公鑰確實是服務器發出來的。** 這個問題在現實中就有，公證處就是這樣的第三方的存在，他提供的資料受到大家的信任。所以我們也可以搞一個認證中心，給大家頒發一個**數字證書**，證明這個人的身份。同時證書里面一定有**這個人的公鑰**。 但是證書依然有怎么安全傳輸，怎么避免被篡改的問題。我們可以使用HASH算法生成一個**消息摘要**，這就是**數字簽名。** HASH算法有個特性，**只要輸入有變化，那生成的數字簽名就會有巨大的變化**，這樣就可以防篡改。 中間人說，雖然改不了**公鑰**，但是可以替換整個原始的信息啊。就如果我們破解開機密碼一樣，不也是把原來加密以后的密碼文件給替換了嗎？ 道高一尺，魔高一丈，我們再讓公信處（CA）用**它的私鑰對消息摘要**加密，形成簽名。 **原始信息 + 數字簽名** = **數字證書**  這樣有了第三方的證書，相當于有個參考。我們可以用**CA的公鑰**對數字簽名進行解密，以此為**基線** 當服務器把它的**證書**給我們的時候，我們可以使用相同的Hash算法生成消息摘要，然后與“基線”對比，就知道是否被篡改過了沒。  **總結一下**，因為公鑰傳輸有可能被截取，所以我們希望有一個**第三方機構**能提供**基線**，我們只要對比**基線**就知道是否被人篡改過了。這樣每個網站它的基線應該是不同的，所以可以使用HASH算法對網站的個人信息生成一個**消息摘要**。那么我們只需要核對從網站收到的**消息摘要**與第三方給的**消息摘要**是否是一樣的就可以了。 好了，保證**基線**正確非常的關鍵，而第三方機構的證書同樣存在沒有加密的問題，容易被篡改的問題。 - 加密的問題：可以讓第三方機構使用其私鑰對**基線**加密，我們用其公鑰解密即可。 - 容易被篡改的問題：無解，只能說對CA進行信用分級，在操作系統/瀏覽器內置一些頂層的CA證書，高層的CA給底層的CA做背書。 這樣，網站在給我們發送**公鑰**的時候，實際上是把**公鑰**和**加密后的消息摘要**放到一起發過來的，我們 - 使用CA的**公鑰**對加密后的**消息摘要**進行解密，得到**基線** - 再對含有**公鑰**的個人信息同樣使用HASH算法也得到消息摘要 如果沒有被篡改過，這兩者應該是相等的 # 小結 我們可以對上面的過程進行簡單的總結。 如果傳輸的信息沒有加密，則信息容易在傳輸的過程中被竊取掉。那么我們可以使用同一個密鑰對信息加密，但是在傳輸之前，必須把密鑰在網絡上傳輸一次，所以一樣存在密鑰被竊取的風險。 那么可以使用非對稱加密算法，也就是發送方使用對方**公鑰**進行加密，然后接收方使用自己的**私鑰**進行解密。但是非對稱加密算法需要消耗大量的資源，速度比較的慢。 那么可以中和一下。對于**公鑰**我們使用**非對稱加密**，對于要發送的信息使用**對稱加密**，這里面存在的問題是如果我把**密鑰**用另一個偽裝的密鑰進行全文替換，依然存在安全的風險。 那么可以加上一個**身份驗證**的環節。 - 首先將**接收方**的公鑰+個人信息進行Hash，得到一個消息摘要，這樣如果傳輸過程中公鑰被篡改，則**消息摘要**肯定會改變。 - 然后對消息摘要使用第三方證書中心的**私鑰**進行加密，這樣就可以保證消息摘要不會再傳輸過程中被篡改。 也就是說CA證書中心的私鑰加密的是公鑰+個人信息進行hash以后的消息摘要，得到數字簽名。 這個數字簽名里面包含了**公鑰**的信息，而且被加密過了，不擔心被人篡改，可以作為**基線**  - 那么如何進行**校驗**呢？ 發送方會把公鑰信息+通過公鑰等信息生成的數字簽名一起發送過去。 接收方首先對數字簽名進行解密，這樣就可以獲得消息摘要。 同樣，再對公鑰信息進行Hash，同樣可以獲得消息摘要。 這兩者一核對，如果相同，則驗證通過，不同，則出現了問題唄。  也就是由一個第三方證書中心使用其**私鑰**對接收方的**公鑰**進行一次加密，也就是一個**基線**， # HTTPS  - 首先瀏覽器請求服務器的**公鑰** - 服務器返回一個含有公鑰的**數字證書**，這個數字證書怎么得到的呢？由含有公鑰的原始數據進行HASH以后，再使用CA私鑰加密得到**數字簽名**，再和原始數據一起組成了**數字證書** - 瀏覽器通過數字證書，既驗證了服務器的身份，又得到了**公鑰** - 使用公鑰加密**對稱加密**的密鑰 - 使用對稱加密進行通信 # 參考 [一個故事講完https](https://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=2665513779&idx=1&sn=a1de58690ad4f95111e013254a026ca2&chksm=80d67b70b7a1f26697fa1626b3e9830dbdf4857d7a9528d22662f2e43af149265c4fd1b60024&scene=21#wechat_redirect)