TLS podróżuje wewnątrz kanału kontrolnego, a nie całym tunelem

Zobaczenie słowa TLS w opisie VPN i wyciągnięcie wniosku, że proxy internetowe zrozumie ten ruch, to częsty skrót. Wewnątrz tego protokołu peery wymieniają własne pakiety, a TLS działa jako część jednego kanału w tej wymianie. Ładunek, na którym zależy użytkownikowi, podróżuje w innym formacie wiadomości, dlatego oba nigdy nie zgadzają się ze zwykłą sesją HTTPS.

Najpierw przychodzi koperta

Każdy pakiet tunelu zaczyna się od własnego nagłówka protokołu: typu wiadomości, identyfikatora klucza oraz, w transporcie strumienia bajtów, prefiksu długości, który znaczy, gdzie pakiet się kończy. Czytelnik, który nie analizuje tej koperty, nie może wiedzieć, gdzie zaczyna się następne pole.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

Ten szkic jest mapą, a nie tabelą bajtów, ponieważ dokładne pola zależą od typu wiadomości, choć pierwszy oktet zawsze pakuje razem kod operacji i identyfikator klucza. Zgadywanie typu wiadomości z numeru portu to sposób, w jaki dekodery kończą na błędnym nazywaniu tego, co widzą. Kolejność ma znaczenie dla diagnostyki: transport, potem koperta protokołu, potem jeden z dwóch rodzajów pracy. Przeczytaj kopertę, zanim wyrobisz sobie opinię o tym, co następuje. Dekoder, który zaczyna w złym miejscu, produkuje pewne siebie bzdury.

Warstwa niezawodności należy do protokołu

Komunikaty kontrolne wymagają uporządkowanego, potwierdzonego dostarczania, a protokół sam to zapewnia potwierdzeniami i retransmisjami. Potwierdzenie może przyjść jako własny komunikat lub podróżować z innym komunikatem kontrolnym, co sprawia, że ślady wyglądają nieregularnie dla każdego, kto oczekuje jednej czystej wymiany.

Zaletą jest to, że uścisk dłoni TLS dostaje niezawodnego nośnika nawet wtedy, gdy transport zewnętrzny to UDP. Kosztem jest to, że pojedynczy datagram może zawierać tylko część tej rozmowy, więc traktowanie go jako samodzielnego rekordu TLS daje bzdury. Ponowne składanie musi odbywać się na warstwie protokołu. Dlatego przechwycony pakiet rzadko wygląda jak kompletny krok uścisku dłoni.

Przełączenie transportu zewnętrznego na TCP nie usuwa tej warstwy. Niezawodny transport oznacza mniej retransmisji na poziomie protokołu, a nie to, że ramkowanie znika lub ruch staje się HTTP.

Pakiety danych używają innego formatu

Gdy sesja istnieje, użyteczny ładunek przychodzi jako komunikaty danych przenoszące wewnętrzne pakiety IP lub ramki Ethernet. Są chronione własnymi kluczami i własnym przetwarzaniem i nie są rekordami aplikacji TLS w żadnym sensie, jaki zaakceptowałaby biblioteka TLS.

To rozdzielenie widać w konfiguracji: kanał kontrolny i kanał danych mają osobne ustawienia szyfrowania, więc wiersz logu nazywający jeden nic nie mówi o drugim. Czytanie silnego szyfru kontrolnego jako dowodu silnego szyfru danych to częsty błąd w raportach.

Trzymaj też powiązane błędne przekonanie poza wyjaśnieniem. TLS nie jest kanałem klucza publicznego obok symetrycznego kanału danych, ponieważ sam TLS chroni swoje rekordy symetrycznie po ustaleniu kluczy. Prawdziwa różnica to rola i format pakietu, a nie to, jakiego rodzaju kryptografii używa każda strona.

Dlaczego proxy HTTPS nie może pomóc

Proxy kończące TLS oczekuje strumienia rekordów TLS, a następnie protokołu aplikacji w nim. Kanał kontrolny tego protokołu jest przenoszony wewnątrz własnego ramkowania z warstwą niezawodności wokół, więc kończące proxy czyta to ramkowanie jako uszkodzone wejście.

Przezroczysty przekazywacz, który przepuszcza bajty lub datagramy bez ich interpretowania, może działać, pod warunkiem że nie przepisuje ani nie składa ponownie strumienia. Pytanie, które trzeba zadać o każdym pośredniku, brzmi, czy przekazuje rzeczywisty transport i ramkowanie, a nie czy gdzieś obsługuje TLS. Zapytaj o to, zanim spędzisz wieczór na regułach proxy. Większość niepowodzeń tutaj jest architektoniczna, a nie brakującym ustawieniem.

Prawidłowe czytanie śladu

Oczekuj najpierw wymiany kontrolnej, potem znacznie większej liczby komunikatów danych, oba dzielą jeden transport. Jeśli faza kontrolna się kończy, a faza danych zatrzymuje, usterka dotyczy kluczy, routingu lub filtrowania ścieżki danych, a nie uścisku dłoni. Przechwyć kilka komunikatów danych i sprawdź, czy w ogóle opuszczają klienta. Ta jedna obserwacja dzieli poszukiwania na pół.

Historyczne opisy metod klucza w dokumentacji protokołu nie oznaczają, że dane wydanie nadal obsługuje każdy stary format. Sprawdź wersję, którą uruchamiasz, zanim zbudujesz oczekiwanie na akapicie opisującym, jak sprawy działały wcześniej.