一、概念回顧

A <------M------> B
場景：A、B兩個人之間通訊，A傳輸信息M給B，假定是在不安全的通路上傳輸。

1.明文傳輸

被中間人C攔截下來，可以隨意篡改A發送給B的消息，且可以冒名頂替A直接與B通信。

2.對稱加密

加密和解密為同一秘鑰。

除非A和B面對面，找個小角落竊竊私語約定秘鑰，況且在現實生活中，躲在小房子里面的小聲說話，也有可能被別人聽見，隔墻有耳大家應該都聽過吧。
因為是網絡傳輸，秘鑰需要在網絡上傳輸給對方，在不安全的信道上倘若被C截獲到對稱秘鑰，那么仍然會出現數據被中間人篡改和冒名頂替的問題。

3.非對稱加密

A生成公鑰和私鑰，私鑰是自己用的保留在本地不再在網絡上進行傳輸，公鑰是分發給其他人用的，隨便傳輸給其他人（一般是下發的證書中包含公鑰然后返回給請求者），因為公鑰私鑰是一對，私鑰加密的只有公鑰才能夠解密，若能成功解密（則證明跟你交互的那個人是當初給你公鑰的那個人）。
A給B發消息，用A的私鑰加密，B收到之后用A的公鑰解密；同理B給A發消息，用B自身的私鑰加密，A收到后用B頒發的私鑰解密，解密成功即可證明發消息的人是當初給你公鑰的人。即A、B要使用非對稱加密方式進行通訊的話，需要各自保留對方的公鑰。
但是客戶端和服務器交互，則是服務端一個私鑰，而大量客戶端用公鑰跟他交互。

非對稱加密：保證了發消息的人就是當時給你公鑰的人。

問題一：中間人C截獲到A發給B的加密信息，即便C有A的公鑰使得他可以解密看到明文，但是他沒有A的私鑰所以偽造不了A的身份，但是他可以搞破壞，直接在密文的基礎上亂改，然后在發給B。B這時候收到用公鑰解密得到的結果肯定和A發給他的不一樣，但是他沒有辦法確認數據是被別人篡改過的，還是A發給他的本身就是有問題的。

如何保證數據在傳輸過程中是否有被篡改過？

利用數字簽名技術，即首先將原文進行哈希運算（不可逆）生成固定長度的數字摘要，（一定要理解摘要的含義，摘要是對總體的一個概括，比如原文件太過于龐大，有上百兆的大小，這時候如果直接對此進行私鑰加密那么代價太大，也就是說只要你對原文進行簽名，且附帶了原文，這樣能夠讓接受者驗證原始數據是否被篡改，這就完成了數字簽名的任務），只不過全文加密代價太大，我們可以使用對原文的縮略版——摘要進行加密即可達到同樣的目的，接收者B收到信息后，首先拿A的公鑰解密數字簽名得到原始摘要，再對傳過來原文進行摘要，二者對比，如果一致則說明數據沒有被篡改過。

---

問題二：公鑰解密成功只能說明發消息的人是當初給你公鑰的人，但是那個人是A嗎？是B嗎？還是中間人C呢？歸根結底還是上面的問題，除了現實生活中手對手把公鑰給你（如果他會易容術呢，冒名頂替也不是不可能）如C跑到B的電腦上將A的公鑰替換為C自己的公鑰，在不可靠的網絡環境下，更有可能出現這個問題，C冒充A說我是A這是我的公鑰，你拿去然后和我通信，B不知道給他公鑰的這個號稱是A的人，到底是不是A。

如何保證發布公鑰的A，不是他人冒名頂替的呢？

找一個受信任的機構"證書中心"（certificate authority，簡稱CA）做認證，證書中心用自己的私鑰給（A的公鑰+申請者A的信息等）加密，生成數字證書。當下次A給B發消息的時候A會帶上CA簽發的數字證書，B收到后用CA的公鑰解密證書，解密成功則證明這個的確是CA簽發的有效證書，而不是不知名的野雞機構，從而拿到了里面的A的公鑰，證明了A就是CA機構認證過的A,這個的的確確就是A的公鑰，錯了就找CA機構買單，假一賠十。然后拿A的公鑰，去解密數字簽名得到摘要，在對原文進行摘要算法之后和這個摘要進行對比，一致則說明沒有被篡改。

重申的概念

非對稱加密和數字摘要、數字簽名完全是兩個不同維度的概念。
非對稱加密只是一種利用公鑰和私鑰進行加密一種方式。
摘要：對于不定長的數據（這個數據一般很大）進行Hash（如MD5摘要算法）形成固定長度的輸出，這個輸出的結果叫做摘要。
數字簽名：利用自己的私鑰對上面生成的摘要進行加密，加密生成的結果被叫做數字簽名。
上面是狹義上的數字簽名（摘要被私鑰簽出來的加密后的信息叫做數字簽名）
廣義上的數字簽名指的是非對稱加密的一種實際使用用途，即利用非對稱加密和哈希算法來保證數據在傳輸過程中不被篡改。
既然是加密，那肯定是不希望別人知道我的消息，所以只有我才能解密，所以可得出公鑰負責加密，私鑰負責解密；同理，既然是簽名，那肯定是不希望有人冒充我發消息，只有我才能發布這個簽名，所以可得出私鑰負責簽名，公鑰負責驗證

非對稱加密的主要用途就是：密鑰交換和數字簽名。

數字簽名的作用主要是：確保發送的報文沒有被篡改。

非對稱加密主要應用在秘鑰協商階段 ！協商好秘鑰之后的通信就用對稱加密了 ！

Https秘鑰交換過程

客戶端要訪問一個網站，向支持https的服務器發起請求。
客戶端向服務器發送自己支持的秘鑰交換算法列表。
服務器選取一種秘鑰交換算法加上CA證書返回給客戶端。
客戶端驗證服務器是否合法，并生成一個隨機數然后用協商好的加密算法加密生成隨機秘鑰，并用剛才從CA證書中拿到的公鑰對其加密后發送給服務器。
服務器收到后用自己的私鑰解密（中間人沒有服務器的私鑰，所以沒有辦法看到傳輸的數據，另外確認秘鑰交換算法是在第一步，中間人是不知道秘鑰交換算法（中間人是無法在第一步做手腳的，那等同于它自己就是一個真實客戶端發起了一個新的請求，唯一一種情況攻擊人有一個合法CA下發的證書，且客戶端（一般為安卓設備）沒有對CA下發的證書中的內容網站地址和當前請求地址做對比校驗），就算攻擊者有公鑰，因為不知道協商協議，所以做不出來隨機秘鑰，頂多就是在傳輸過程中將報文攔截下來，亂改，但是給到服務器后，私鑰是解不開亂改之后的密文的）
服務器私鑰解密之后，拿到對稱秘鑰，并且用它再加密一個信息，返回給瀏覽器。

最關鍵的一步就是在客戶端采用 RSA 或 Diffie-Hellman 等加密算法生成 Pre-master，這個隨機秘鑰是用來計算最終的對稱秘鑰的，用公鑰加密之后攻擊人是不知道這個這個隨機秘鑰的，只有服務器才能解的開。

Https有可能會有中間人攻擊，當然瀏覽器自身會對CA證書做校驗，但是如果自己開發的過程中，尤其是在安卓客戶端，只是驗證證書是否是由CA簽出來的，這個時候如果中間人也有一個從CA簽出來的證書，而恰好客戶端又沒有做校驗，那么就會被冒名頂替。

而且要明確中間人攻擊的目的是什么？是為了獲得某些利益，不可能只在中間環節搗亂，而獲取不到任何有價值的信息，那么他是沒有必要這么做的。

總結

以上是生活随笔為你收集整理的Https之秘钥交换过程分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。