Skąd serwer WWW wie, której pary kluczy użyć do odszyfrowania SSL?

Rozumiem, że kiedy Apache otrzyma żądanie do jednego z portów TCP, na których nasłuchuje (np. 80, 443), zadecyduje o tym, którego hosta żąda, patrząc na nagłówek HTTP Host. Serwer będzie wtedy wiedział, do którego wirtualnego hosta powinien przekierować żądanie.

Ale jak to działa dla HTTP przez SSL / TLS? Ponieważ całe żądanie HTTP jest szyfrowane (przynajmniej tak myślę, że gdzieś przeczytałem), informacje w nagłówku można odczytać dopiero po odszyfrowaniu danych przez serwer. Ale w celu odszyfrowania musi wiedzieć, której pary kluczy użyć, ponieważ na serwerze sieciowym może być zainstalowanych wiele certyfikatów SSL.

Skąd więc serwer wie, jakiego klucza potrzebuje do odszyfrowania?

Mogę sobie wyobrazić, że uścisk dłoni TLS zapewnia niezbędne informacje.

Odnośnie flagi „możliwego duplikatu” :

Chociaż zgadzam się, że odpowiedzi zarówno na pytanie powiązane, jak i moje są podobne, muszę powiedzieć, że pytanie jest inne. Nie ma wątpliwości, czy i jak możliwe jest hostowanie wielu witryn z niezależnymi certyfikatami SSL. Zamiast tego moje pytanie dotyczy podstawowego aspektu technicznego.

Pierwotnie serwer WWW nie wiedział. To był powód, dla którego potrzebujesz osobnego adresu IP dla każdego vhosta SSL, który chcesz hostować na serwerze. W ten sposób serwer wiedział, że kiedy pojawiło się połączenie na IP X, musiał użyć konfiguracji (w tym certyfikatów) dla powiązanego vhosta.

Zmieniło się to wraz ze wskazaniem nazwy serwera , rozszerzeniem TLS, które rzeczywiście pozwala klientowi wskazać wymaganą nazwę hosta w procesie uzgadniania. To rozszerzenie jest używane we wszystkich nowoczesnych systemach operacyjnych, ale stare przeglądarki lub serwery go nie obsługują, więc jeśli oczekujesz, że klienci będą nadal korzystać z IE 6 na WinXP, nie będziesz miał szczęścia.

Wygląda na to, że masz jakieś nieporozumienia na temat TLS / SSL. Żądanie HTTP nie jest szyfrowane kluczem publicznym serwera. Jest szyfrowany za pomocą symetrycznego szyfru przy użyciu klucza wynegocjowanego w poprzednim uzgadnianiu.

Krótki opis uzgadniania TLS: Serwer i klient negocjują pewne oprogramowanie szyfrujące, klucze symetryczne i inne szczegóły. Aby zapobiec MITM, serwer zwykle wysyła swój certyfikat (łańcuch) do klienta i uwierzytelnia uzgadnianie za pomocą klucza w certyfikacie. (Istnieją również inne warianty, np. Uwierzytelnianie klienta lub TLS-PSK, ale nie są one zbyt często używane z HTTP). Klient może albo zweryfikować certyfikat (w zwykły sposób), albo go zignorować.

Chociaż SNI jest ważne, gdy używa się wielu certyfikatów TLS w jednym adresie IP, nie jest konieczne, aby serwer mógł odszyfrować żądanie. Bez SNI serwer nie wie, który łańcuch certyfikatów powinien zostać wysłany, dlatego serwer zwykle wybiera jeden (np. Pierwszy vhost), co oczywiście może być niewłaściwe. Jeśli serwer wybierze niewłaściwy łańcuch certyfikatów, klient powinien go odrzucić (aby nie kontynuować wysyłania żądania HTTP). Jeśli jednak klient zignoruje certyfikat (lub jeśli niepoprawny certyfikat zostanie oznaczony jako zaufany dla tej witryny), może z powodzeniem kontynuować. Ponieważ klucz symetryczny używany do szyfrowania nie zależy od certyfikatu (TLS jest zaprojektowany do pracy również bez certyfikatów), serwer może go odszyfrować.

Tylko drobna uwaga, dlaczego piszę o TLS, podczas gdy pytasz o SSL: TLS jest nową wersją SSL. Wszystkie wersje protokołu SSL są uważane za niebezpieczne dla ogólnego użytku, dlatego obecnie używamy głównie TLS (1.0, 1.1, 1.2).