伺服器名稱指示
 | 此條目可參照英語維基百科相應條目來擴充。 (2023年10月4日) |
伺服器名稱指示（英語：Server Name Indication，縮寫：SNI）是TLS的一個擴充協定[1]，在該協定下，在握手過程開始時客戶端告訴它正在連接的伺服器要連接的主機名稱。這允許伺服器在相同的IP位址和TCP埠號上呈現多個憑證，並且因此允許在相同的IP位址上提供多個安全（HTTPS）網站（或其他任何基於TLS的服務），而不需要所有這些站點使用相同的憑證。它與HTTP/1.1基於名稱的虛擬主機的概念相同，但是用於HTTPS。
為了使SNI協定起作用，絕大多數訪問者必須使用實現它的Web瀏覽器。使用未實現SNI瀏覽器的使用者將被提供預設憑證，因此很可能會收到憑證警告。
問題的背景[編輯]
當進行TLS連接時，客戶端從Web伺服器請求數位憑證。伺服器一旦傳送憑證，客戶端就會檢查這個憑證，並將其嘗試連接的名稱與憑證中包含的名稱進行對比。如果發生匹配，則連接正常進行。如果沒有找到匹配，則可能會向使用者警告該差異，並且可能會中止連接，因為該失配可能表明存在中間人攻擊。不過，某些應用程式允許使用者繞過警告繼續進行連接，由使用者承擔信任憑證以及連接的責任。
一個憑證覆蓋多個主機名是可以做到的。X.509 v3規範引入了subjectAltName欄位，該欄位允許一個憑證指定多個網域名稱，並在通用名和subjectAltName欄位中使用萬用字元。
然而，由於缺少所有名稱的完整清單，可能很難甚至不可能獲得涵蓋伺服器將負責的所有名稱的單個憑證。負責多個主機名的伺服器可能需要為每個名稱（或一組名稱）提供不同的憑證。自2005年以來，CAcert已經在虛擬伺服器上執行了TLS的不同用法的實驗。[2]大多數實驗是不理想和不切實際的。例如，可以使用subjectAltName來包含單個憑證中由一個人控制的多個網域名稱。[3]每當網域名稱清單更改時，必須重新發布此類「統一通訊憑證」。
基於名稱的虛擬主機允許多個DNS主機名由同一IP位址上的單個伺服器（通常為Web伺服器）代管。為了實現這一點，伺服器使用客戶端提供的主機名作為協定的一部分（對於HTTP，名稱顯示在主機頭中）。但是，當使用HTTPS時，TLS握手發生在伺服器看到任何HTTP頭之前。因此，伺服器不可能使用HTTP主機頭中的資訊來決定呈現哪個憑證，並且因此只有由同一憑證覆蓋的名稱才能由同一IP位址提供。
實際上，這意味著對於安全瀏覽來說，HTTPS伺服器只能是每個IP位址服務一個網域名稱（或一組網域名稱）。為每個站點分配單獨的IP位址會增加代管成本，因為對IP位址的請求必須為區域網際網路序號產生器構提供證據而且現在IPv4位址已用盡。其結果是，許多網站在IPv4上使用安全通訊實際上都受到了限制。IPv6位址空間未用完，因此使用IPv6提供的網站不受此問題的影響。
SNI如何解決此問題[編輯]
客戶端在SNI擴充中傳送要連接的主機名稱，作為TLS協商的一部分。[4]這使伺服器能夠提前選擇正確的主機名稱，並向瀏覽器提供相應TLS憑證。從而，具有單個IP位址的伺服器可以在取得公共憑證不現實的情況下提供一組網域名稱的TLS連接。
SNI在2003年6月的RFC 3546，《傳輸層安全（TLS）擴充》中加入到IETF的Internet RFCs中。最新版本的標準是RFC 6066。
實現[編輯]
在2004年，EdelKey專案做了一個用於將TLS/SNI添加到OpenSSL中的修補程式。[5]在2006年，這個修補程式被移植到OpenSSL的開發分支，並在2007年由OpenSSL 0.9.8支援（首次發布在0.9.8f[6]）。
一個應用程式要實現SNI，它使用的TLS庫必須實現SNI，並且該應用程式必須將主機名傳遞給TLS庫。其他複雜的問題有，TLS庫可以包括在應用程式中或者作為底層作業系統的組件。因此，一些瀏覽器在任何作業系統上執行時都能實現SNI，而其他瀏覽器僅在某些作業系統上執行時才能實現SNI。
安全性[編輯]
Cloudflare的聯合創始人兼執行長Matthew Prince曾表示，傳統SNI「絕對是加密裝甲中的最後縫隙之一」。（really is one of the last chinks in the encryption armor.）[7]
由於SNI資訊並未加密，審查者可以辨識出使用者訪問的網站網域名稱。現已被部分國家用於網際網路審查，如防火長城和韓國的KCSC（廣播通訊審議委員會）[8]。有兩種方法可以解決這個問題。
域前置[編輯]
域前置通過SNI中使用虛假無害的網域名稱資訊，已經被TLS加密的應用層才使用真實的網域名稱資訊，將真實流量隱藏在看似無害的流量中，從而使審查者無法區別出來，對於基於CDN的域前置，審查者要麼一律放行，要麼帶有嚴重附加傷害的一刀切封鎖。[9][10]
Cloudflare在2016年的一些修改讓基於其CDN的域前置不再工作。[11]
Google和CloudFront曾經接受域前置，之後停止了，被認為是受到俄羅斯政府的壓力，防止Telegram利用該技術來規避審查。[12]
加密伺服器名稱指示[編輯]
作為TLS的標準擴充實現，TLS 1.3一開始準備通過支援加密SNI以解決這個問題。Cloudflare、Mozilla、Fastly和蘋果的開發者制定了關於加密伺服器名稱指示（Encrypted Server Name Indication）的草案。[13]
2018年9月24日，Cloudflare在其網路上支援並預設啟用了ESNI。[14] 2019年7月，Mozilla Firefox開始提供ESNI的草案性實現支援，但預設關閉[15][16]。2019年8月，研究人員確認ESNI可以有效規避防火長城的SNI審查。[17]
2020年3月，ESNI更名為Encrypted Client Hello（簡稱ECHO），把加密擴充至整個Client Hello訊息。[18]2020年5月，簡稱更改為ECH。[19]ECH被認為解決了之前ESNI擴充「突出」（stick out），從而容易被網際網路服務提供者或審查系統辨識的問題。[20]從2023年09月29日開始，Cloudflare在「免費計劃」的使用者群組中預設開啟了ECH且無法關閉，付費使用者則可以選擇性開啟。[21]
自2020年7月下旬起，防火長城開始封鎖加密伺服器名稱指示（ESNI）的TLS通訊。[22]但沒有封鎖ECH的TLS通訊。而2020年8月開始，俄羅斯網際網路服務運營商Rostelecom及旗下移動手機服務運營商Tele2開始封鎖加密伺服器名稱指示（ESNI）的TLS通訊。[23]
參考文獻[編輯]
- ^ Server Name Indication. Transport Layer Security (TLS) Extensions. IETF: p. 8. sec. 3.1. RFC 3546.
- ^ CAcert VHostTaskForce. CAcert Wiki. [2017-01-18]. （原始內容存檔於2009-08-22）.
- ^ What is a Multiple Domain (UCC) SSL Certificate?. [2017-01-18]. （原始內容存檔於2015-02-06）.
- ^ TLS Server Name Indication. Paul's Journal. [2017-01-18]. （原始內容存檔於2016-08-12）.
- ^ EdelKey Project. [2017-01-18]. （原始內容存檔於2016-04-04）.
- ^ OpenSSL CHANGES. （原始內容存檔於2016-04-20）.
- ^ Thomas Claburn. Don't panic about domain fronting, an SNI fix is getting hacked out. The Register. 2017-07-17 [2018-08-25]. （原始內容存檔於2018-08-26） （英語）.
- ^ Sergiu Gatlan. South Korea is Censoring the Internet by Snooping on SNI Traffic. Bleeping Computer. 2019 [2021-04-17]. （原始內容存檔於2021-04-06） （美國英語）.
- ^ doc/meek – Tor Bug Tracker & Wiki. [2017-01-04]. （原始內容存檔於2016-12-13）.
- ^ Open Whisper Systems >> Blog >> Doodles, stickers, and censorship circumvention for Signal Android. [2017-01-04]. （原始內容存檔於2016-12-28）.
- ^ #14256 (Clarify whether Cloudflare's Universal SSL thing works with meek) – Tor Bug Tracker & Wiki. Tor Bug Tracker. [12 May 2020]. （原始內容存檔於2020-10-31）.
- ^ Amazon and Google bow to Russian censors in Telegram battle. Fast Company. 2018-05-04 [2018-05-09]. （原始內容存檔於2018-05-10） （英語）.
- ^ Kazuho, Oku,; Christopher, Wood,; Eric, Rescorla,; Nick, Sullivan,. Encrypted Server Name Indication for TLS 1.3. IETF. 2018-07-02 [2018-08-25]. （原始內容存檔於2018-08-13） （英語）.
- ^ Matthew Prince. Encrypting SNI: Fixing One of the Core Internet Bugs. 2018-09-24 [2021-06-15]. （原始內容存檔於2020-12-12）.
- ^ Check if your browser uses Secure DNS, DNSSEC, TLS 1.3, and Encrypted SNI - gHacks Tech News. www.ghacks.net. [2019-07-09]. （原始內容存檔於2019-09-02）.
- ^ Encrypt that SNI: Firefox edition. The Cloudflare Blog. 2018-10-18 [2019-07-09]. （原始內容存檔於2020-02-14） （英語）.
- ^ Zimo Chai; Amirhossein Ghafari; Amir Houmansadr. On the Importance of Encrypted-SNI (ESNI) to Censorship Circumvention (PDF). 9th USENIX Workshop on Free and Open Communications on the Internet (FOCI 19). Santa Clara, CA: USENIX Association. 2019-08-05 [2021-10-07]. （原始內容存檔 (PDF)於2021-12-02）.
currently only 66 websites can be unblocked with the help of ESNI.
- ^ ESNI -> ECHO · tlswg/draft-ietf-tls-esni. [2020-05-22]. （原始內容存檔於2021-02-25）.
- ^ s/ECHO/ECH · tlswg/draft-ietf-tls-esni. [2020-06-08]. （原始內容存檔於2021-02-24）.
- ^ TLS Encrypted Client Hello draft-ietf-tls-esni-11. IETF Data Tracker. 2021-06-14 [2021-06-15]. （原始內容存檔於2021-12-08）.
- ^ Encrypted Client Hello - the last puzzle piece to privacy. The Cloudflare Blog. 2023-09-29 [2023-10-04]. （原始內容存檔於2024-01-12） （英語）.
- ^ 报告：中国的防火长城已经封锁加密服务器名称指示（ESNI）. iYouPort. 2020-08-08 [2020-08-10]. （原始內容存檔於2021-03-28）.
- ^ Почему Ростелеком блокирует ESNI трафик?. qna.habr.com. 11 October 2020 [30 October 2020]. （原始內容存檔於2021-01-29） （俄語）.
外部連結[編輯]
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||