我們先不去探究ssl的實現原理，我們先從設計者的角度去思考如何去建立一個安全的傳輸通道?

從第一個消息開始?

客戶端A向服務端B發送一條消息，這個消息可能會被攔截以及篡改，我們如何做到A發送給B的數據包，及時被攔截了，也沒辦法得知消息內容并且也不能查看呢？?

利用對稱加密?

要做到消息不能被第三方查看以及篡改，那么第一想法就是對內容進行加密，同時，該消息還需要能被服務端進行解密。所以我們可以使用對稱加密算法來實現，密鑰S扮演著加密和解密的角色。在密鑰S不公開的情況下，就可以保證安全性？?

沒那么簡單?

在互聯網世界，通信不會這么簡單，也許是這樣。?

會存在多個客戶端和服務端產生連接，而這個客戶端也許是一個潛伏者，如果他也有對稱密鑰S，那相當于上面的方案是不可行的？如果服務端和每個客戶端通信的時候使用不同的加密算法呢？?

似乎能夠完美解決問題，然后？密鑰如何分配呢？也就是服務端怎么告訴客戶端該使用那種對稱加密算法呢？
解決辦法似乎只能通過建立會話以后進行協商了？?

協商過程又是不安全的?

協商過程，意味著又是基于一個網絡傳輸的情況下去動態分配密鑰，可是這個協商過程又是不安全的，怎么破？?

非對稱加密出馬?

非對稱加密算法的特點是：私鑰加密后的密文，只要有公鑰，都能解密，但是公鑰加密后的密文，只有私鑰可以解密。私鑰只有一個人有，而公鑰可以發給所有人?

這樣就可以保證A/B向服務器端方向發送的消息是安全的。似乎我們通過非對稱加密算法解決了密鑰的協商的問題？但是?

公鑰怎么拿？?

使用非對稱加密算法，那么如何讓A、B客戶端安全地持有公鑰？?

那么我們逐步思考，有兩種我們能想到的方案：?

1. 服務器端將公鑰發送給每一個客戶端?

2. 服務器端將公鑰放到一個遠程服務器，客戶端可以請求到 （多了一次請求，還得解決公鑰放置問題）?

方案一
似乎不可行，因為，傳輸過程又是不安全的？公鑰可能會被調包?

引入第三方機構?

到上面這一步，最關鍵的問題是，客戶端如何知道給我公鑰的是黃蓉還是小龍女？只能找本人去證實？或者有一個第三者來幫你證實，并且第三者是絕對公正的。?

所以，引入一個可信任的第三者是一個好的方案?服務端把需要傳遞給客戶端的公鑰，通過第三方機構提供的私鑰對公鑰內容進行加密后，再傳遞給客戶端？?通過第三方機構私鑰對服務端公鑰加密以后的內容，就是一個簡陋版本的“數字證書”。這個幀數中包含【服務器公鑰】

?客戶端拿到這個證書以后，因為證書是第三方機構使用私鑰加密的。客戶端必須要有第三方機構提供的公鑰才能解密證書。這塊又涉及到第三方機構的公鑰怎么傳輸？（假設是先內置在系統中）以及還有一個問題，第三方機構頒發的證書是面向所有用戶，不會只針對一家發放。如果不法分子也去申請一個證書呢？?

如果不法分子也拿到證書？?

如果不法分子也申請了證書，那它可以對證書進行調包。客戶端在這種情況下是無法分辨出收到的是你的證書，還是中間人的。因為不論是中間人的、還是你的證書?

都能使用第三方機構的公鑰進行解密。?

?

驗證證書的有效性?

事情發展到現在，問題演變成了，客戶端如何識別證書的真偽？在現實生活中，要驗證一個東西的真偽，絕大部分都是基于編號去驗證（比如大學畢業證書，比如買的數碼產品是否是山寨），我之前講過，計算機領域的解決方案都是人為去實現的，所以在這里，解決方案也是一樣，如果給這個數字證書添加一個證書編號？是不是就能達到目的呢？?

證書上寫了如何根據證書的內容生成證書編號。客戶端拿到證書后根據證書上的方法自己生成一個證書編號，如果生成的證書編號與證書上的證書編號相同，那么說明這個證書是真實的。這塊有點類似于md5的驗證，我們下載一個軟件包，都會提供一個md5的值，我們可以拿到這個軟件包以后通過一個第三方軟件去生成一個md5值去做比較，是不是一樣如果一樣表示這個軟件包沒被篡改過?

對服務端的數據進行MD5算法得到一個MD5的值，生成證書編號，使用第三方機構的私鑰對這個證書編號進行加密，并且會在證書中添加證書編號的生成算法?

瀏覽器內置的CA公鑰可以解密服務端CA私鑰加密的證書，通過瀏覽器內置的CA證書的證書編號算法對服務端返回的證書編號進行驗簽?

第三方機構的公鑰證書存哪里？?

瀏覽器和操作系統都會維護一個權威的第三方機構列表（包括他們的公鑰）?

因為客戶端接收到的證書中會些頒發機構，客戶端就根據這個辦法機構的值在本地找到響應的公鑰?
說到這里，我想大家一定知道，證書就是HTTPS中的數字證書，證書編號就是數字簽名，而第三方機構就是數字證書的簽發機構（CA）?

?

總結

以上是生活随笔為你收集整理的逆向推导https的设计过程的全部內容，希望文章能夠幫你解決所遇到的問題。

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