侍服器名稱指示

侍服器名稱指示（英語：ServerNameIndication，縮寫：SNI）是 TLS 的一个擴充協定，佇該協定之下，佇咧握手的過程開始的時陣客戶捀共講當佇咧連接的侍服器就愛連接的主機名稱。這允准侍服器佇相仝的 IP 位址佮 TCP 埠號上呈現濟个憑證，並且因此允准佇相仝的 IP 址頂懸提供真濟个安全（HTTPS）網站（抑是其他任何是因為 TLS 的服務）， 就無需要所有遮的站點來使用仝款的憑證。伊佮 HTTP / 是一鋪一是因為名稱的虛擬主機的概念相𫝛，但是用著 HTTPS。

為著使 SNI 協定起作用，真大的存取者著愛使用實現伊的 Web 瀏覽器。使用未實現 SNI 瀏覽器的使用者將被提供預設憑證，就按呢真可能收著憑證警告。

問題的背景

當進行 TLS 共接時間，客戶捀對 Web 侍服器請求數位憑證。侍服器若是傳送憑證，客戶捀就會檢查這憑證，閣共伊試連接的名稱佮憑證中包括的名稱進行對比。你若配生匹配，是連接正常的進行。你若無揣著匹配，可能會向使用者警告愛差，並且可能會接著，因為該失配可能表明存在中央人攻擊。猶毋過，某一寡應用程式允准使用者踅過警告繼續進行連接，由使用者承擔信任憑證佮連接的責任。

一个憑證崁濟个主機名是會當做到的。X . 五百空九 v 三規範引入來 ` subjectAltName ` 欄位，該欄位允准一个憑證指定濟个網域名稱，並且咧通用名佮 _ subjectAltName _ 欄位使用萬用字元。

毋過，因為欠所有名稱的完整清單，可能真困難啊甚至無可能得著涵蓋侍服器共負責的所有的名稱的單個憑證。負責真濟主機名的侍服器可能需要為著逐个名稱（抑是一組名稱）提供無仝款的憑證。自二空空五年以來，CAcert 已經佇咧虛擬侍服器懸頂執行矣 TLS 的無仝用法的實驗。大多數實驗是無理想佮無意佮實際的。比如講，會用得使用 _ subjectAltName _ 來包含單一个憑證中由一个人控制的濟个網域名稱。予逐家做網域名稱清單改的時陣，著愛重新發布此類「統一通批憑證」。

是因為講名稱的虛擬主機允真濟个 DNS 主機名由仝一 IP 址頂懸的單个侍服器（通常為 Web 侍服器）代管。為著實現這點，侍服器使用客戶捀提供的主機名作為協定的一部份（對於 HTTP，名稱顯示佇主機頭當中）。 猶毋過，當使用 HTTPS 時，TLS 握手發生咧侍服器看著任何 HTTP 頭進前。所以，侍服器無可能使用 HTTP 主機頭中的資訊來決定欲呈現佗一个憑證，而且只有由同一憑證崁的名稱才會當由仝一 IP 位址提供。

實際上，這意味對安全瀏覽來講，HTTPS 侍服器干焦會使是逐个 IP 位址服務一个網域名稱（或者是一組網域名稱）。 共每一个站點分配單獨的 IP 位址會增加代管的成本，因為著 IP 位址的請求必須為區域網際網路序號產生器構提供證據而且這馬 IPv 四个址已經用盡。其結果是，真濟網站佇咧 IPv 四上使用安全通信實際上攏受著限制。IPv 六位址空間未用完，就按呢使用 IPv 六提供的網站無受此問題的影響。

SNI 欲按怎解決這个問題

客戶捀佇咧 SNI 擴充中傳送欲連接的主機名稱，做為 TLS 協商的一部份。這使侍服器會使提早選擇正確的主機名稱，並且向瀏覽器提供相應 TLS 憑證。對而且，具有單个 IP 位址的侍服器會當佇咧取得公共憑證無現實的情況之下提供一組網域名稱的 TLS 連接。

SNI 佇二空空三年六月的 RFC 三千五百四十六，《 傳輸層安全（TLS）擴充》加入來到 IETF 的 Internet RFCs 中。上蓋新版本的標準是 RFC 六千空六十六。

實現

佇二空空四年，EdelKey 專案做一个用於將 TLS / SNI 添加到 OpenSSL 中的修補程式。佇二空空六年，這个修補程式去予徙栽去 OpenSSL 的開發分支，並佇二空空七年由 OpenSSL 空九九 . 八支援（頭一擺發佈佇咧零馮九 . 八 f）。

一个應用程式愛實現 SNI，伊使用的 TLS 庫著愛實現 SNI，並且應該用程式必須將主機名傳遞予 TLS 庫。其他複雜的問題有，TLS 庫會當包括佇咧應用程式當中抑是作為底層作業系統的組件。所以，一寡瀏覽器咧任何作業系統上執行的時攏會當實現 SNI，猶毋過其他的瀏覽器干焦佇某一寡作業系統上執行才會當實現 SNI。

安全性

Cloudflare 的聯合創始人兼執行長 Matthew Prince 捌表示，傳統 SNI「絕對是加密裝甲中的上尾仔空縫之一」。（really is one of the last chinks in the encryption armor .）

因為 SNI 資訊並無加密，審查者會當辨識出使用者存取的網站網號名字。這馬予部份國家用佇網路審查，如防火長城和韓國的 KCSC（廣播通信審議委員會）。 有兩種方法會當解決這个問題。

域前置

域前置通過 SNI 中使用虛假無害的網域名稱資訊，已經予 TLS 加密的應用層才使用真實的網域名稱資訊，將真實流量隱藏佇咧看起來無害的流量內底，毋過使審查者無法度區別出來，對基於 CDN 的域頭前，審查者愛跳一律放行，欲按怎紮有嚴重附加傷害的一刀切封鎖。

Cloudflare 佇咧二空一六年的一寡修改予是無仝款的 CDN 的前置不再做工課。

Google 和 CloudFront 捌接受著域的頭前，了後停止矣，予人認為是受著俄羅斯政府的壓力，防止 Telegram 利用這个技術來做避審查。

加密侍服器名稱指示

做為 TLS 的標準擴充實現，TLS 一孵三一開始準備通過支援加密 SNI 以解決這个問題。Cloudflare、Mozilla、Fastly 佮蘋果的開發者制定關於加密侍服器名稱指示（Encrypted Server Name Indication）的草案。

二空一八年九月二四，Cloudflare 佇咧其網路頂懸支援並且拍開用 ESNI。 二空一九年七月，Mozilla Firefox 開始提供 ESNI 的草案性實現支援，毋過預設關起來。二空一九年八月，研究人員確認 ESNI 會當有效規避防火長城的 SNI 審查。

二空二空年三月，ESNI 閣較號名做Encrypted Client Hello（簡稱 ECHO）， 共加密擴充到規个 Client Hello 訊息。二空二空年五月，簡稱閣較改做ECH。ECH 予人認為解決進前 ESNI 擴充「突出」（stick out）， 對網路頂懸強欲予網路服務提供者抑是審查系統辨識的問題。

自二空二空年七月下旬起，防火長城開始封鎖加密侍服器名稱指示（ESNI）的 TLS 通批。但是無封鎖 ECH 的 TLS 通批。而二空二空年八月開始，露西亞網際網路服務運營商 Rostelecom 佮旗下的移動手機仔服務運營商 Tele 二開始封鎖加密侍服器名稱指示（ESNI）的 TLS 通批。

外部連結

• RFC 六千空六十六 ( obsoletes RFC 四千三百六十六 ( which obsoleted RFC 三千五百四十六 ) )