HTTPS協議互動過程

在https協議中，第一步a作為客戶端去獲取b作為**的公鑰(b-public-key)。

怎麼獲取？如果我們認為網路不可信，那麼我們就需要找乙個可信的中間人，第三方權威機構g，由它來證明，我們**b返回客戶端a的公鑰(b-public-key)，的確來自於b，中間沒有被其他人篡改。

這意味著**b不能直接返回自己的公鑰(b-public-key)給客戶端a，而是需要返回由權威機構g做了數字簽名的公證書(簡稱數字證書)，裡面記錄了**b的網域名稱，和對應的公鑰(b-public-key), 還有證書的頒發人g的代號。

這張數字證書的在作用是什麼？最重要的並不是它怎麼在網路上傳遞。而是它記錄了這樣的乙個事實:網域名稱domain對應的公鑰是b-public-key, 它是由權威機構g做出的公證，因為上面有g的數字簽名。

所以這張數字證書並不需要臨時生成，而是提前在**部署時就已經生成好了，而且也可以隨意傳遞給任何人，因為它是完全公開的資訊。

當然這裡還有乙個前提，我們客戶端a已經擁有第三方權威機構g的公鑰(g-public-key)了。整個過程如下:

* 客戶端a向**b請求**的數字證書。

* **b返回它的數字證書。

* 客戶端a收到數字證書，用g-public-key驗證該數字證書的確由權威機構g認證，於是選擇相信證書裡面的(domain, public-key)

資訊。* 客戶端a檢查證書中的domain, 和我們要訪問的**b網域名稱是否一致。如果不一致，那麼說明數字證書雖然是真的，但是是別人

找權威機構g認證的其他網域名稱的證書，於是會話結束; 如果一致，於是相信證書中的public-key就是**b的公鑰(b-public-key)。

但是，https並不能完全解決釣魚問題。它假設使用者對要訪問地**網域名稱(domain)可靠性由自己地判斷力。

這當然並不全是事實。所以，高階一點的瀏覽器，它會簡歷不靠譜**網域名稱的資料庫，在使用者訪問這些**時進行風險提示。