To jest kanoniczne pytanie dotyczące hostingu wielu witryn SSL w tym samym adresie IP.
Miałem wrażenie, że każdy certyfikat SSL wymaga własnej unikalnej kombinacji adresu IP / portu. Ale odpowiedź na moje poprzednie pytanie jest sprzeczna z tym twierdzeniem.
Korzystając z informacji z tego pytania, udało mi się uzyskać wiele certyfikatów SSL do pracy na tym samym adresie IP i na porcie 443. Jestem bardzo zdezorientowany, dlaczego to działa, biorąc pod uwagę powyższe założenie i potwierdzone przez innych, że każda strona internetowa domeny SSL w ten sam serwer wymaga własnego adresu IP / portu.
Jestem podejrzliwy, że zrobiłem coś złego. Czy w ten sposób można używać wielu certyfikatów SSL?
Odpowiedzi:
FYsI: „Wiele (różnych) certyfikatów SSL w jednym adresie IP” przynosi ci magia aktualizacji TLS. Działa z nowszymi serwerami Apache (2.2.x) i stosunkowo nowymi przeglądarkami (nie znam wersji poza moją głową).
RFC 2817 (aktualizacja do TLS w HTTP / 1.1) ma krwawe szczegóły, ale w zasadzie działa dla wielu osób (jeśli nie dla większości).
Możesz jednak odtworzyć stare, funky zachowanie za pomocą
s_client
polecenia openssl (lub dowolnej „wystarczająco starej” przeglądarki).Edytuj, aby dodać: najwyraźniej
curl
może pokazać ci, co się tutaj dzieje lepiej niż openssl:SSLv3
TLSv1
źródło
Tak, ale są pewne zastrzeżenia.
Odbywa się to poprzez Wskazanie nazwy serwera, rozszerzenie do Transport Layer Security.
Co to jest wskazanie nazwy serwera?
Wskazanie nazwy serwera ( RFC 6066 ; przestarzałe RFC 4366 , RFC 3546 ) jest rozszerzeniem Transport Layer Security, które pozwala klientowi powiedzieć serwerowi nazwę hosta, do którego próbuje dotrzeć.
SNI jest zgodny z TLS 1.0 i wyższym zgodnie ze specyfikacją, ale implementacje mogą się różnić (patrz poniżej). Nie można go używać z protokołem SSL, dlatego połączenie SNI musi negocjować TLS (patrz RFC 4346 dodatek E ). Zwykle dzieje się to automatycznie w przypadku obsługiwanego oprogramowania.
Dlaczego SNI jest potrzebny?
W zwykłym połączeniu HTTP przeglądarka informuje serwer o nazwie hosta serwera, do którego próbuje dotrzeć, używając
Host:
nagłówka. Umożliwia to serwerowi sieciowemu na jednym adresie IP udostępnianie treści dla wielu nazw hostów, co jest powszechnie znane jako wirtualny hosting oparty na nazwach .Alternatywą jest przypisanie unikalnych adresów IP do każdej obsługiwanej nazwy hosta. Robiono to powszechnie w pierwszych dniach Internetu, zanim powszechnie wiadomo, że skończy się adres IP i rozpoczną się środki ochronne, i nadal tak jest w przypadku wirtualnych hostów SSL (nie używając SNI).
Ponieważ ta metoda przesyłania nazwy hosta wymaga nawiązania połączenia, nie działa z połączeniami SSL / TLS. Do czasu ustanowienia bezpiecznego połączenia serwer WWW musi już wiedzieć, jaką nazwę hosta będzie obsługiwał na kliencie, ponieważ sam serwer WWW ustanawia bezpieczne połączenie.
SNI rozwiązuje ten problem, ponieważ klient przesyła nazwę hosta w ramach negocjacji TLS, dzięki czemu serwer już wie, który host wirtualny powinien zostać użyty do obsługi połączenia. Serwer może następnie użyć certyfikatu i konfiguracji dla poprawnego wirtualnego hosta.
Dlaczego nie użyć różnych adresów IP?
Host:
Nagłówek HTTP został zdefiniowany, aby umożliwić obsługę więcej niż jednego hosta WWW z jednego adresu IP z powodu braku adresów IPv4, uznanego za problem już w połowie lat dziewięćdziesiątych. We współdzielonych środowiskach hostingowych setki unikalnych, niepowiązanych stron internetowych mogą być obsługiwane przy użyciu jednego adresu IP w ten sposób, oszczędzając przestrzeń adresową.Współdzielone środowiska hostingowe odkryły następnie, że największym konsumentem przestrzeni adresowej IP była potrzeba posiadania bezpiecznych stron internetowych w celu posiadania unikalnych adresów IP, co spowodowało potrzebę SNI jako środka zatrzymującego lukę w drodze do IPv6. Obecnie czasami trudno jest uzyskać zaledwie 5 adresów IP (/ 29) bez znacznego uzasadnienia, co często powoduje opóźnienia w wdrożeniu.
Wraz z pojawieniem się IPv6 takie techniki zachowania adresów nie są już konieczne, ponieważ do jednego hosta można przypisać więcej adresów IPv6 niż cały Internet obecnie, ale techniki te prawdopodobnie będą nadal używane w dalekiej przyszłości do obsługi starszych IPv4 znajomości.
Ostrzeżenia
Niektóre kombinacje systemu operacyjnego / przeglądarki nie obsługują SNI (patrz poniżej), więc używanie SNI nie jest odpowiednie dla wszystkich sytuacji. Witryny atakujące takie kombinacje system / przeglądarka musiałyby zrezygnować z SNI i nadal używać unikalnych adresów IP dla każdego wirtualnego hosta.
Na szczególną uwagę, żadna wersja Internet Explorera na Windows XP nie obsługuje SNI. Ponieważ ta kombinacja nadal stanowi znaczną (ale stale malejącą; około 16% ruchu internetowego w grudniu 2012 r. Według NetMarketShare) część ruchu internetowego, SNI byłby nieodpowiedni dla witryny kierowanej do tych grup użytkowników.
Wsparcie
Wiele powszechnie używanych pakietów oprogramowania obsługuje SNI.
(Pominięcie tej listy niekoniecznie oznacza brak wsparcia; oznacza to, że było ograniczenie, ile mógłbym wpisać, lub nie mogłem szybko znaleźć informacji w wyszukiwaniu. Jeśli Twojego pakietu oprogramowania nie ma na liście, wyszukiwanie jego nazwa plus
sni
powinna ujawniać, czy istnieje wsparcie i jak je skonfigurować).Obsługa bibliotek
Większość pakietów zależy od zewnętrznej biblioteki zapewniającej obsługę SSL / TLS.
Obsługa serwera
Większość aktualnych wersji popularnego oprogramowania serwerowego obsługuje SNI. Instrukcje instalacji są dostępne dla większości z nich:
Obsługa klienta
Większość obecnych przeglądarek internetowych i agentów użytkownika wiersza poleceń obsługuje SNI.
Pulpit
mobilny
Wiersz poleceń
Bez wsparcia
(Uwaga: niektóre informacje na temat tej odpowiedzi uzyskano z Wikipedii ).
źródło
Problem:
Gdy klient WWW i serwer WWW rozmawiają ze sobą przez HTTPS, pierwszą rzeczą, która musi się zdarzyć, jest bezpieczny uścisk dłoni.
Oto uproszczony przykład takiego uścisku dłoni:
Gdyby to był HTTP, a nie HTTPS, pierwszą rzeczą, którą klient wysłałby, byłoby coś takiego:
Umożliwiło to utworzenie wielu wirtualnych hostów na jednym adresie IP, ponieważ serwer dokładnie wie, do jakiej domeny chce uzyskać dostęp klient, czyli example.com.
HTTPS jest inny. Jak powiedziałem wcześniej, uścisk dłoni jest najważniejszy. Jeśli spojrzysz na trzeci krok uzgadniania zilustrowany powyżej (Certyfikat), serwer musi przedstawić klientowi certyfikat jako część uzgadniania, ale nie ma pojęcia, do jakiej nazwy domeny klient chce uzyskać dostęp. Jedyną opcją serwera jest wysyłanie za każdym razem tego samego certyfikatu, domyślnego certyfikatu.
Nadal można skonfigurować wirtualne hosty na serwerze WWW, ale serwer zawsze wysyła ten sam certyfikat do każdego klienta. Jeśli próbujesz hostować zarówno witryny example.com, jak i example.org na swoim serwerze, serwer zawsze wysyła certyfikat na example.com, gdy klient zażąda połączenia HTTPS. Tak więc, gdy klient zażąda example.org przez ustanowione połączenie HTTPS, tak by się stało:
Ten problem skutecznie ogranicza liczbę domen, które można serwerować przez HTTPS, do jednej na adres IP.
Rozwiązanie:
Najprostszym sposobem rozwiązania tego problemu jest poinformowanie serwera, do której domeny chce uzyskać dostęp podczas uzgadniania . W ten sposób serwer może podać poprawny certyfikat.
To właśnie robi SNI lub Wskazanie nazwy serwera.
W przypadku SNI klient wysyła nazwę serwera, do którego chce uzyskać dostęp, w ramach pierwszej wiadomości, kroku „Witaj klienta” na powyższym schemacie uzgadniania.
Niektóre starsze przeglądarki internetowe nie obsługują SNI. Na przykład w systemie Windows XP nie ma jednej wersji programu Internet Explorer , która obsługuje SNI. Podczas uzyskiwania dostępu do zasobu przez HTTPS na serwerze, który korzysta z wirtualnych hostów SNI, zostanie wyświetlony ogólny certyfikat, który może spowodować, że przeglądarka wyświetli ostrzeżenie lub błąd.
Upraszczam tutaj rzeczy, aby wyjaśnić zasadę problemu i rozwiązanie. Jeśli potrzebujesz bardziej technicznego wyjaśnienia, strona wikipedia lub RFC 6066 może służyć jako dobry punkt wyjścia. Możesz również znaleźć aktualną listę serwerów i przeglądarek obsługujących SNI na wikipedii
źródło
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
Przeglądarka klienta musi również obsługiwać SNI. Oto niektóre przeglądarki, które:
źródło
Rozszerzenie TLS ze wskazaniem nazwy serwera (RFC6066) jest wymagane, aby vhosty oparte na nazwach działały przez HTTPS.
Rozszerzenie jest szeroko wdrażane i nie mam jeszcze żadnych problemów z bieżącym oprogramowaniem, ale istnieje szansa, że niektórzy klienci (ci, którzy go nie obsługują) zostaną przekierowani do Twojej domyślnej witryny, jeśli zależysz od SNI.
źródło