Wskazanie nazwy serwera — Server Name Indication

Server Name Indication ( SNI ) jest rozszerzeniem protokołu sieciowego TLS ( Transport Layer Security ) , za pomocą którego klient wskazuje nazwę hosta, z którą próbuje się połączyć na początku procesu uzgadniania. Pozwala to serwerowi prezentować jeden z wielu możliwych certyfikatów na tym samym adresie IP i numerze portu TCP, a tym samym umożliwia obsługę wielu bezpiecznych ( HTTPS ) witryn internetowych (lub dowolnej innej usługi przez TLS) przez ten sam adres IP bez wymagania wszystkich tych witryn używać tego samego certyfikatu. Jest to koncepcyjny odpowiednik wirtualnego hostingu opartego na nazwach HTTP/1.1 , ale dla protokołu HTTPS. Pozwala to również serwerowi proxy na przekazywanie ruchu klienta do właściwego serwera podczas uzgadniania TLS/SSL. Żądana nazwa hosta nie jest zaszyfrowana w oryginalnym rozszerzeniu SNI, więc podsłuchujący może zobaczyć, która witryna jest żądana.

Tło problemu

Przed SNI podczas nawiązywania połączenia TLS klient nie miał możliwości określenia, z którą witryną próbuje się połączyć. Dlatego jeśli jeden fizyczny serwer obsługuje wiele witryn, serwer nie ma możliwości sprawdzenia, którego certyfikatu użyć w protokole TLS. Mówiąc bardziej szczegółowo, podczas nawiązywania połączenia TLS klient żąda certyfikatu cyfrowego od serwera WWW. Gdy serwer wyśle ​​certyfikat, klient sprawdza go i porównuje nazwę, z którą próbował się połączyć, z nazwami zawartymi w certyfikacie. Jeśli dojdzie do dopasowania, połączenie będzie przebiegać normalnie. Jeśli dopasowanie nie zostanie znalezione, użytkownik może zostać ostrzeżony o rozbieżności, a połączenie może zostać przerwane, ponieważ niezgodność może wskazywać na próbę ataku typu man-in-the-middle . Jednak niektóre aplikacje pozwalają użytkownikowi ominąć ostrzeżenie, aby kontynuować połączenie, przy czym użytkownik przejmuje odpowiedzialność za zaufanie do certyfikatu i, co za tym idzie, połączenia.

Jednak uzyskanie pojedynczego certyfikatu obejmującego wszystkie nazwy, za które będzie odpowiedzialny serwer, może być trudne – a nawet niemożliwe z powodu braku pełnej listy wszystkich nazw. Serwer odpowiedzialny za wiele nazw hostów prawdopodobnie będzie musiał przedstawić inny certyfikat dla każdej nazwy (lub małej grupy nazw). Możliwe jest użycie subjectAltName do umieszczenia wielu domen kontrolowanych przez jedną osobę w jednym certyfikacie. Takie „certyfikaty ujednoliconej komunikacji” muszą być wydawane ponownie za każdym razem, gdy zmienia się lista domen.

Hosting wirtualny oparty na nazwach umożliwia hostowanie wielu nazw hostów DNS przez jeden serwer (zwykle serwer sieci Web) pod tym samym adresem IP. W tym celu serwer używa nazwy hosta prezentowanej przez klienta w ramach protokołu (w przypadku HTTP nazwa ta jest prezentowana w nagłówku hosta ). Jednak w przypadku korzystania z protokołu HTTPS uzgadnianie TLS ma miejsce, zanim serwer zobaczy nagłówki HTTP. W związku z tym serwer nie mógł użyć informacji z nagłówka hosta HTTP, aby zdecydować, który certyfikat przedstawić i jako takie tylko nazwy objęte tym samym certyfikatem mogą być obsługiwane z tego samego adresu IP.

W praktyce oznaczało to, że serwer HTTPS mógł obsługiwać tylko jedną domenę (lub małą grupę domen) na adres IP w celu bezpiecznego i wydajnego przeglądania. Przypisanie oddzielnego adresu IP dla każdej witryny zwiększa koszt hostingu, ponieważ żądania adresów IP muszą być uzasadnione w regionalnym rejestrze internetowym, a adresy IPv4 są teraz wyczerpane . W przypadku protokołu IPv6 zwiększa to obciążenie administracyjne dzięki posiadaniu wielu adresów IP na jednym komputerze, nawet jeśli przestrzeń adresowa nie jest wyczerpana. W rezultacie wiele stron internetowych zostało skutecznie powstrzymywanych przed korzystaniem z bezpiecznej komunikacji.

Zasady techniczne

SNI rozwiązuje ten problem, wysyłając klientowi nazwę domeny wirtualnej jako część komunikatu ClientHello negocjacji TLS . Dzięki temu serwer może wcześniej wybrać odpowiednią domenę wirtualną i przedstawić przeglądarce certyfikat zawierający poprawną nazwę. Dlatego w przypadku klientów i serwerów, które implementują SNI, serwer z jednym adresem IP może obsługiwać grupę nazw domen, dla których uzyskanie wspólnego certyfikatu jest niepraktyczne.

SNI dodano do IETF „s RFC internetowych w czerwcu 2003 roku przez RFC 3546, Transport Layer Security (TLS) Extensions . Najnowsza wersja standardu to RFC 6066.

Implikacje dla bezpieczeństwa

Ładunek Server Name Indication nie jest szyfrowany, dlatego nazwa hosta serwera, z którym klient próbuje się połączyć, jest widoczna dla pasywnego podsłuchującego. Ta słabość protokołu została wykorzystana przez oprogramowanie zabezpieczające do filtrowania i monitorowania sieci oraz rządy do wprowadzenia cenzury. Obecnie istnieje wiele technologii próbujących ukryć wskazanie nazwy serwera.

Frontowanie domeny

Fronting domeny to technika zastępowania żądanej nazwy hosta w SNI inną hostowaną przez ten sam serwer lub, częściej, sieć serwerów znaną jako Content Delivery Network. Gdy klient korzysta z frontu domeny, zastępuje domenę serwera w SNI (niezaszyfrowaną), ale pozostawia ją w nagłówku hosta HTTP (który jest szyfrowany przez TLS), aby serwer mógł obsługiwać odpowiednią zawartość. Fronton domeny narusza standard definiujący sam SNI, więc jego kompatybilność jest ograniczona (wiele usług sprawdza, czy host SNI odpowiada hostowi nagłówka HTTP i odrzuca połączenia z SNI z frontem domeny jako nieprawidłowe). Podczas gdy fronting domeny był używany w przeszłości w celu uniknięcia rządowej cenzury, jego popularność spadła, ponieważ główni dostawcy usług w chmurze (Google, Amazon AWS i CloudFront) wyraźnie zabraniają tego w swoich TOS i nakładają na to ograniczenia techniczne.

Zaszyfrowany klient Witaj

Encrypted Client Hello ( ECH ) to rozszerzenie protokołu TLS 1.3, które umożliwia szyfrowanie całej wiadomości Client Hello, która jest wysyłana na wczesnym etapie negocjacji TLS 1.3. ECH szyfruje ładunek za pomocą klucza publicznego, który strona ufająca (przeglądarka internetowa) musi znać z wyprzedzeniem, co oznacza, że ​​ECH jest najbardziej efektywny w przypadku dużych sieci CDN znanych z wyprzedzeniem dostawcom przeglądarek.

Początkowa wersja tego rozszerzenia z 2018 r. nosiła nazwę Encrypted SNI ( ESNI ), a jej implementacje zostały wdrożone w sposób „eksperymentalny”, aby wyeliminować ryzyko podsłuchiwania domeny. W przeciwieństwie do ECH, Encrypted SNI szyfruje tylko SNI, a nie całe Client Hello. Wsparcie opt-in dla tej wersji zostało włączone do Firefoksa w październiku 2018 i wymagało włączenia DNS-over-HTTPS.

W marcu 2020 r. ESNI został przerobiony na rozszerzenie ECH, po tym, jak analiza wykazała, że ​​szyfrowanie samego SNI jest niewystarczające. Na przykład specyfikacje zezwalają rozszerzeniu klucza wstępnego na zawieranie dowolnych danych ułatwiających wznawianie sesji, nawet przesyłanie kopii jawnego tekstu dokładnie tej samej nazwy serwera, która jest zaszyfrowana przez ESNI. Ponadto szyfrowanie rozszerzeń pojedynczo wymagałoby zaszyfrowanego wariantu każdego rozszerzenia, z których każde ma potencjalne konsekwencje dla prywatności, a nawet ujawnia zestaw reklamowanych rozszerzeń. Wreszcie, rzeczywiste wdrożenie ESNI ujawniło ograniczenia interoperacyjności. Skrócona nazwa brzmiała ECHO w marcu 2020 r. i została zmieniona na ECH w maju 2020 r.

Zarówno ESNI, jak i ECH są kompatybilne tylko z TLS 1.3, ponieważ opierają się na KeyShareEntry, który został po raz pierwszy zdefiniowany w TLS 1.3. Ponadto, aby korzystać z ECH, klient nie może proponować wersji TLS poniżej 1.3.

W sierpniu 2020 r. Wielka Chińska zapora sieciowa zaczęła blokować ruch ESNI, jednocześnie zezwalając na ruch ECH.

W październiku 2020 r. rosyjski ISP Rostelecom i jego operator komórkowy Tele2 rozpoczęli blokowanie ruchu ESNI. We wrześniu tego samego roku rosyjski minister cenzury Roskomnadzor planował zakazać szeregu protokołów szyfrowania, w tym TLS 1.3 i ESNI, które utrudniały cenzurę dostępu do stron internetowych.

Realizacja

W 2004 roku projekt EdelKey stworzył łatkę do dodawania TLS/SNI do OpenSSL . W 2006 roku ta poprawka została następnie przeniesiona do gałęzi rozwojowej OpenSSL, a w 2007 została przeportowana wstecznie do OpenSSL 0.9.8 (po raz pierwszy wydana w wersji 0.9.8f).

Aby aplikacja mogła zaimplementować SNI, używana przez nią biblioteka TLS musi ją implementować, a aplikacja musi przekazać nazwę hosta do biblioteki TLS. Jeszcze bardziej komplikując sprawy, biblioteka TLS może być zawarta w programie aplikacji lub być składnikiem bazowego systemu operacyjnego. Z tego powodu niektóre przeglądarki implementują SNI, gdy działają w dowolnym systemie operacyjnym, podczas gdy inne implementują go tylko w określonych systemach operacyjnych.

Wsparcie

Bibliografia

Zewnętrzne linki

• RFC  6066 (przestarzały RFC  4366 , który przestarzał RFC  3546 )