Mozilla ogłosiła włączenie obsługi dla użytkowników stabilnej gałęzi przeglądarki Firefox dla mechanizmu ECH (Encrypted Client Hello), który stanowi kontynuację rozwoju technologii ESNI (Encrypted Server Name Indication) i ma za zadanie szyfrować informacje o parametrach sesji TLS , takie jak żądana nazwa domeny. Kod do pracy z ECH został pierwotnie dodany do wersji Firefoksa 85, ale był domyślnie wyłączony. Chrome stopniowo zaczął włączać obsługę ECH, począwszy od wydania Chrome 115.
Ponieważ oprócz łączenia się z serwer Żądane informacje o domenie wyciekają przez DNS. Aby zapewnić pełną ochronę, oprócz ECH, należy używać DNS przez HTTPS lub DNS przez TLS do szyfrowania ruchu DNS. Firefox nie będzie korzystał z ECH bez włączenia DNS przez HTTPS w ustawieniach. Możesz sprawdzić obsługę ECH w swojej przeglądarce na tej stronie.
Jednym z czynników, który umożliwił domyślną obsługę ECH w przeglądarce Firefox, było włączenie kilka dni temu obsługi ECH przez Cloudflare do swojej sieci dostarczania treści. Z praktycznego punktu widzenia, ponieważ dane o żądanych hostach podczas korzystania z ECH są ukryte przed analizą, filtrowanie i blokowanie niechcianych witryn za pomocą Cloudflare CDN będzie teraz wymagało blokowania całej sieci Cloudflare, blokowania wszystkich żądań z ECH lub organizowania przechwytywania HTTPS przy użyciu fałszywych certyfikatów głównych w systemie użytkownika.
Początkowo do organizacji pracy na jednym adresie IP kilku serwisów HTTPS wykorzystywano rozszerzenie TLS SNI, w którym nazwa żądanego hosta była wskazywana w wiadomości ClientHello przesyłanej przed nawiązaniem zaszyfrowanego kanału komunikacji. Funkcja ta umożliwiła dystrybucję żądań pomiędzy wirtualnymi hostami już na wczesnym etapie przetwarzania połączenia, ale także umożliwiła po stronie ISP selektywne filtrowanie ruchu HTTPS i analizę, które strony otwiera użytkownik, co nie pozwalało na osiągnięcie pełnej poufności podczas korzystania z HTTPS.
Aby rozwiązać ten problem i zapobiec wyciekowi informacji o żądanej witrynie, później zaproponowano rozszerzenie ESNI, które implementuje szyfrowanie danych za pomocą nazwy hosta. W trakcie wdrażania ESNI okazało się, że proponowany mechanizm nie obejmuje wszystkich możliwych źródeł wycieku danych z hosta, a jego zastosowanie nie jest wystarczające do zapewnienia całkowitej poufności sesji HTTPS. W szczególności po wznowieniu wcześniej nawiązanej sesji nazwa domeny w postaci zwykłego tekstu była nadal podawana wśród parametrów rozszerzenia TLS PSK (Pre-Shared Key). Ponadto wysiłki mające na celu wdrożenie ESNI pozwoliły zidentyfikować problemy ze zgodnością i skalowaniem, które uniemożliwiły powszechne przyjęcie ESNI.
Biorąc pod uwagę zidentyfikowane braki ESNI, opracowano nowy uniwersalny mechanizm ECH, który umożliwia szyfrowanie parametrów dowolnych rozszerzeń TLS. Technicznie rzecz biorąc, główna różnica między ECH i ESNI polega na tym, że zamiast pojedynczych pól, cała wiadomość ClientHello jest szyfrowana od razu. ECH polega na podzieleniu ClientHello na dwie oddzielne wiadomości — zaszyfrowaną wiadomość ClientHelloInner (SNI Inner) i niezaszyfrowaną wiadomość bazową ClientHelloOuter (SNI Outer). Nieszyfrowany SNI Outer zawiera dane nieprywatne, takie jak wersja TLS i lista zastosowanych szyfrów, a także popularna nazwa domeny, która nie pokrywa się z rzeczywistą nazwą żądanej domeny. Na przykład dla wszystkich klientów Cloudflare niezaszyfrowany SNI Outer określa wspólnego hosta „cloudflare-ech.com”, ale rzeczywista nazwa żądanego hosta jest przesyłana w zaszyfrowanym SNI Inner i nie jest dostępna do analizy.
ECH wykorzystuje również inny schemat dystrybucji kluczy szyfrujących: informacje o kluczu publicznym są przesyłane w rekordach DNS HTTPSSVC, a nie TXT. Do uzyskania i zaszyfrowania klucza wykorzystywane jest uwierzytelnione szyfrowanie typu end-to-end oparte na mechanizmie HPKE (Hybrid Public Key Encryption). ECH obsługuje również bezpieczne retransmisje klucza z serwera, co może być wykorzystane w przypadku rotacji kluczy. serwer i rozwiązać problemy z pobieraniem nieaktualnych kluczy z pamięci podręcznej DNS.
Źródło: opennet.ru
