Wiele domen SSL na tym samym adresie IP i tym samym porcie?

109

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?

Jan
źródło
To ciało Q mówi wiele certyfikatów, a odpowiedzi są poprawne. Ale tytuł mówi o wielu domenach i możesz mieć wiele domen z jednym certyfikatem (i bez SNI), patrz serverfault.com/questions/126072/... i serverfault.com/questions/279722/... również krzyżują się na security.SX.
dave_thompson_085

Odpowiedzi:

68

Aby uzyskać najbardziej aktualne informacje o Apache i SNI, w tym o dodatkowych specyfikacjach RFC specyficznych dla HTTP, odwiedź Wiki Apache


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_clientpolecenia openssl (lub dowolnej „wystarczająco starej” przeglądarki).

Edytuj, aby dodać: najwyraźniej curlmoże pokazać ci, co się tutaj dzieje lepiej niż openssl:


SSLv3

mikeg@flexo% curl -v -v -v -3 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: serialNumber=wq8O9mhOSp9fY9JcmaJUrFNWWrANURzJ; C=CA; 
              O=staging.bossystem.org; OU=GT07932874;
              OU=See www.rapidssl.com/resources/cps (c)10;
              OU=Domain Control Validated - RapidSSL(R);
              CN=staging.bossystem.org
*    start date: 2010-02-03 18:53:53 GMT
*    expire date: 2011-02-06 13:21:08 GMT
* SSL: certificate subject name 'staging.bossystem.org'
       does not match target host name 'www.yummyskin.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'staging.bossystem.org'
does not match target host name 'www.yummyskin.com'

TLSv1

mikeg@flexo% curl -v -v -v -1 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: C=CA; O=www.yummyskin.com; OU=GT13670640;
              OU=See www.rapidssl.com/resources/cps (c)09;
              OU=Domain Control Validated - RapidSSL(R);
              CN=www.yummyskin.com
*    start date: 2009-04-24 15:48:15 GMT
*    expire date: 2010-04-25 15:48:15 GMT
*    common name: www.yummyskin.com (matched)
*    issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global eBusiness CA-1
*    SSL certificate verify ok.
voretaq7
źródło
2
To bardzo przydatne - Dzięki! Wszelkie informacje na temat konfigurowania Apache dla TLS zamiast SSL?
Josh
2
Myślę, że Apache 2.2 musi mieć włączone bity TLS na liście szyfrów. Przyznaję, że nigdy nie widziałem całego bitu „Aktualizacja z SSL do TLS”, dopóki te dwie strony nie będą działać. Rozumiem dokumenty TLS, że negocjowanie tego rodzaju aktualizacji jest dopuszczalne (ale nietypowa) ...
voretaq7
Po raz pierwszy też to widzę i wciąż próbuję oderwać szczękę od podłogi ...
Josh
1
OK, moja odpowiedź potroiła się - najwyraźniej curl może prowadzić zarówno negocjacje SSLv3, jak i TLSv1, dzięki czemu mogę pokazać niepowodzenie i sukces. Chciałbym mieć pod ręką debuger protokołów, aby pokazać magiczną część. (Przetestowano również i z przyjemnością informujemy, że serwer johnlai2004 poprawnie odmawia połączeń SSLv2 :-)
voretaq7
Jest to niezwykle pomocne i mam nadzieję, że johnlai2004 zaakceptuje twoją odpowiedź. Wielkie dzięki!
Josh
97

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 snipowinna 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.

  • GNU TLS
  • JSSE (Oracle Java) 7 lub nowszy, tylko jako klient
  • libcurl 7.18.1 lub wyższy
  • NSS 3.1.1 lub nowszy
  • OpenSSL 0.9.8j lub wyższy
    • OpenSSL 0.9.8f lub wyższy, z flagami konfiguracji
  • Qt 4,8 lub wyższy

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

  • Chrome 5 lub nowszy
    • Chrome 6 lub nowszy w systemie Windows XP
  • Firefox 2 lub nowszy
  • Internet Explorer 7 lub nowszy, działający w systemie Windows Vista / Server 2008 lub nowszym
    • Internet Explorer w systemie Windows XP nie obsługuje SNI niezależnie od wersji IE
  • Konqueror 4.7 lub nowszy
  • Opera 8 lub nowsza (może wymagać włączenia TLS 1.1 do działania)
  • Safari 3.0 w systemie Windows Vista / Server 2008 lub nowszym albo Mac OS X 10.5.6 lub nowszym

mobilny

  • Przeglądarka Android w wersji 3.0 Honeycomb lub wyższej
  • iOS Safari na iOS 4 lub nowszym
  • Windows Phone 7 lub nowszy

Wiersz poleceń

  • cURL 7.18.1 lub wyższy
  • wget 1.14 lub wyższy (Dystrybucje mogły mieć backportową łatkę do obsługi SNI)

Bez wsparcia

  • Przeglądarka BlackBerry
  • Internet Explorer (dowolna wersja) w systemie Windows XP

(Uwaga: niektóre informacje na temat tej odpowiedzi uzyskano z Wikipedii ).

Michael Hampton
źródło
1
O wiele lepiej :-) Mam nadzieję, że może to ostatecznie uzyskać wyższy wynik niż obecnie akceptowany, co, oprócz ostatniej edycji na górze, jest niestety w większości niepoprawne.
Bruno,
1
@Bruno Na pewno nie będę narzekać, jeśli znajdziesz kilkaset osób, aby go głosować. :)
Michael Hampton
Najnowsza przeglądarka BlackBerry (10?) Używa najnowszej wersji WebKit, więc jest bardzo prawdopodobne, że obsługuje teraz SNI.
dave1010
37

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:

uścisk dłoni tls

Gdyby to był HTTP, a nie HTTPS, pierwszą rzeczą, którą klient wysłałby, byłoby coś takiego:

GET /index.html HTTP/1.1
Host: example.com

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:

wprowadź opis zdjęcia tutaj

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.

wprowadź opis zdjęcia tutaj

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

Kenny Rasschaert
źródło
16

http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Przeglądarka klienta musi również obsługiwać SNI. Oto niektóre przeglądarki, które:

* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (with TLS 1.1 enabled)
* Internet Explorer 7.0 or later (on Vista, not XP)
* Google Chrome
* Safari 3.2.1 on Mac OS X 10.5.6 
Craig
źródło
6

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.

Falcon Momot
źródło
Oprócz odpowiedzi Falcona usługi IIS wymagają również specjalnych zmian, aby wiele witryn IIS mogło działać w tym samym adresie IP. Musisz ręcznie edytować plik konfiguracyjny dla serwera lub użyć narzędzia CLI, aby wprowadzić zmiany wiązania, narzędzie GUI nie może tego zrobić. W IIS jest to określane jako przypisywanie certyfikatów SSL do nagłówków hosta. Przez pewien czas Apache nie miał problemu.
Brent Pabst
Ach, dobrze, to trochę wyjaśnia. Skąd możesz wiedzieć, czy klient (przeglądarka) to obsługuje? Na przykład, jeśli chcę sprawdzić MSIE6, jak mogę to przetestować bez konieczności instalowania wirtualnej maszyny XP?
Luc
1
@ Falcon SNI nie działa z IE na XP; co wciąż stanowi prawie jedną czwartą użytkowników komputerów stacjonarnych. Nie nazwałbym tego „szeroko wdrażanym”, gdy jedna czwarta potencjalnych odwiedzających nie pracuje.
Chris S
1
@MichaelHampton IE używa natywnego stosu szyfrowania Windows dla SSL. XP nie obsługuje SNI, dlatego też żadna wersja IE działająca na XP też nie. IE obsługuje tylko SNI w Vista i nowszych systemach operacyjnych.
Chris S