Https 與對稱加密和非對稱加密

總結沒有 https，使用者傳輸的資料，如賬號密碼，會被不法分子截獲。

客戶端請求一次服務端後，服務端給客戶端乙個金鑰。然後他們傳輸的資料會用金鑰加密。

但第一次告訴客戶端金鑰的時候也可能被不法分子截獲。

服務端有自己的公鑰和私鑰。客戶端請求一次服務端後，服務端提供自己的公鑰，客戶端（瀏覽器）收到後自己生成乙個金鑰用服務端傳來的公鑰加密再傳給服務端。然後服務端再用私鑰解密。這樣它們就可以進行上面的對稱加密傳輸了。

這樣解決了在第一次服務端向客戶端做出響應的過程中，不法分子擷取到金鑰的漏洞。

但是，不法分子可以截獲服務端發來的公鑰，然後向客戶端傳送自己的公鑰。然後，客戶端要傳給服務端的就是不法分子的公鑰加密的金鑰。不法分子再次截獲，用自己的私鑰解密，拿到金鑰，再用之前截獲的公鑰加密傳給服務端。這樣一來，有了用於對稱加密的金鑰，以後就可以隨意竊取資訊了。

證書裡面大概有些什麼內容呢？

證書頒發機構的資訊、服務端資訊、機構私鑰加密的服務端公鑰、機構私鑰加密的證書簽名等，如下圖（簡化）：

其中，證書簽名是基於服務端資訊生成的。

關於公鑰、私鑰補充一點：可以用公鑰加密、私鑰解密，也可以用私鑰加密、公鑰解密。

服務端提交自己的網域名稱就可以找 ca 購買證書了。

客戶端發出第一次請求之後，服務端返回給客戶端乙個證書。客戶端接著會驗證證書真偽，如何驗證？

其實，各大瀏覽器和作業系統本身已經維護了所有權威 ca 的名稱和公鑰。

所以客戶端從證書中得知是哪個機構頒發的證書以後，可以從本地找到對應的機構公鑰，這樣就可以解密出證書簽名和服務端公鑰。

客戶端通過證書簽名生成規則自己生成乙個證書簽名與解密出的證書簽名對比，如果一致，就可以拿服務端公鑰加密會話金鑰了。到此，後面的過程就和之前差不多了。

因為客戶端只維護了權威機構的公鑰，所以不法分子也無可奈何了。

可以看出，在有了會話用對稱加密的點子後，後面的優化，都是針對第一次服務端向客戶端的傳輸可能會被截獲的情形。

ca 相當於在兩端事先安排好了一組公鑰和私鑰，這樣就打破了第一次傳輸總是透明的瓶頸。