Apple, Cloudflare, Fastly i Mozilla opracowują rozwiązanie do szyfrowania SNI

Aktualności
Bezpieczeństwo / Apple, Cloudflare, Fastly i Mozilla opracowują rozwiązanie do szyfrowania SNI 5 minut czytania

Właśnie pojawiły się wiadomości, że Apple, Cloudflare, Fastly i Mozilla współpracują nad ulepszeniem szyfrowania mechanizmu identyfikacji nazwy serwera w HTTPS podczas IETF 102 Hackathon, jak wskazał tweet od Cloudflare Nick Sullivan. Tweet pogratulował zespołowi mikserów czterech gigantów technologicznych, mówiąc „Świetna robota” i udostępniając tam linki do działających serwerów pod adresem esni.examp1e.net i cloudflare-esni.com .



IETF Hackathon to platforma, która zaprasza młodych programistów i entuzjastów technologii do wspólnego opracowywania rozwiązań problemów technicznych, z którymi boryka się obecnie zwykły użytkownik. Udział w wydarzeniach jest bezpłatny, otwarty dla wszystkich i zachęca do pracy zespołowej, a nie rywalizacji. Tegoroczny IETF Hackathon odbył się 14 sierpnia w Montrealuthi 15thlipca. Wydaje się, że najbardziej znaczącym osiągnięciem, które z tego wynikło, jest szyfrowanie Transport Layer Security (TLS) Server Name Indication (SNI), problem, który nękał deweloperów przez ostatnią dekadę, a który członkowie Apple, Cloudflare, Fastly , a Mozilla zaproponowała teraz rozwiązanie.



Wydarzenie IETF Hackathon. IETF

W ciągu ostatnich półtorej dekady nastąpiło wyraźne globalne przejście z protokołu Hyper Text Transfer Protocol (HTTP) do protokołu Transport Layer Security Server Name Indication (TLS SNI HTTPS). Plik problem Efektem optymalizacji systemu TLS SNI HTTPS była możliwość wykorzystania SNI przez hakera wbrew jego celowi, aby dopasować transfer danych do późniejszego odszyfrowania.

dlaczego mój telefon mówi tylko o połączeniach alarmowych?

Przed opracowaniem SNI trudno było ustanowić bezpieczne połączenia z wieloma serwerami wirtualnymi przy użyciu tego samego pierwszego uzgadniania klienta. Gdy jeden adres IP wchodził w interakcję z jednym serwerem, dwa wymieniły się „hello”, serwer wysłał swoje certyfikaty, komputer wysłał swój klucz klienta, dwa wymieniły komendy „ChangeCipherSpec”, a następnie interakcja została zakończona, gdy połączenie zostało nawiązane. To może wydawać się łatwe, jak to właśnie zostało powiedziane, ale proces obejmował wiele wymian i odpowiedzi, które z łatwością stawały się dość problematyczne w miarę wzrostu liczby serwerów, z którymi się komunikowano. Jeśli wszystkie witryny korzystały z tych samych certyfikatów, nie stanowiło to większego problemu, ale niestety rzadko się to zdarzało. Gdy wiele witryn wysyłało różne certyfikaty w tę iz powrotem, serwerowi trudno było określić, którego certyfikatu szukał komputer, aw złożonej sieci wymiany informacji trudno było zidentyfikować, kto wysyłał co i kiedy, co zakończyło całą aktywność. z komunikatem ostrzegawczym.



TLS SNI został następnie wprowadzony w czerwcu 2003 r. Na szczycie IETF, a jego celem, w pewnym sensie, było stworzenie tagów nazw dla komputerów i usług zaangażowanych w sieć wymiany. To znacznie uprościło proces wymiany informacji między klientem a serwerem, ponieważ serwer był w stanie dostarczyć dokładnie potrzebne certyfikaty, a obaj mogli mieć własną wymianę konwersacji bez zastanawiania się, kto co powiedział. To trochę tak, jakby mieć nazwy osób kontaktowych do czatów i nie mieć wątpliwości, skąd pochodzą wiadomości, a także móc odpowiednio odpowiedzieć na każde zapytanie, dostarczając odpowiednie dokumenty każdemu komputerowi, który tego potrzebuje. Ta definicja SNI jest właśnie tym, co spowodowało największy problem z tą metodą optymalizacji procesu wymiany.

Zmaganiem wielu firm przy przechodzeniu na HTTPS było dostosowanie wielu certyfikatów do formatu SNI z indywidualnymi adresami IP w celu wykonywania żądań dla każdego certyfikatu. To, co zrobił dla nich TLS, to uproszczenie generowania certyfikatów w celu odpowiadania na takie żądania, a co jeszcze SNI zrobiło, to wyeliminowanie potrzeby zindywidualizowanych dedykowanych adresów IP certyfikatów poprzez wprowadzenie całego systemu identyfikacji w całej sieci internetowej. Wraz z modernizacją stulecia umożliwiło hakerom wykorzystanie ustalonych „nazw kontaktów” do monitorowania i śledzenia transferu danych oraz wyodrębniania informacji potrzebnych do odszyfrowania na późniejszym etapie.

Chociaż protokół TLS umożliwiał przesyłanie danych tam iz powrotem w zaszyfrowanym kanale, przy czym SNI zapewniało dotarcie do właściwego miejsca docelowego, ten ostatni zapewniał również hakerom możliwość monitorowania aktywności online i dopasowywania jej do źródła poprzez śledzenie żądań DNS, adresów IP i strumienie danych. Chociaż bardziej rygorystyczne zasady kodowania SNI zostały wdrożone poprzez przekazywanie informacji DNS również przez kanał TLS, hakerzy mogą wykorzystać to jako środek identyfikacji, aby śledzić informacje, które chcieliby wyodrębnić i odizolować. odszyfrowanie. Złożone serwery, które radzą sobie z większym ruchem zaszyfrowanych danych TLS, używają zwykłego tekstu SNI do wysyłania komunikacji na swoich serwerach, co ułatwia hakerom identyfikację kanałów i strumieni informacji, które chcą śledzić. Gdy haker będzie w stanie wyodrębnić informacje SNI z interesujących go danych, może ustawić fałszywe powtórzenie polecenia w oddzielnym połączeniu TLS z serwerem, wysyłając skradzione informacje SNI i odzyskując informacje, które było z tym związane. W przeszłości podejmowano kilka prób rozwiązania tego problemu SNI, ale większość z nich sprzeciwia się zasadzie prostoty, na której działa SNI, aby uczynić go wygodną metodą identyfikacji serwerów.

Wracając do szczytu, na którym po raz pierwszy pracowano nad ustanowieniem tej metody, uczestnicy czterech gigantów technologicznych wrócili na konferencję w Montrealu, aby opracować szyfrowanie dla TLS SNI, ponieważ pomimo większej wydajności w sąsiadującym systemie z wieloma HTTPS bezpieczeństwo nadal pozostaje problemem. tak samo jak wcześniej.

Aby ukryć SNI w TLS, „usługa ukryta” musi być utrzymywana pod nazwą „usługi Fronting”, którą może zobaczyć haker. Bez możliwości bezpośredniego obserwowania usługi ukrytej haker zostanie zmylony przez maskę frontu, pod którą ukrywa się w postaci zwykłego tekstu, nie będąc w stanie zidentyfikować podstawowych parametrów tajnych usług używanych do przekazywania zaszyfrowanych danych. Gdy obserwator podąża śladami usługi frontingowej, dane zostaną usunięte z obserwowanego kanału, gdy zostanie przekierowany do zamierzonej usługi ukrytej, w którym to momencie haker zgubi trop. Ponieważ serwer będzie również narażony na działanie usługi frontingu, gdy dane docierają tam, do usługi frontingowej zostanie wysłany drugi równoległy sygnał SNI w celu przekierowania danych do usługi ukrytej i zmiany w tym kierunku procesu, haker zagubić się w sieci serwera. Ten mechanizm podwójnych biletów jest dalej rozwijany w bilet łączony w ramach tego samego SNI. Gdy jeden fragment danych jest wysyłany do serwera, generuje on współpracujący przekierowanie SNI i oba te elementy współpracują w celu pobrania zaszyfrowanych danych TLS tam, gdzie muszą się udać. Bez możliwości złamania losowej usługi frontingu, która obejmuje obie ścieżki SNI, haker nie będzie w stanie śledzić danych, ale serwer nadal będzie mógł je połączyć i odszyfrować usługę ukrytą jako ostateczną lokalizację danych. Pozwala to serwerom na dalsze korzystanie z SNI w celu optymalizacji transferu danych w szyfrowaniu TLS, zapewniając jednocześnie, że hakerzy nie będą w stanie wykorzystać mechanizmu SNI.