https 真的安全嗎？可以抓包嗎？如何防止抓包嗎？

作者：廢柴程序員
鏈接：https://www.jianshu.com/p/54ae53f17602

背景

我們知道，http 通信存在以下問題：

使用 https 可以解決數據安全問題，但是你真的理解 https 嗎？

當面試官連續對你發出靈魂追問的時候，你能對答如流嗎

  1. 什麼是 https，爲什麼需要 https

  2. https 的連接過程

  3. https 的加密方式是怎樣的，對稱加密和非對稱加密，爲什麼要這樣設計？內容傳輸爲什麼要使用對稱機密

  4. https 是絕對安全的嗎

  5. https 可以抓包嗎

如果你能對答自如，恭喜你，https 你已經掌握得差不多了，足夠應付面試了。

什麼是 https

簡單來說， https 是 http + ssl，對 http 通信內容進行加密，是 HTTP 的安全版，是使用 TLS/SSL 加密的 HTTP 協議

Https 的作用：

  1. 內容加密 建立一個信息安全通道，來保證數據傳輸的安全；

  2. 身份認證 確認網站的真實性

  3. 數據完整性 防止內容被第三方冒充或者篡改

什麼是 SSL

SSL 由 Netscape 公司於 1994 年創建，它旨在通過 Web 創建安全的 Internet 通信。它是一種標準協議，用於加密瀏覽器和服務器之間的通信。它允許通過 Internet 安全輕鬆地傳輸賬號密碼、銀行卡、手機號等私密信息。

SSL 證書就是遵守 SSL 協議，由受信任的 CA 機構頒發的數字證書。

SSL/TLS 的工作原理:

需要理解 SSL/TLS 的工作原理，我們需要掌握加密算法。加密算法有兩種：對稱加密和非對稱加密：

對稱加密：通信雙方使用相同的密鑰進行加密。特點是加密速度快，但是缺點是需要保護好密鑰，如果密鑰泄露的話，那麼加密就會被別人 pojie。常見的對稱加密有 AES，DES 算法。

非對稱加密：它需要生成兩個密鑰：公鑰 (Public Key) 和私鑰(Private Key)。

公鑰顧名思義是公開的，任何人都可以獲得，而私鑰是私人保管的。相信大多程序員已經對這種算法很熟悉了：我們提交代碼到 github 的時候，就可以使用 SSH key：在本地生成私鑰和公鑰，私鑰放在本地. ssh 目錄中，公鑰放在 github 網站上，這樣每次提交代碼，不用麻煩的輸入用戶名和密碼了，github 會根據網站上存儲的公鑰來識別我們的身份。

公鑰負責加密，私鑰負責解密；或者，私鑰負責加密，公鑰負責解密。這種加密算法安全性更高，但是計算量相比對稱加密大很多，加密和解密都很慢。常見的非對稱算法有 RSA。

https 的連接過程

https 的連接過程大概分爲兩個階段，證書驗證階段和數據傳輸階段

證書驗證階段

大概分爲三個步驟

  1. 瀏覽器發起請求

  2. 服務器接收到請求之後，會返回證書，包括公鑰

  3. 瀏覽器接收到證書之後，會檢驗證書是否合法，不合法的話，會彈出告警提示（怎樣驗證合法，下文會詳細解析，這裏先忽略）

數據傳輸階段

證書驗證合法之後

  1. 瀏覽器會生成一個隨機數，

  2. 使用公鑰進行加密，發送給服務端

  3. 服務器收到瀏覽器發來的值，使用私鑰進行解密

  4. 解析成功之後，使用對稱加密算法進行加密，傳輸給客戶端

之後雙方通信就使用第一步生成的隨機數進行加密通信。

https 的加密方式是怎樣的，對稱加密和非對稱加密，爲什麼要這樣設計

從上面我們可以知道，https 加密是採用對稱加密和非對稱機密一起結合的。

在證書驗證階段，使用非對稱加密。
在數據傳輸階段，使用對稱機密。

這樣設計有一個好處，能最大程度得兼顧安全效率。

在證書驗證階段，使用非對稱加密，需要公鑰和私鑰，假如瀏覽器的公鑰泄漏了，我們還是能夠確保隨機數的安全，因爲加密的數據只有用私鑰才能解密。這樣能最大程度確保隨機數的安全。

在內容傳輸階段，使用對稱機密，可以大大提高加解密的效率。

內容傳輸爲什麼要使用對稱機密

  1. 對稱加密效率比較高

  2. 一對公私鑰只能實現單向的加解密。只有服務端保存了私鑰。如果使用非對稱機密，相當於客戶端必須有自己的私鑰，這樣設計的話，每個客戶端都有自己的私鑰，這很明顯是不合理的，因爲私鑰是需要申請的。

https 是絕對安全的嗎

不是絕對安全的，可以通過中間人攻擊。

什麼是中間人攻擊

中間人攻擊是指攻擊者與通訊的兩端分別創建獨立的聯繫，並交換其所收到的數據，使通訊的兩端認爲他們正在通過一個私密的連接與對方直接對話，但事實上整個會話都被攻擊者完全控制。

HTTPS 使用了 SSL 加密協議，是一種非常安全的機制，目前並沒有方法直接對這個協議進行攻擊，一般都是在建立 SSL 連接時，攔截客戶端的請求，利用中間人獲取到 CA 證書、非對稱加密的公鑰、對稱加密的密鑰；有了這些條件，就可以對請求和響應進行攔截和篡改。

過程原理：

  1. 本地請求被劫持（如 DNS 劫持等），所有請求均發送到中間人的服務器

  2. 中間人服務器返回中間人自己的證書

  3. 客戶端創建隨機數，通過中間人證書的公鑰對隨機數加密後傳送給中間人，然後憑隨機數構造對稱加密對傳輸內容進行加密傳輸

  4. 中間人因爲擁有客戶端的隨機數，可以通過對稱加密算法進行內容解密

  5. 中間人以客戶端的請求內容再向官方網站發起請求

  6. 因爲中間人與服務器的通信過程是合法的，官方網站通過建立的安全通道返回加密後的數據

  7. 中間人憑藉與官方網站建立的對稱加密算法對內容進行解密

  8. 中間人通過與客戶端建立的對稱加密算法對官方內容返回的數據進行加密傳輸

  9. 客戶端通過與中間人建立的對稱加密算法對返回結果數據進行解密

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

https 是如何防止中間人攻擊的

https 無法防止中間人攻擊，只有做證書固定 ssl-pinning 或者 apk 中預置證書做自簽名驗證可以防中間人攻擊

瀏覽器是如何確保 CA 證書的合法性？
一、證書包含什麼信息？

頒發機構信息、公鑰、公司信息、域名、有效期、指紋……

二、證書的合法性依據是什麼？

首先，權威機構是要有認證的，不是隨便一個機構都有資格頒發證書，不然也不叫做權威機構。另外，證書的可信性基於信任制，權威機構需要對其頒發的證書進行信用背書，只要是權威機構生成的證書，我們就認爲是合法的。所以權威機構會對申請者的信息進行審覈，不同等級的權威機構對審覈的要求也不一樣，於是證書也分爲免費的、便宜的和貴的。

三、瀏覽器如何驗證證書的合法性？

瀏覽器發起 HTTPS 請求時，服務器會返回網站的 SSL 證書，瀏覽器需要對證書做以下驗證：

驗證域名、有效期等信息是否正確。證書上都有包含這些信息，比較容易完成驗證；
判斷證書來源是否合法。每份簽發證書都可以根據驗證鏈查找到對應的根證書，操作系統、瀏覽器會在本地存儲權威機構的根證書，利用本地根證書可以對對應機構簽發證書完成來源驗證；
判斷證書是否被篡改。需要與 CA 服務器進行校驗；
判斷證書是否已吊銷。通過 CRL（Certificate Revocation List 證書註銷列表）和 OCSP（Online Certificate Status Protocol 在線證書狀態協議）實現，其中 OCSP 可用於第 3 步中以減少與 CA 服務器的交互，提高驗證效率。
以上任意一步都滿足的情況下瀏覽器才認爲證書是合法的。

https 可以抓包嗎

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

但是，我們可以通過抓包工具來抓包。它的原理其實是模擬一箇中間人。

通常 HTTPS 抓包工具的使用方法是會生成一個證書，用戶需要手動把證書安裝到客戶端中，然後終端發起的所有請求通過該證書完成與抓包工具的交互，然後抓包工具再轉發請求到服務器，最後把服務器返回的結果在控制檯輸出後再返回給終端，從而完成整個請求的閉環。

有人可能會問了，既然 HTTPS 不能防抓包，那 HTTPS 有什麼意義？

HTTPS 可以防止用戶在不知情的情況下通信鏈路被監聽，對於主動授信的抓包操作是不提供防護的，因爲這個場景用戶是已經對風險知情。要防止被抓包，需要採用應用級的安全防護，例如採用私有的對稱加密，同時做好移動端的防反編譯加固，防止本地算法被 pojie。

擴展

如何防止抓包？

對於 HTTPS API 接口，如何防止抓包呢？既然問題出在證書信任問題上，那麼解決方法就是在我們的 APP 中預置證書。在 TLS/SSL 握手時，用預置在本地的證書中的公鑰校驗服務器的數字簽名，只有簽名通過才能成功握手。由於數字簽名是使用私鑰生成的，而私鑰只掌握在我們手上，中間人無法僞造一個有效的簽名，因此攻擊失敗，無法抓包。

同時，爲了防止預置證書被替換，在證書存儲上，可以將證書進行加密後進行「嵌入存儲」，如嵌入在圖片中或一段語音中。這涉及到信息隱寫的領域，這個話題我們有空了詳細說。

預置證書 / 公鑰更新問題

這樣做雖然解決了抓包問題，但是也帶來了另外一個問題：我們購買的證書都是有有效期的，到期前需要對證書進行更新。主要有兩種方式：

提供預置證書更新接口。在當前證書快過期時，APP 請求獲取新的預置證書，這過渡時期，兩個證書同時有效，直到安全完成證書切換。這種方式有一定的維護成本，且不易測試。
在 APP 中只預埋公鑰，這樣只要私鑰不變，即使證書更新也不用更新該公鑰。但是，這樣不太符合週期性更新私鑰的安全審計需求。一個折中的方法是，一次性預置多個公鑰，只要任意一個公鑰驗證通過即可。考慮到我們的證書一般購買週期是 3-5 年，那麼 3 個公鑰，可以使用 9-15 年，同時，我們在此期間還可以發佈新版本廢棄老公鑰，添加新公鑰，這樣可以使公鑰一直更新下去。

小結

開頭說到的幾個問題，你能對答如流了嗎

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/_K3UohfiVS-531JrdhLIxQ

猜你喜歡