https原理解析

最近公司分享會講了這塊的內容，於是就學習了一下。

在客戶端和伺服器中作怪的中間人無非做三件事：

竊聽、假冒、篡改

https的出現就是為了防止中間人作怪的。

這裡要引入兩個概念：

想想，兩方通訊若是直接明文傳輸，相當於打**中開著揚聲器，巴拉巴拉，周圍的人都能聽到，有危險的機率不言而喻。

所以我們就要加密，用什麼方法呢，由於非對稱加密的耗時長，耗費資源也大，自然用對稱加密就足夠。兩兩之間擁有只有他們知道的對稱演算法，獲得私鑰，用此來對明文加密後進行傳輸，就是最好的方案了。

那麼怎麼能確定只屬於他們的專屬對稱演算法呢。

隨機數。通過隨機數產生對稱演算法。

那雙方要怎麼溝通好是哪個隨機數呢？

如果這個隨機演算法被中間人捕獲了不就功虧一簣嗎？

那就自然也要對這個數進行加密。用那種加密方式呢？

這裡我們想想，如果也用對稱加密的話，那這個對稱加密的公鑰又是什麼呢？再建立乙個隨機數？那不就死迴圈了嘛？

那這裡我們就得用非對稱加密了。

由伺服器端產生私鑰，然後將公鑰分發給每個向它發出服務請求的客戶端，客戶端產生隨機數，用公鑰加密一下，再反傳送給伺服器端，伺服器端用私鑰進行解密，兩方就都擁有這個由隨機數產生的私鑰了。

這樣就可以保證客戶端傳送給服務端的資訊是安全的，畢竟中間都沒有伺服器的私鑰進行解密，從而後續的對稱加密演算法進行傳輸是安全的。

仔細想想，這個過程還是有問題。

如果伺服器端一開始發的公鑰就是中間人自己建立的，那接下來的對話不就是客戶端和中間人兩方的了嗎？

這裡我們沒法了，必須得有權威的第三方（ca）介入一下，不然兩方永遠也證明不了對面是自己真正想傳輸的。

這個第三方是要有公信力的，通過他的證明，能證明「我是我」，就像身份證的作用一般。第三方機構可以有很多個，但是最上層一定是只有乙個，即root ca，其他的公司若也想成為第三方機構，必須向最上層申請。

於是就引入了數字證書+數字簽名

能在伺服器向客戶端發放公鑰的時候就證明伺服器的資訊，真實性。

客戶端要怎麼驗證這個呢？

答案是證書本身就已經告訴客戶端怎麼驗證證書的真偽。

也就是證書上寫著如何根據證書的內容生成證書編號。客戶端拿到證書後根據證書上的方法自己生成乙個證書編號，如果生成的證書編號與證書上的證書編號相同，那麼說明這個證書是真實的。

可見，其實第三方的這個證書也是加密過的，但是這個解密方法是公布的。是不是和非對稱加密很像。

其實就是這樣的，當伺服器申請證書的時候，第三方會用自己的私鑰加密一下，它的公鑰是公布的，每個瀏覽器都會有，當客戶端收到伺服器發來的這個證書時，會在自己的地方遍歷這個第三方機構的解密演算法來解密，就可以進行下去了。

那我來重新理一下流程

客戶端向伺服器端發出請求

伺服器端有非對稱加密產生的公鑰和私鑰，將自己的私鑰留下，將公鑰和第三方機構用非對稱加密產生的私鑰進行加密的能證明自己身份的數字證書和簽名傳送給客戶端

客戶端檢視到數字證書簽名所屬的第三方機構，用該第三方機構的公鑰進行解密，得知服務端的資訊，即就是自己想要進行請求的一方。然後生成隨機數，這個隨機數用隨機數演算法產生乙個對稱加密的公鑰，再將該公鑰用伺服器端發來的公鑰進行加密，傳送給伺服器端。

伺服器端用自己的私鑰進行解密，拿出對稱加密的公鑰，這樣雙方就都得到了雙方獨有的，協商完畢的公鑰，此後用此公鑰進行內容的加密/解密傳輸即可

參考：