駭客可輕易取得他人網站假HTTPS認證，Let's Encrypt緊急停用TLS-SNI驗證

自動化數位憑證認證機構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以及思科。