跳至內容

伺服器名稱指示

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書

伺服器名稱指示（英語：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（英語：Rostelecom）及旗下移動手機服務運營商Tele2開始封鎖加密伺服器名稱指示（ESNI）的TLS通訊。[23]

參考文獻

  1. ^ Server Name Indication. Transport Layer Security (TLS) Extensions. IETF: p. 8. sec. 3.1. RFC 3546. 
  2. ^ CAcert VHostTaskForce. CAcert Wiki. [2017-01-18]. （原始內容存檔於2009-08-22）. 
  3. ^ What is a Multiple Domain (UCC) SSL Certificate?. [2017-01-18]. （原始內容存檔於2015-02-06）. 
  4. ^ TLS Server Name Indication. Paul's Journal. [2017-01-18]. （原始內容存檔於2016-08-12）. 
  5. ^ EdelKey Project. [2017-01-18]. （原始內容存檔於2016-04-04）. 
  6. ^ OpenSSL CHANGES. （原始內容存檔於2016-04-20）. 
  7. ^ 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） （英語）. 
  8. ^ Sergiu Gatlan. South Korea is Censoring the Internet by Snooping on SNI Traffic. Bleeping Computer. 2019 [2021-04-17]. （原始內容存檔於2021-04-06） （美國英語）. 
  9. ^ doc/meek – Tor Bug Tracker & Wiki. [2017-01-04]. （原始內容存檔於2016-12-13）. 
  10. ^ Open Whisper Systems >> Blog >> Doodles, stickers, and censorship circumvention for Signal Android. [2017-01-04]. （原始內容存檔於2016-12-28）. 
  11. ^ #14256 (Clarify whether Cloudflare's Universal SSL thing works with meek) – Tor Bug Tracker & Wiki. Tor Bug Tracker. [12 May 2020]. （原始內容存檔於2020-10-31）. 
  12. ^ Amazon and Google bow to Russian censors in Telegram battle. Fast Company. 2018-05-04 [2018-05-09]. （原始內容存檔於2018-05-10） （英語）. 
  13. ^ 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） （英語）. 
  14. ^ Matthew Prince. Encrypting SNI: Fixing One of the Core Internet Bugs. 2018-09-24 [2021-06-15]. （原始內容存檔於2020-12-12）. 
  15. ^ 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）. 
  16. ^ Encrypt that SNI: Firefox edition. The Cloudflare Blog. 2018-10-18 [2019-07-09]. （原始內容存檔於2020-02-14） （英語）. 
  17. ^ 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. 
  18. ^ ESNI -> ECHO · tlswg/draft-ietf-tls-esni. [2020-05-22]. （原始內容存檔於2021-02-25）. 
  19. ^ s/ECHO/ECH · tlswg/draft-ietf-tls-esni. [2020-06-08]. （原始內容存檔於2021-02-24）. 
  20. ^ TLS Encrypted Client Hello draft-ietf-tls-esni-11. IETF Data Tracker. 2021-06-14 [2021-06-15]. （原始內容存檔於2021-12-08）. 
  21. ^ Encrypted Client Hello - the last puzzle piece to privacy. The Cloudflare Blog. 2023-09-29 [2023-10-04]. （原始內容存檔於2024-01-12） （英語）. 
  22. ^ 报告：中国的防火长城已经封锁加密服务器名称指示（ESNI）. iYouPort. 2020-08-08 [2020-08-10]. （原始內容存檔於2021-03-28）. 
  23. ^ Почему Ростелеком блокирует ESNI трафик?. qna.habr.com. 11 October 2020 [30 October 2020]. （原始內容存檔於2021-01-29） （俄語）. 

外部連結

取自 "https://zh.wikipedia.org/w/index.php?title=服务器名称指示&oldid=80698969"