別使用 Let's Encrypt (2019) （★ 83 分）
Michael Orlitzky 在「Let's Not Encrypt」一文中，質疑 Let's Encrypt (LE) 與其他憑證授權中心 (Certificate Authority, CA) 一樣，僅透過在網頁根目錄放置驗證檔案，藉由 HTTP (超文本傳輸協定) 存取確認網站所有權；若真有中間人攻擊 (Man-in-the-Middle, MITM) 即可攔截此驗證，讓攻擊者自行簽發憑證。作者強調 LE 憑證無法阻擋最關鍵的攻擊，且從全球百餘家信任 CA 中，任何一方都可冒名頂替，所謂安全保證形同虛設。
他進一步抨擊 LE 的自動化更新機制：官方工具 certbot 必須以 root 權限下載陌生主機簽發的憑證並安裝進伺服器，恐將惡意或錯誤內容推入，甚至癱瘓服務；而手動更新雖可避此風險，短至三個月的憑證有效期卻讓網站營運者終身被迫持續投入時間。更甚者，一旦切換到 HTTPS (超文本傳輸安全協定)，搜尋引擎僅收錄 https 網址，無法回溯至 HTTP，猶如綁上倒數計時炸彈，難以解除。LE 本身每年營運經費高達 360 萬美元，由競爭者捐助，且可隨時被瀏覽器移出信任名單，網站將面臨斷線或高額支出風險。
Hacker News 討論中，部分網管者分享因憑證更新失敗，遠端管理介面如 iDRAC、iLO 在新瀏覽器上無法存取，只好維持舊版憑證或過時瀏覽器。也有評論指出，SSL / TLS 推廣主要解決公共 Wi-Fi 與 ISP 廣告攔截問題，保障機密登入與資料完整性；隨著真實攻擊案例稀少，憑證透明度 (Certificate Transparency, CT) 日誌與多視點驗證可進一步降低中間人攻擊風險。另有人建議結合網域名稱系統安全擴充 (DNSSEC) 與基於 DNS 的命名實體驗證 (DANE) 來加強網域驗證。
反對者認為，與其追求所謂完美的自簽憑證或首次使用信任 (Trust On First Use, TOFU) 模式，不如承認自動化短生命週期憑證在減少金鑰外洩風險、強制測試更新流程與改善作業可觀測性上的優勢；憑證私鑰從不離開伺服器，撤銷機制與線上憑證狀態協定 (OCSP) 訂書亦提高安全性。若再搭配監控憑證透明度 (CT) 日誌與憑證授權機構授權 (Certification Authority Authorization, CAA) 記錄，惡意簽發將被迅速偵測並移出根憑證。入門者還可選擇 ZeroSSL、Buypass 等免費自動憑證管理環境 (ACME) 服務，獲得與 LE 相當的便利。許多網管者認同，現今網站普遍採用 HTTPS 已成共識，實務上已無退路。
👥 160 則討論、評論 💬
https://news.ycombinator.com/item?id=45579968