跳至內容

服務器名稱指示

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

服務器名稱指示（英語：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」