大廠面試：HTTPS三連問，最後一問難道很多人

大家好，我是專門跟大家分享乾貨的老田。另外，需要面試資料的朋友，記得後台回覆面試

前言

大家都知道HTTPS 比HTTP 安全，也聽過與HTTPS 協定相關的概念有SSL 、非對稱加密、 CA 憑證等。

但對於以下靈魂三拷問可能就答不上了：

• 為什麼用了 HTTPS 就是安全的？
• HTTPS 的底層原理如何實現？
• 用了 HTTPS 就一定安全嗎？

本文將層層深入，從原理上把 HTTPS 的安全性講透。

HTTPS 的實作原理

大家可能都聽過HTTPS 協定之所以是安全的是因為HTTPS協定會對傳輸的資料進行加密，而加密過程是使用了非對稱加密實作。

但其實，HTTPS 在內容傳輸的加密上使用的是對稱加密，非對稱加密只作用在憑證驗證階段。

HTTPS 的整體流程分為憑證驗證和資料傳輸階段，具體的互動過程如下：

img

憑證驗證階段：

• 瀏覽器發起HTTPS 請求。
• 服務端傳回 HTTPS 憑證。
• 用戶端驗證憑證是否合法，如果不合法則提示警告。

資料傳輸階段：

• 當憑證驗證合法後，在本地產生隨機數。
• 透過公鑰加密隨機數，並把加密後的隨機數傳送到服務端。
• 服務端透過私鑰對隨機數進行解密。
• 服務端透過客戶端傳入的隨機數建構對稱加密演算法，將傳回結果內容加密後傳輸。

為什麼資料傳輸是用對稱加密？

首先，非對稱加密的加解密效率是非常低的，而HTTP 的應用場景中通常端與端之間存在大量的交互，非對稱加密的效率是無法接受的。

另外，在HTTPS 的場景中只有服務端保存了私鑰，一對公私鑰只能實現單向的加解密，所以HTTPS 中內容傳輸加密採取的是對稱加密，而不是不對稱加密。

為什麼需要 CA 認證機構頒發憑證？

HTTP 協定被認為不安全是因為傳輸過程容易被監聽者勾線監聽、偽造伺服器，而HTTPS 協定主要解決的便是網路傳輸的安全性問題。

首先我們假設不存在認證機構，任何人都可以製作證書，這帶來的安全風險便是經典的「中間人攻擊」問題。

「中間人攻擊」的具體過程如下：

#過程原理如下：

• #本地請求被劫持（如DNS 劫持等），所有請求都發送到中間人的伺服器。
• 中間人伺服器傳回中間人自己的憑證。
• 客戶端建立隨機數，透過中間人憑證的公鑰將隨機數加密後傳送給中間人，然後憑隨機數建構對稱加密對傳輸內容進行加密傳輸。
• 中間人因為擁有客戶端的隨機數，可以透過對稱加密演算法進行內容解密。
• 中間人以客戶端的請求內容再向正規網站發起請求。
• 因為中間人與伺服器的通訊過程是合法的，正規網站透過建立的安全通道傳回加密後的資料。
• 中間人憑藉著與正規網站建立的對稱加密演算法對內容進行解密。
• 中間人透過與客戶端建立的對稱加密演算法對正規內容傳回的資料進行加密傳輸。
• 客戶端透過與中間人建立的對稱加密演算法對傳回結果資料進行解密。

由於缺少對憑證的驗證，所以客戶端雖然發起的是 HTTPS 請求，但客戶端完全不知道自己的網路已被攔截，傳輸內容被中間人全部竊取。

瀏覽器是如何確保 CA 憑證的合法性？

憑證包含什麼資訊？

憑證包含資訊如下：

• 頒發機構資訊
• #公鑰
• #公司資訊
• 網域名稱
• 有效期限
• 指紋
• ...

憑證的合法性依據是什麼？

首先，權威機構是要有認證的，不是隨便一個機構都有資格頒發證書，不然也不叫做權威機構。

另外，證書的可信性是基於信任制，權威機構需要對其頒發的證書進行信用背書，只要是權威機構產生的證書，我們就認為是合法的。

所以權威機構會對申請者的資訊進行審核，不同等級的權威機構對審核的要求也不一樣，於是證書也分為免費的、便宜的和貴的。

瀏覽器如何驗證憑證的合法性？

瀏覽器發起 HTTPS 請求時，伺服器會傳回網站的 SSL 憑證。

瀏覽器需要對憑證做以下驗證：

• 驗證網域、有效期限等資訊是否正確。證書上都有包含這些信息，比較容易完成驗證。
• 判斷憑證來源是否合法。每份簽發證書都可以根據驗證鏈查找到對應的根證書，作業系統、瀏覽器會在本地儲存權威機構的根證書，利用本地根證書可以對對應機構簽發證書完成來源驗證。

• #**判斷憑證是否被竄改。 **需要與 CA 伺服器進行校驗。

• **判斷憑證是否已撤銷。 **透過 CRL（Certificate Revocation List 憑證登出清單）和 OCSP（Online Certificate Status Protocol 線上憑證狀態協定）實作。

  其中 OCSP 可用於步驟 3 中以減少與 CA 伺服器的交互，提高驗證效率。

以上任一步驟都滿足的情況下瀏覽器才認為憑證是合法的。

**這裡插一個我想了很久的但其實答案很簡單的問題：**既然證書是公開的，如果要發起中間人攻擊，我在官網上下載一份證書作為我的服務器證書，那客戶端一定會認同這個證書是合法的，如何避免這種證書冒用的情況？

其實這就是非加密對稱中公私鑰的用處，雖然中間人可以得到證書，但私鑰是無法取得的。

一份公鑰是不可能推算出其對應的私鑰，中間人即使拿到憑證也無法偽裝成合法服務端，因為無法對客戶端傳入的加密資料進行解密。

只有認證機構可以產生憑證嗎？

如果需要瀏覽器不提示安全性風險，那隻能使用認證機構簽發的憑證。

但瀏覽器通常只是提示安全風險，並不限制網站不能訪問，所以從技術上誰都可以生成證書，只要有證書就可以完成網站的 HTTPS 傳輸。

例如早期的 12306 採用的便是手動安裝私有憑證的形式實作 HTTPS 存取。

本機隨機數被竊取怎麼辦？

證書驗證是採用非對稱加密實現，但是傳輸過程是採用對稱加密，而其中對稱加密演算法中重要的隨機數字是由本地生成並且存儲於本地的，HTTPS 如何保證隨機數不會被竊取？

其實HTTPS 不包含對隨機數的安全保證，HTTPS 保證的只是傳輸過程安全，而隨機數儲存於本地，本地的安全屬於另一安全範疇，應對的措施有安裝防毒軟體、反木馬、瀏覽器升級修復漏洞等。

用了 HTTPS 會被抓到嗎？

HTTPS 的資料是加密的，常規下抓包工具代理請求後抓到的包內容是加密狀態，無法直接查看。

但是，如前文所說，瀏覽器只會提示安全風險，如果使用者授權仍可繼續造訪網站，完成請求。

因此，只要客戶端是我們自己的終端，我們授權的情況下，便可以組成中間人網絡，而抓包工具便是作為中間人的代理。

通常 HTTPS 抓包工具的使用方法是會產生一個證書，用戶需要手動把證書安裝到客戶端中，然後終端機發起的所有請求透過該證書完成與抓包工具的交互。

然後抓包工具再轉送請求到伺服器，最後把伺服器回傳的結果在控制台輸出後再回傳給終端，從而完成整個請求的閉環。

既然 HTTPS 不能防抓包，那 HTTPS 有什麼意義？ HTTPS 可防止使用者在不知情的情況下通訊連結被監聽，對於主動授信的抓包操作是不提供防護的，因為這個場景使用者已經對風險知情。

要防止被抓包，需要採用應用級的安全防護，例如採用私有的對稱加密，同時做好行動端的防反編譯加固，防止本地演算法被破解。

總結

以下以簡短的Q&A 形式進行全文總結：

Q：HTTPS 為什麼安全？

A：因為 HTTPS 保證了傳輸安全，防止傳輸程序被監聽、防止資料被竊取，可以確認網站的真實性。

Q：HTTPS 的傳輸過程是怎麼樣的？

A：客戶端發起 HTTPS 請求，服務端返回證書，客戶端對證書進行驗證，驗證透過後本地生成用於改造對稱加密演算法的隨機數。

透過憑證中的公鑰對隨機數進行加密傳輸到服務端，服務端接收後透過私鑰解密得到隨機數，之後的資料互動透過對稱加密演算法進行加解密。

Q：為什麼需要憑證？

A：防止「中間人」攻擊，同時可以為網站提供身分證明。

Q：使用 HTTPS 會被抓到嗎？

A：會被抓包，HTTPS 只防止用戶在不知情的情況下通信被監聽，如果用戶主動授信，是可以構建“中間人”網絡，代理軟體可以對傳輸內容進行解密。

順手分享一張學習 HTTPS 的流程圖：

以上是大廠面試：HTTPS三連問，最後一問難道很多人的詳細內容。更多資訊請關注PHP中文網其他相關文章！