Wprowadzenie
Wirtualny hosting jest praktyką udostępniania wielu stron internetowych w Internecie ten sam serwer. Chociaż jest to obecnie normą, nie było to możliwe we wczesnych dniach HTTP (wersje wcześniejsze niż 1.1).
Pierwotnie serwer mógł obsługiwać tylko wiele stron internetowych na tym samym komputerze (tj. Pod tym samym adresem IP), pod warunkiem, że każdej stronie internetowej został przypisany dedykowany port. Nie było to idealne rozwiązanie, ponieważ przeglądarki domyślnie portują 80 dla HTTP, chyba że użytkownik określi inny. W rezultacie większość właścicieli witryn zdecydowała się na serwer dedykowany, aby uniknąć ryzyka, że użytkownicy nie zapamiętają prawidłowego numeru portu i trafią do innej witryny.
Niemniej jednak, gdy więcej użytkowników dołączyło do sieci i zaczęło pojawiać się więcej urządzeń sieciowych, liczba dostępnych adresów IP zaczęła spadać w zastraszającym tempie. To oczekiwane wyczerpanie, znane jako Wyczerpanie zakresu adresów IPv4, skłonił przemysł do opracowania i wdrożenia różnych środków zaradczych, takich jak IPv6 (Następca IPv4), który może obsługiwać więcej adresów niż kiedykolwiek będziemy potrzebować. Niestety, mimo że IPv6 jest realnym rozwiązaniem, jego wdrożenie było dość powolne. Według Statystyki Google dotyczące IPv6, w chwili pisania tego tekstu tylko około 25% urządzeń internetowych jest wdrażanych przez IPv6.
Hosting wirtualny został również wdrożony jako wczesne rozwiązanie problemu wyczerpania, wraz z wprowadzeniem Host nagłówek w HTTP 1.1. Przeglądarki komunikujące się za pośrednictwem protokołu HTTP 1.1 mogły teraz łączyć się z portem serwera 80 i dołącz nazwę domeny (np www.ssl.com) witryny, którą chcieli odwiedzić w Host nagłówek. Niezależnie od tego, ile witryn serwer obsługuje na tym samym porcie, może wykorzystać te informacje do zidentyfikowania właściwej witryny i zwrócenia jej zawartości.
HTTPS i wirtualny hosting
Jednak wiele opublikowanych raportów na temat luk w sieci i ataków na użytkowników sieci zmotywowało przemysł do tego zacznij odchodzić od niezabezpieczonego HTTP do bardziej bezpiecznej alternatywnej HTTPS. Szerokie przyjęcie HTTPS poprawiło ogólne bezpieczeństwo użytkownika. Jednak jego dodatkowe ulepszenia również zwiększyły ogólną złożoność komunikacji internetowej.
Zasadniczo HTTPS jest dość podobny do HTTP, z wyjątkiem tego, że komunikacja HTTPS między przeglądarkami i serwerami jest szyfrowana. Krótko mówiąc, protokół HTTPS wymaga, aby serwery dostarczały przeglądarkom ważny certyfikat SSL wydany przez zaufanego publicznie urząd certyfikacji (CA), takie jak SSL.com. Przeglądarka może następnie użyć klucza publicznego zawartego w certyfikacie do ustanowić zaszyfrowany kanał komunikacji z serwerem. Ponadto dla określonej nazwy domeny wystawiany jest certyfikat, który przeglądarka sprawdza pod kątem zgodności z domeną, którą użytkownik chciał odwiedzić. Dlatego niezależnie od tego, ile witryn hostuje serwer, przeglądarki oczekują, że znajdą ważny certyfikat SSL dla żądanej witryny.
Uważny czytelnik może już wyczuć problem: przeglądarka wymaga prawidłowego certyfikatu witryny internetowej, aby ustanowić zaszyfrowany kanał i wysłać Host nagłówek, podczas gdy serwer potrzebuje Host nagłówek, aby zlokalizować certyfikat właściwej witryny. To klasyczny problem jajka i kury.
Oczywiste jest, że wirtualny hosting, tak jak został zaprojektowany dla HTTP, nie działa dla HTTPS, ponieważ mechanizmy bezpieczeństwa uniemożliwiają przeglądarkom wysyłanie Host przekazanie informacji na serwer. Niemniej jednak, przy wciąż nierozwiązanym problemie wyczerpania IPv4 i stale rosnącej popularności technologii chmurowych (które wymagają równoważenia obciążenia i wielu awaryjnych serwerów zaplecza), hosting wirtualny jest nadal koniecznością.
Co z certyfikatami wielodomenowymi?
Proponowanym rozwiązaniem tego problemu jest użycie wielu domen lub Certyfikaty SAN. Pojedynczy certyfikat SAN może zabezpieczyć setki różnych nazw domen, a przeglądarki nie będą narzekać, jeśli znajdą nazwę domeny, którą próbują odwiedzić, na liście domen certyfikatu SAN. Po skonfigurowaniu zaszyfrowanego kanału przeglądarka może wysłać plik Host nagłówek na serwer i kontynuuj jak w każdym innym przypadku. To świetny pomysł wykorzystujący technologię już obecną i dostępną, ale te same mechanizmy, które zapewniają bezpieczeństwo certyfikatów SAN, wprowadziły również kilka potencjalnie niepożądanych skutków ubocznych:
Certyfikaty SAN są doskonałym narzędziem do zabezpieczania wielu domen należących do tego samego podmiotu (osoby, firmy lub organizacji), ale ich stosowanie w hostingu dzielonym jest nieco niepraktyczne; ilekroć nowa domena jest gotowa do dodania lub usunięcia z certyfikatu, urząd certyfikacji musi wydać nowy certyfikat z najnowszą listą domen i ponownie wdrożyć we wszystkich domenach.
Ponadto certyfikaty SAN można wydawać tylko jako Organizacja sprawdzona (OV) lub rozszerzona weryfikacja (EV) if cała kolekcja domeny należą do tej samej organizacji. Te poziomy sprawdzania poprawności odnoszą się do ilość i rodzaje informacji o potencjalnym właścicielu certyfikatu zweryfikowanych przez CA przed wydaniem im certyfikatu. Wykazano, że im wyższy poziom weryfikacji, tym większe zaufanie użytkowników do witryny, a zaufanie użytkowników może wpływać na rozpoznawalność marki i współczynniki konwersji.
Wreszcie, we wspólnych środowiskach hostingu dość często firma udostępnia serwer innym firmom lub organizacjom (nawet swoim konkurentom). Ponieważ domeny w certyfikatach SAN są publicznie wymienione, właściciele firm mogą niechętnie udostępniać ten sam certyfikat firmom zewnętrznym.
Chociaż certyfikaty SAN są potężnymi i wszechstronnymi narzędziami z niezliczonymi aplikacjami, te problemy zmotywowały IETF - organ zarządzający standardami internetowymi - do poszukiwania lepiej dopasowanego podejścia do konkretnego problemu wirtualnie hostowanych witryn HTTPS.
Wskazanie nazwy serwera na ratunek
Rozwiązanie zostało wdrożone w formie Wskazanie nazwy serwera (SNI) rozszerzenie TLS protokół (część HTTPS, która zajmuje się szyfrowaniem).
SNI umożliwia przeglądarkom określenie nazwy domeny, z którą chcą się połączyć podczas TLS uścisk ręki (wstępna negocjacja certyfikatu z serwerem). W rezultacie witryny internetowe mogą używać własnych certyfikatów SSL, gdy są nadal hostowane na wspólnym adresie IP i porcie, ponieważ serwery HTTPS mogą wykorzystywać informacje SNI do identyfikacji odpowiedniego łańcucha certyfikatów wymaganego do nawiązania połączenia.
Następnie, po skonfigurowaniu szyfrowanego kanału komunikacyjnego, przeglądarka może włączyć nazwę domeny witryny w Host nagłówek i kontynuuj tak, jak zwykle. Zasadniczo SNI pełni tę samą funkcję co HTTP Host nagłówek podczas tworzenia szyfrowanego połączenia.
Ta prosta sztuczka pozwoliła wreszcie serwerom hostować wiele witryn HTTPS na tym samym porcie. Jednak, podobnie jak w przypadku większości technologii internetowych, SNI ma pewne ograniczenia.
Obawy związane ze wsparciem SNI
Chociaż SNI jest dość dojrzały, odkąd został po raz pierwszy opracowany w 1999 r., Nadal istnieje kilka starszych przeglądarek (IE w systemie Windows XP) i systemów operacyjnych (wersje Androida <= 2.3), które go nie obsługują. Aby uzyskać pełną listę przeglądarek i systemów operacyjnych obsługujących SNI, zapoznaj się z ten stół.
Chociaż udziały w rynku przeglądarek, które nie obsługują SNI (a co za tym idzie, takich przypadków) są niewielkie w porównaniu z nowoczesnymi przeglądarkami, jeśli przeglądarka nie rozpoznaje SNI, powróci do domyślnego certyfikatu SSL i potencjalnie wygeneruje błąd niedopasowania nazwy pospolitej.
Wiele firm, takich jak Google, wdraża SNI dla klientów, którzy go obsługują, i rzadko sięgają po certyfikaty SAN. Oczywiście oczekuje się, że problem ten zmniejszy się, gdy coraz więcej użytkowników i właścicieli firm uaktualni swoje systemy do nowoczesnych technologii.
Obawy dotyczące prywatności SNI
Obecna stabilna wersja TLS (wersja 1.2) przesyła nieszyfrowaną początkową część uzgadniania, a co za tym idzie - informacje SNI. W rezultacie osoba atakująca w sieci może odkryć historię sieciową użytkownika, mimo że sama komunikacja internetowa jest w pełni zaszyfrowana.
Różni dostawcy usług w chmurze, tacy jak Amazon czy Google, zezwolili na (brudne) obejście znane jako fronton domeny. Domena fronting może zapobiec ujawnieniu historii przeglądania, ponieważ zaciemnia informacje SNI przy użyciu nazwy hosta dostawcy usług w chmurze w TLS negocjacje i witryna docelowa w nagłówku HTTP. Jednak ta metoda nie jest już opłacalna, ponieważ Google i Amazon publicznie oświadczyły, że tak wyłączono obsługę frontingu domen w swoich usługach od kwietnia 2018 r.
Na szczęście zaproponowano bardziej systemowe rozwiązanie jako plik projekt eksperymentalny szczegółowo Zaszyfrowane SNI (ESNI) rozszerzenie dla najnowszego TLS wersja 1.3. ESNI szyfruje informacje SNI, łagodząc w ten sposób wszelkie obawy dotyczące prywatności. Niestety, TLS Mimo że 1.3 nie jest jeszcze powszechnie przyjęty w branży TLS 1.3 powoli staje się de facto protokołem bezpieczeństwa sieci. Śledź przyszłe artykuły od nas na temat statusu ESNI i prywatności HTTPS i TLS.
Wnioski
Podsumowując, dzięki SNI możesz hostować miliony witryn HTTPS na jednym serwerze. Jednak w zależności od indywidualnego przypadku certyfikat SAN może działać lepiej. Wciąż istnieją obawy dotyczące prywatności dotyczące SNI, chociaż istnieje również potencjalne rozwiązanie z ESNI. W każdym razie, korzystając z jednej lub kombinacji tych dwóch metod, możesz łatwo wdrożyć wirtualny hosting dla wszystkich swoich stron przy minimalnym wysiłku.
Jeśli masz więcej pytań dotyczących SNI lub nie wiesz, jak wybrać między SAN a SNI, zawsze chętnie odpowiemy na wszystkie pytania naszych klientów dotyczące ich PKI wymagania. Po prostu napisz do nas maila na support@ssl.com a ekspert ci pomoże.
