自動化數位憑證認證機構Let's Encrypt表示,由於太多共享託管以及基礎設施服務違反TLS-SNI驗證背後的假設,即日起停止透過TLS-SNI驗證取得認證,並對已存在使用者執行更新驗證程序,Let's Encrypt鼓勵使用者,盡量更換成HTTP或是DNS驗證。

網頁應用程式安全自動掃描服務Detectify安全研究員Frans Rosén,1月9日向Let's Encrypt回報TLS-SNI-01驗證的使用風險,同時被視為其繼任機制的TLS-SNI-02驗證也具有同樣問題,Let's Encrypt也隨即停用TLS-SNI驗證。

TLS-SNI是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。

Let's Encrypt是數位認證機構,宗旨是以自動化流程代替手動建立和安裝憑證的複雜流程,主要贊助商有電子前哨基金會、Mozilla基金會、Akamai以及思科。


Advertisement

更多 iThome相關內容