CLIENTcertkeySERVERcertkeyclient certserver certboth sides authenticated cryptographically

相互 TLS (mTLS)

11 最小閱讀量密碼學

標準 HTTPS 向客戶端驗證伺服器 — 瀏覽器驗證伺服器的憑證。相互 TLS 則相反：客戶端也提供一個證書，伺服器會驗證該證書。結果是連接雙方的加密身份驗證。 mTLS 日益成為現代架構中服務到服務身分驗證的標準。

完整的文章正文以英文提供如下。

相互 TLS (mTLS) 透過要求用戶端提供伺服器驗證的憑證來擴充標準 TLS。握手完成後，雙方都以加密方式相互驗證。與基於密碼或令牌的身份驗證相比，mTLS 提供更強大的身份保證、證書生命週期內的自動憑證輪換以及消除共享秘密分發問題。

握手差異

在標準 TLS 中，客戶端根據信任儲存驗證伺服器的憑證。伺服器不以加密方式對客戶端進行身份驗證 - 它依賴應用程式層機制（cookie、不記名令牌、基本身份驗證）。

在 mTLS 中，伺服器在 TLS 握手期間新增一個憑證請求。客戶端必須使用自己的憑證以及證明擁有私鑰的簽章進行回應。伺服器根據其自己的信任儲存來驗證客戶端憑證。如果驗證失敗，連線就會斷開。

部署 mTLS 的地方

  • Microservices. Istio、Linkerd 和 Consul Connect 等服務網格框架使用 mTLS 進行服務到服務驗證。每個微服務都有一個標識其身分的憑證；網格強制誰可以呼叫誰。
  • API 閘道。 內部 API 越來越需要客戶端憑證而不是 API 金鑰。更強的身份，透過短期證書自動輪換。
  • VPN 和零信任產品。 Cloudflare Access、Tailscale、BeyondCorp 使用裝置憑證進行驗證。
  • 政府和金融 API。 開放銀行、FedRAMP 相容系統、軍事 API 經常強制要求mTLS.
  • IoT. 每設備憑證為車隊管理建立身分。 AWS IoT、Azure IoT Hub、Google Cloud IoT 皆使用 mTLS。
  • WebHooks 和 B2B 整合。 安全性更高的 Webhook 交付透過憑證驗證雙方。

為什麼 mTLS 優於密碼或令牌

  • 無共享Secrets. 每一方都只有自己的私鑰。一側儲存的洩漏不會暴露另一側。
  • 強身分。 憑證驗證持有者控制相應的私鑰，該私鑰由受信任的 CA 綁定到已驗證的身份。
  • 自動輪換。 短期憑證（幾小時到幾天）限制任何憑證的視窗妥協。
  • 沒有密碼重複使用。 每個服務都有自己的憑證；沒有跨服務重複使用密碼的概念。
  • 沒有重播。 如果沒有私鑰，憑證本身是沒有用的，私鑰永遠不會移動。
  • 內建加密相互身份驗證。 握手期間雙方在單次往返中相互驗證。

如何取得憑證所頒發的

mTLS 部署故事圍繞著憑證授權：

  • Internal PKI. 該組織運作自己的憑證授權單位。每個服務或用戶端都會獲得該 CA 所頒發的憑證。信任是內部的。
  • SPIFFE / SPIRE. 雲端原生身分框架。向由 URI 樣式識別碼標識的工作負載頒發短期憑證。服務網格使用此模式。
  • HashiCorp Vault。 Vault 可以充當內部 mTLS 的 CA，按需向經過驗證的工作負載頒發短期憑證。
  • Step CA /smallstep。 供內部使用的開源 ACME 樣式憑證授權單位。降低操作複雜度。
  • 公共 CA。 對於雙方都需要全球可信身分的 B2B mTLS，商業 CA 頒發 mTLS 憑證。

操作挑戰

mTLS 不是免費的：

  • 證書管理。 每個用戶端都需要一個證書，在需要時頒發、輪換、吊銷。 PKI 成為關鍵基礎設施。
  • Distribution. 安全地向正確的客戶端取得憑證 — 引導是一個反覆出現的問題。
  • 調試. mTLS 故障比密碼故障更難調試。工具和可觀察性很重要。
  • Library 支援。 大多數現代 HTTP 庫都支援 mTLS，但配置比基本驗證更複雜。
  • 瀏覽器限制。 瀏覽器對 mTLS 的支援存在（客戶端憑證提示），但很尷尬； Web 上下文中的 mTLS 在伺服器到伺服器上比瀏覽器到伺服器更常見。

服務網格中的 mTLS

現代用例的標題。像 Istio 這樣的服務網格：

  1. 每個服務都會獲得一個工作負載身分（SPIFFE ID）。
  2. 網格的控制平面頒發短期證書（通常有效幾個小時）。
  3. Sidecar代理程式（Envoy）處理應用程式的 mTLS - 應用程式與本機進行簡單的HTTP對話；sidecar 將其包裝在 mTLS 中以用於網路出口。
  4. 接收方的 sidecar 終止 mTLS，驗證來源身份，並將純 HTTP 轉送到目標應用程式。
  5. P策略規定哪些工作負載可以呼叫哪些工作負載 — 根據憑證身分在 sidecar 上強制執行。

應用程式無需更改任何程式碼即可獲得基於身分的強大身份驗證。網格處理所有憑證和加密操作複雜性。

mTLS 與 API 的 OAuth/OIDC

兩種不同的驗證模型：

  • OAuth/OIDC — 基於不記名代幣。令牌包含身份聲明。如果未綁定到客戶端，令牌可能會被洩漏和重播。
  • mTLS — 基於憑證。如果沒有私鑰，僅憑證是沒有用的。更強的身份保證。

對於內部服務到服務的身份驗證，mTLS 越來越受到青睞。對於使用者導向的身份驗證，OAuth/OIDC 仍然是標準。混合方法（帶有令牌綁定的 OAuth、mTLS 綁定的 OAuth 令牌）結合了這些優點。

對於開發人員

將 mTLS 新增至堆疊涉及：

  • 設定 CA（步驟 CA是入門時最友善的開源選項）
  • 向客戶端頒發憑證和伺服器
  • 將伺服器設定為需要客戶端憑證
  • 將客戶端配置為提供證書
  • 處理證書輪換（透過內部CA的ACME等效項自動執行）

在過去5年中，進入門檻已顯著下降。 mTLS 現在對於小型團隊來說在操作上是可行的；以前它主要是擁有專用安全基礎設施的企業的領域。

常見問題

mTLS 對於我的應用程式來說是不是太過分了？
取決於場景。對於面向使用者的 Web 應用程序，OAuth/OIDC 通常是正確的。對於微服務中的內部 API 和服務到服務流量，mTLS 正在成為標準。對於高安全性 B2B 集成，mTLS 通常是正確的答案。
mTLS 和 TLS 用戶端身份驗證有什麼不同？
一樣的東西，不同的名字。 TLS 用戶端身份驗證是協定功能； mTLS 是使用它的常用術語。它們指的是相同的機制。
瀏覽器支援 mTLS 嗎？
是的 - 當伺服器請求客戶端憑證時，它們會提示使用者。使用者體驗很差；使用者覺得很混亂。 mTLS 在瀏覽器中可以使用，但對於消費者應用程式來說很少見。具有員工頒發的設備證書的企業應用程式更常使用它。
mTLS 憑證的生命週期應該要多短？
對於服務網格中的工作負載身份，通常需要數小時到數天。旋轉是自動的；較短的使用壽命限制了妥協的影響。對於長期運行的 B2B 身份，需要幾天到幾週的時間。公共 CA 頒發的憑證遵循較長的週期（目前最長為 397 天）。
我可以撤銷 mTLS 憑證嗎？
是的，透過 CRL（憑證撤銷清單）或 OCSP（線上憑證狀態協定）。短期證書部分消除了這種需求——無論如何，當證書在數小時內到期時，撤銷的重要性就不那麼重要了。大多數現代 mTLS 部署依賴較短的生命週期而不是主動撤銷。
相互 TLS (mTLS) 解釋：當客戶端也有憑證時