Warstwy SSTP wyjaśnione: co wciąż ujawnia pakiet wewnętrzny

W większości wyjaśnień dwa fakty o SSTP zlewają się w jeden, i właśnie to zlanie czyni przechwycenia mylącymi. Pakiet aplikacji przeżywa wewnątrz chronionego kanału, a połączenie TCP niosące ten kanał przez cały czas zachowuje własne adresy. Po drucie idzie nośnik wraz z ładunkiem, nigdy zamiennik któregokolwiek z nich. Przejdź stos od zewnątrz do wewnątrz i oznacz każdą granicę, którą przekraczasz.

Zacznij od zewnętrznego nośnika

Pierwszą rzeczą na drucie jest zwykłe połączenie TCP do portu 443, z prawdziwymi adresami, które routery przekazują dalej. To właśnie to połączenie przeżywa tłumaczenie adresów sieciowych i to, co dostawca dostępu może policzyć. Ochrona ładunku nie usuwa nośnika, i nie ukrywa objętości ani czasu.

Wszystko po tym punkcie jest niesione, a nie trasowane. Nośnik działa dalej nawet wtedy, gdy wewnętrzna wymiana zawodzi.

Podążaj za enkapsulacją do wewnątrz

Wewnątrz chronionego kanału znajduje się wymiana sterująca SSTP, potem sesja PPP, potem pakiet sieciowy, który klient chce otrzymać. Każda warstwa ma własne negocjacje, własne komunikaty o błędach i własną maszynę stanów. Dlatego awaria może wyglądać jak awaria TLS z jednego punktu widzenia, a jak awaria PPP z innego. Czytanie warstw po kolei mówi, która maszyna stanów się zatrzymała.

Jedno przechwycenie rzadko pokazuje cały stos. Zewnętrzne nagłówki widać tylko poza punktem końcowym, a wewnętrzne dopiero po deenkapsulacji. Ta asymetria wynika z miejsca, w którym stoisz, a nie z protokołu.

Poniższy diagram grupuje warstwy, żeby w ogóle można było o nich mówić. Nie jest układem bajtów, nie obiecuje jednego rekordu na pakiet i nic nie mówi o tym, ile operacji kryptograficznych wykonuje implementacja.

outer IP header
  TCP to port 443
    TLS record layer
      SSTP control and data packets
        PPP frames
          inner IP packet
            application transport and payload

Oznacz obserwatora, zanim przeczytasz przechwycenie

Dwa przechwycenia tej samej sesji odpowiadają na różne pytania, a decyduje o tym interfejs, na którym je wykonano. Na ścieżce dostępu widzisz nośnik i rekordy TLS, i możesz mierzyć rozmiary oraz odstępy, nie widząc adresu wewnętrznego. W punkcie końcowym, po deenkapsulacji, pakiet wewnętrzny jest zwykłym ruchem w ramach prywatnej polityki przekazywania.

Zapisz interfejs i kierunek na każdym przechwyceniu, zanim je zinterpretujesz. Ślad z fizycznego adaptera nigdy nie pokaże adresów wewnętrznej aplikacji jako zwykłych pól zewnętrznych, a czytanie tego braku jako awarii szyfrowania to częsty błąd. Ślad z wnętrza tunelu nie pokazuje żadnego nośnika, więc nie może odpowiedzieć na pytanie o widok dostawcy. Ta sama dyscyplina dotyczy dzienników punktu końcowego, które zapisują kolejność negocjacji, a nie treść.

Zachowaj kontrole, których diagram nie może dowieść

Kolejność warstw nie dowodzi, że wdrożenie weryfikuje certyfikat serwera, negocjuje obsługiwaną wersję TLS ani autoryzuje konta. Każde z nich to decyzja konfiguracyjna, która zawodzi niezależnie od enkapsulacji.

Sprawdź je klientem, który raportuje, co wynegocjował, zamiast wnioskować z rysunku. Zacznij od uścisku dłoni TLS, potem wymiany SSTP, potem PPP, i zatrzymaj się na pierwszym etapie, który zgłosi błąd. Pierwsze polecenie wypisuje łańcuch i wynegocjowaną wersję, a drugie wymienia uściski dłoni obecne w przechwyceniu.

openssl s_client -connect vpn.corp.internal:443 -servername vpn.corp.internal
tshark -r sstp.pcap -Y "tls.handshake.type == 1"