Gdzie siedzi TLS wewnątrz OpenVPN i co zmienia kształt

OpenVPN naprawdę używa TLS, a ludzie rutynowo rozciągają to na twierdzenie, którego ono nie udźwignie: że tunel dlatego wygląda jak przeglądarka odwiedzająca witrynę. Pierwsza część jest prawdziwa. Druga nie. TLS należy tu do kanału sterującego, który podróżuje wewnątrz własnego kontenera OpenVPN, obok kanału ładunku o zupełnie innej kryptografii, więc kto ogląda początkowe bajty, widzi OpenVPN.

Dwie rozmowy w jednej kopercie

Proszę myśleć o sesji jak o dwóch rozmowach dzielących jedną kopertę. Jedna weryfikuje certyfikaty i wyprowadza materiał klucza. Druga szyfruje to, co naprawdę wysyłasz, używając tego, co wytworzyła pierwsza.

Koperta to protokół. Każdy pakiet zaczyna się od małego nagłówka nazywającego jego typ, a ten nagłówek przychodzi przed wszystkim innym.

Co faktycznie przychodzi pierwsze

Z powodu tej kolejności pierwszą rzeczą na łączu nie jest rekord TLS. To nagłówek OpenVPN, po którym następuje zawartość tego kanału, który nagłówek ogłasza. ClientHello tam istnieje, tylko nie na bajcie zerowym. Do zauważenia różnicy nie potrzeba żadnego odszyfrowania, bo sam kształt ją zdradza.

Wartości domyślne też tu mają znaczenie. Strumień idzie przez UDP na 1194, chyba że profil wybierze TCP. W obu przypadkach wygląd zewnętrzny to tunel, a nie żądanie sieci web.

Trzy uczciwe sposoby zmiany kształtu

Terminator TLS, taki jak stunnel, przyjmuje TLS na porcie na obu końcach i przekazuje odszyfrowany strumień OpenVPN lokalnie, więc sieć widzi TLS na ten port. Protokół, który jest TLS od pierwszego bajtu, zachowuje się jeszcze inaczej: wymiana zgodna z AnyConnect, którą implementuje ocserv, przypomina korporacyjny dostęp zdalny, którego wiele sieci już oczekuje. SSTP, dostarczany z Windows, ma tę samą właściwość w innym produkcie.

W Linuksie opcja -w w SSH przenosi łącze punkt-punkt wewnątrz sesji SSH, co jest przydatne, gdy SSH jest jedynym dozwolonym protokołem. Jest najtańsza z czterech, jeśli SSH już działa z tej sieci, i najmniej przydatna, jeśli nie.

Czego żadna z nich nie zmienia

Żadna z nich nie zmienia tego, do czego tunel może dotrzeć. Nie czynią zablokowanego adresu osiągalnym, nikogo nie uwierzytelniają i nie decydują o trasach.

Otoczka kosztuje też jeden komponent. Dwaj słuchacze i dwa pliki konfiguracyjne oznaczają dwa miejsca awarii, a oba wyglądają identycznie z miejsca użytkownika. Zaplanuj to w budżecie, zanim ją przyjmiesz. Sesja pozostaje jednym długotrwałym szyfrowanym strumieniem do jednego celu, a jej objętość i czas pozostają widoczne.

Najpierw diagnoza, potem wybór

Więc najpierw diagnozuj. Odrzucony UDP odpowiada się trybem TCP, a rozpoznany podpis innym protokołem lub otoczką. Wybór narzędzia, zanim zna się blokadę, to droga, na której ludzie kończą z utrzymywaniem trzech warstw, które wszystkie zawodzą z tego samego powodu.

Sieć, która dopuszcza tylko porty web, zawęża wybór do protokołu opartego na TLS na porcie 443. Zastosowanie wszystkich trzech naraz daje stos, którego nikt nie potrafi odpluskwić, więc zmień jedną rzecz i ponownie przetestuj ten sam strumień.

Jeśli żadna nie pasuje, dokładna odpowiedź brzmi: ta sieć nie przeniesie tunelu dla ciebie. To ustalenie, a nie porażka wysiłku. Przechodzenie przez kolejne opcje nie odwraca decyzji politycznej podjętej wyżej.

Przed tym wszystkim stoi jedna granica. Zgoda na uruchamianie tunelu w cudzej sieci to kwestia polityki, rozstrzygana oddzielnie od tego, czy mechanizm działa. Te fakty wyjaśniają, co widzi obserwator, i nie dają zgody.