駭客可獲假 HTTPS 認證 Let’s Encrypt 採取緊急措施

網頁應用程式安全自動掃瞄服務 Detectify 安全研究員近日 Frans Rosén 發現，TLS-SNI-01 以及 TLS-SNI-02 在特定的情況下，允許駭客取得他人網站的 HTTPS 認證。

證書頒發認證機構 Let’s Encrypt 表示，由於太多共享託管以及基礎設施服務違反 TLS-SNI 驗證，即日起停止通過 TLS-SNI 驗證取得認證，並對通過的驗證進行更新，Let’s Encrypt 鼓勵使用者，儘量更換成 HTTP 或是 DNS 驗證。

Frans Rosén 發現後，1 月 9 日已向 Let’s Encrypt 報告的 TLS-SNI-01 驗證存在風險，同時被視為其繼任機制的 TLS-SNI-02 驗證也具有同樣問題，Let’s Encrypt 也隨即停用 TLS-SNI 驗證。

TLS-SN I 是 Let’s Encrypt 3 個自動化認證管理環境（Automatic Certificate Management Environment，ACME）請求 TLS 認證協定的方法之一。而 Frans Rosén 發現，TLS-SNI-01 和 TLS-SNI-02 在特定的情況下，允許駭客取得他人的網站 HTTPS 認證。

駭客可以找到指向託管服務的獨立網域名稱，為該域名添加未授權的認證，以假亂真。例如一間擁有fakecert.com 網域的公司，將其位置指向一個位置非 fakecert.com 的雲端服務，而黑客就有機會在該雲端服務啟用一個全新的帳號，並用新帳號為 fakecert.com 添加 HTTPS 伺服器，再使用 Let’s Encrypt 的 TLS-SNI-01 驗證服務認證 HTTPS，讓假網站看起來跟真的一樣。

而這個風險發生的原因並非是 TLS-SNI 驗證程式上的漏洞，而是流程控制問題。不少託管服務不驗證網域的所有權，尤其是託管服務提供多個使用者共用同一 IP 時，更可能讓有心人士利用 Let’s Encrypt，並通過TLS-SNI-01 驗證機制取得他人的網站認證，無論是 AWS 的 CloudFront 或是 Heroku 都存在這樣的風險。

Frans Rosén 建議 3 個方法減少相關的風險，首先便是停用 TLS-SNI-01，再來是設置 .acme.invalid 入黑名單，最後為使用取得其他驗證的方法。Let’s Encrypt 目前也停止通過 TLS-SNI-01 機制發放認證，要求使用者轉而使用 HTTP-01 或是 DNS-01。