SSTP i SSL 3.0: etykieta kontra wynegocjowana wersja

Dwie osoby mogą spojrzeć na to samo wdrożenie SSTP i dojść do przeciwnych wniosków. Jedna czyta dokumentację produktu, widzi litery SSL i zakłada, że tunel uruchamia protokół wycofany lata temu. Druga wskazuje nowoczesny handshake i uznaje sprawę za zamkniętą. Obie spierają się o etykiety, a nie o wynegocjowaną wersję, a tylko jedno z tych podejść jest dowodem. Porównanie, które warto przeprowadzić, dotyczy tego, co obiecuje nazwa, i tego, co usługa faktycznie wybiera.

Dwie odpowiedzi na to samo pytanie

Argument z etykiety łatwo sformułować: SSTP opisuje się jako bezpieczny protokół tunelowania przez gniazda, historyczna nazwa mówi SSL, więc połączenie musi działać na SSL 3.0. Utrzymuje się, bo nazwa naprawdę pochodzi z tej linii i bo większość osób, które to powtarzają, nigdy nie spojrzała na handshake. Utrzymuje się także dlatego, że wniosek brzmi zachowawczo, jakby założenie najgorszego było bezpiecznym wyborem. Zakładać najgorsze i mierzyć rzeczywistą wersję to dwie różne czynności, a tylko jedna z nich coś zmienia.

Argument z dowodu zadaje węższe pytanie. Na jaką wersję protokołu zgodziły się ten klient i ten serwer, na tym punkcie końcowym, w tym momencie? Odpowiedź pochodzi od usługi, która kończy TLS, a nie ze strony marketingowej ani z przeglądarki, która trafiła na podobnie nazwany serwis.

Oba argumenty różnią się tym, co mogą udowodnić. Etykieta nie odróżnia starego wdrożenia od załatanej wersji, a handshake nie powie, co robi niezwiązana usługa na tym samym hoście. Używaj drugiego i przestań używać pierwszego.

Odczytaj wersję, którą usługa faktycznie wybiera

Zacznij od nazwania komponentów: implementacji klienta, implementacji serwera, punktu końcowego TLS i wszystkiego pomiędzy, co kończy i ponownie nawiązuje TLS. Moduł równoważenia obciążenia, który kończy TLS i mówi do backendu zwykłym HTTP, zmienia to, czyją politykę musisz odczytać.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

Zapisz punkt końcowy i czas obok wyniku, bo późniejsza zmiana polityki czyni niedatowaną obserwację bezużyteczną. Powtórz próbę z klienta na tej samej ścieżce sieciowej co użytkownicy, na których ci zależy, ponieważ urządzenie przechwytujące może kończyć TLS własnymi ustawieniami. Jeśli oba stanowiska się nie zgadzają, znalazłeś komponent, który ma znaczenie. Jeśli się zgadzają, masz dowód zamiast sloganu.

Oddziel pole rekordu od negocjacji

Numer wersji wyglądający staroświecko w jednym polu to nie to samo co sesja SSL 3.0. RFC 7568 traktuje wersję warstwy rekordu i wynegocjowany protokół jako odrębne sprawy i właśnie z tego rozróżnienia biorą się pewne siebie błędne odpowiedzi. Odczytaj wynegocjowany protokół, potem szyfr, a dopiero potem wyciągnij wniosek o sesji.

Ten sam dokument jest jednoznaczny co do samego protokołu: SSL 3.0 nie wolno używać, a negocjacja lub fallback do niego są zabronione. Powodem jest wadliwa konstrukcja CBC wykorzystana przez atak POODLE, a to cecha protokołu, nie konfiguracja jednej aplikacji.

Dlatego „to obciążenie robocze prawdopodobnie trudno wykorzystać” nie jest argumentem za pozostawieniem SSL 3.0 włączonego. Wymaganie polega na usunięciu protokołu, a nie na wygraniu debaty o jednej demonstracji.

Wycofaj SSL 3.0 z polityką, którą możesz utrzymać

W Windows ustawienia protokołów Schannel znajdują się pod kluczem Protocols i są czytane osobno dla roli klienta i serwera, dlatego zmiana naprawiająca jeden kierunek może pozostawić drugi nietknięty. Bieżące ustawienia i wymagania dotyczące ponownego uruchomienia dokumentuje Microsoft, a biblioteka TLS firmy trzeciej na tym samym hoście całkowicie je ignoruje.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

Zmień politykę wspieraną ścieżką administracyjną, potwierdź, że usługa będąca właścicielem ponownie odczytuje konfigurację, i zachowaj zatwierdzoną drogę powrotu. Wklejenie szerokiego skryptu rejestru z innego środowiska to sposób, w jaki naprawa jednej usługi staje się awarią wszystkich klientów TLS na maszynie. Zakres ponownego uruchomienia ma tu znaczenie: ustawienie, które wygląda na zastosowane, może nadal tkwić w pamięci usługi, która go nie przeładowała.

Peer, który nadal wymaga przestarzałej wersji, potrzebuje aktualizacji lub planu migracji. Nieudokumentowany wyjątek, który po cichu przywraca stary protokół, nie jest strategią zgodności i nie przetrwa następnego audytu.

Odbierz zmianę na nowych połączeniach

Testuj na nowych sesjach po zmianie polityki, ponieważ połączenie nawiązane przed zmianą niczego nie dowodzi o konfiguracji obecnie obowiązującej. Potwierdź, że zatwierdzony protokół działa, a zabroniony zawodzi w autoryzowanym procesie walidacji, a następnie pozostaw tożsamość certyfikatu i kontrole zaufania dokładnie takie, jak były.

Pamiętaj, czego handshake nie obejmuje. SSTP przenosi uwierzytelnianie PPP po warstwie TLS, więc nowoczesna wersja protokołu nic nie mówi o tym, który użytkownik został autoryzowany ani do jakich zasobów sesja może dotrzeć. To odrębne mechanizmy kontroli z odrębnymi dowodami.

Zapisz wynik jako usługa, backend, dozwolona polityka i zaobserwowana wersja. Taki zapis precyzyjnie odpowiada na pytanie o bezpieczeństwo, czego nie robi ani argument z etykiety, ani argument z niedogodności.