我剛開始使用 Let's Encrypt。 http-01-challenge 很簡單:
- 讓網頁伺服器回應http://example.com
- 向 Let's Encrypt 索取挑戰文件
- 提供以下文件http://example.com/.well-known/acme-challenge
- 接收 example.com 的 TLS 證書
奇蹟般有效。但是他們如何使用不安全的 http 連線來確保我確實是 example.com 的所有者呢?
難道我的資料中心(或我的 ISP)的某些管理員不能只要求憑證並攔截 http 請求,Let's Enrypt 發送來檢查伺服器的身份嗎?
答案1
事實上,沒有針對 HTTP-01 挑戰的中間人攻擊的可靠保護。
能夠攔截 Let's Encrypt 驗證節點和您的伺服器之間流量的人可以通過挑戰並獲得頒發的證書。如果他們能夠實現 BGP 欺騙,他們甚至可能不一定處於正常意義上的中間位置。
這適用於 HTTP-01 質詢,對於未簽署的網域也適用於 DNS-01 質詢。
值得注意的是,這個問題並非Lets Encrypt獨有,傳統CA對DV憑證的驗證也普遍存在同樣的問題;它們通常提供 HTTP、DNS 和電子郵件驗證選項,所有這些選項都容易受到 MITM 攻擊。
什麼讓我們加密有為緩解問題所做的努力,就是從不同資料中心的多個測試節點執行每次驗證,要求所有測試結果一致才能頒發憑證。 (我懷疑這使得他們比大多數傳統 CA 更不易受到此類濫用的影響。)
這至少縮小了可能處於「中間」的範圍,因為「中間」的大部分人在看待時會有所不同來自不同的測試節點。
這都是關於 Let's Encrypt(以及一般 CA)自動域驗證的預設行為,但網域擁有者被賦予了一些額外的控制權,要求公共 CA 必須檢查CAA
記錄。
為了真正取得控制權,網域所有者可以採取以下步驟:
- DNSSEC 對區域進行簽名,以確保
CAA
資料不會被篡改
(在 DNS-01 的情況下也保護質詢本身) - 新增一筆或多筆
CAA
記錄以限制憑證的核發
(特別是CAA
不僅指定允許核發的 CA 的記錄,還指定允許該 CA 的哪個帳戶的記錄)
記錄CAA
看起來像這樣:
example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12346789"
由於冒名頂替者一開始就無法輕易發起挑戰,問題就大大減少了。
請特別注意資料accounturi
中的參數CAA
,這使得策略特定於具有指定 CA 的網域擁有者帳戶。僅指定 CA 但不指定帳戶的
記錄CAA
雖然有效,但幫助有限,因為此類策略仍然允許該 CA 的任何其他客戶要求頒發憑證。
答案2
使用 http 的理由規格中收到 HTTP-01 挑戰時:
由於許多 Web 伺服器以微妙且非直觀的方式將預設 HTTPS 虛擬主機指派給特定的低權限租用戶用戶,因此挑戰必須透過 HTTP 而不是 HTTPS 完成。
此質詢與 ACME 協定訊息不同。該規範強制要求使用 https。 ACME還有正直和重播對其簽名訊息的保護。即使流量被捕獲,危害它的因素也不僅僅是未加密的挑戰。當然,它存在一些風險,但是更好的網域驗證程式的替代方案是什麼?
監控未經授權的證書的更完整方法可能涉及證書透明度。在 CT 日誌上搜尋您的姓名或設定警報。頒發 CA、序號和日期都應該是熟悉的。