Firma Mozilla ogłosiła włączenie wsparcia dla mechanizmu ECH (Encrypted Client Hello) z myślą o użytkownikach stabilnej wersji Firefox, co jest kontynuacją rozwoju technologii ESNI (Encrypted Server Name Indication) i służy do szyfrowania informacji o parametrach sesji TLS, takich jak żądana nazwa domeny. Początkowo kod do obsługi ECH został dodany w wersji Firefox 85, ale był domyślnie wyłączony. W Chrome wsparcie dla ECH zaczęto stopniowo włączać, począwszy od wersji Chrome 115.
Ponieważ oprócz połączenia z serwerem wyciek danych o żądanych domenach występuje przez DNS, do pełnej ochrony oprócz ECH konieczne jest zastosowanie technologii DNS over HTTPS lub DNS over TLS w celu szyfrowania ruchu DNS. Firefox nie będzie używał ECH bez włączenia DNS over HTTPS w ustawieniach. Sprawdzić wsparcie ECH w przeglądarce można na tej stronie.
Jednym z czynników aktywacji domyślnego wsparcia ECH w Firefoxie była niedawna decyzja firmy Cloudflare o włączeniu wsparcia dla ECH w swojej sieci dostarczania treści. Z praktycznego punktu widzenia, ponieważ dane o żądanych hostach przy zastosowaniu ECH są ukryte przed analizą, do filtrowania i blokowania niepożądanych stron korzystających z CDN Cloudflare teraz będzie wymagana blokada całej sieci Cloudflare, blokada wszystkich żądań z ECH lub zorganizowanie przechwytywania HTTPS przy użyciu fałszywych certyfikatów głównych na systemie użytkownika.
Początkowo dla umożliwienia działania kilku stron HTTPS na jednym adresie IP stosowano rozszerzenie TLS SNI, w którym nazwa żądanego hosta była wskazywana w wiadomości ClientHello, przesyłanej przed ustanowieniem zaszyfrowanego połączenia. Taka cecha umożliwiała we wczesnym etapie przetwarzania połączenia rozdzielanie żądań pomiędzy wirtualne hosty, ale pozwalała również dostawcom internetu na selektywne filtrowanie ruchu HTTPS oraz analizowanie, które strony odwiedza użytkownik, co uniemożliwiało uzyskanie pełnej prywatności przy korzystaniu z HTTPS.
Aby rozwiązać ten problem i zapobiec wyciekom informacji o żądanej stronie, zaproponowano rozszerzenie ESNI, które realizuje szyfrowanie danych z nazwą hosta. W trakcie wdrażania ESNI ujawniono, że zaproponowany mechanizm nie obejmuje wszystkich możliwych źródeł wycieków danych o hostie, a jego zastosowanie jest niewystarczające do zapewnienia pełnej poufności sesji HTTPS. W szczególności podczas wznowienia wcześniej ustanowionej sesji, nazwa domeny w jawnej postaci nadal była wskazywana w liczbie parametrów rozszerzenia TLS PSK (Pre-Shared Key). Dodatkowo, próby wdrożenia ESNI ujawniły problemy z kompatybilnością i skalowalnością, które utrudniały powszechne wdrożenie ESNI.
Biorąc pod uwagę zidentyfikowane niedociągnięcia, ESNI opracowano nowy uniwersalny mechanizm ECH, który umożliwia szyfrowanie parametrów dowolnych rozszerzeń TLS. Technicznie główną różnicą między ECH a ESNI jest to, że zamiast osobnych pól szyfrowane jest całe powiadomienie ClientHello. ECH zakłada podział ClientHello na dwa osobne komunikaty — szyfrowane powiadomienie ClientHelloInner (SNI Inner) oraz nieszyfrowane podstawowe powiadomienie ClientHelloOuter (SNI Outer). W nieszyfrowanym SNI Outer przesyłane są dane, które nie naruszają prywatności, takie jak wersja TLS oraz lista używanych szyfrów, a także wspólna nazwa domeny, która nie pokrywa się z faktyczną nazwą żądanej domeny. Na przykład dla wszystkich klientów Cloudflare w nieszyfrowanym SNI Outer wskazywana jest wspólna domena "cloudflare-ech.com", a rzeczywista nazwa żądanej domeny jest przesyłana w szyfrowanym SNI Inner i nie jest dostępna do analizy.
ECH wykorzystuje również inny schemat dystrybucji klucza do szyfrowania — informacje o kluczu publicznym są przekazywane w rekordach DNS HTTPSSVC, a nie w rekordach typu TXT. Do uzyskiwania i szyfrowania klucza stosowane jest uwierzytelnione szyfrowanie end-to-end oparte na mechanizmie HPKE (Hybrid Public Key Encryption). ECH wspiera również bezpieczne ponowne przesyłanie klucza z serwera, co może być stosowane w przypadku rotacji kluczy na serwerze i do rozwiązywania problemów z uzyskiwaniem przestarzałych kluczy z pamięci podręcznej DNS.
Źródło: opennet.ru
