SSTP-lag forklaret: hvad den indre pakke stadig afslører

To forhold om SSTP smelter sammen i de fleste forklaringer, og netop den sammensmeltning gør optagelser forvirrende. Applikationspakken overlever inde i den beskyttede kanal, og den TCP-forbindelse, der bærer kanalen, beholder sine egne adresser hele vejen. Det, der løber på ledningen, er en bærer plus dens last, aldrig en erstatning for nogen af dem. Gå gennem stakken udefra og ind, og mærk hver grænse, når du krydser den.

Start ved den ydre bærer

Det første på ledningen er en almindelig TCP-forbindelse til port 443 med rigtige adresser, som routere videresender. Det er den forbindelse, der overlever netværksadresseoversættelse, og som en adgangsudbyder kan tælle. Beskyttelse af lasten fjerner ikke bæreren, og den skjuler ikke mængde eller timing.

Alt efter dette punkt bæres i stedet for at blive rutet. Bæreren fungerer stadig, selv når den indre udveksling fejler.

Følg indkapslingen indad

Inde i den beskyttede kanal ligger en SSTP-styreudveksling, derefter en PPP-session og derefter den netværkspakke, som klienten vil have leveret. Hvert lag har sin egen forhandling, sine egne fejlmeddelelser og sin egen tilstandsmaskine. Derfor kan en fejl se ud som en TLS-fejl fra ét synspunkt og en PPP-fejl fra et andet. Læs lagene i rækkefølge, og du ved, hvilken tilstandsmaskine der stoppede.

En enkelt optagelse viser sjældent hele stakken. Ydre headere er kun synlige uden for endepunktet, og indre headere først efter afkapsling. Den asymmetri kommer fra, hvor du står, ikke fra protokollen.

Diagrammet nedenfor grupperer lagene, så de overhovedet kan drøftes. Det er ikke et byte-layout, det lover ikke én post pr. pakke, og det siger intet om, hvor mange kryptografiske operationer en implementering udfører.

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

Mærk observatøren, før du læser en optagelse

To optagelser af samme session besvarer forskellige spørgsmål, og det interface, de er taget på, afgør hvilke. På adgangsvejen ser du bæreren og TLS-posterne, og du kan måle størrelser og intervaller uden at se en indre adresse. Ved endepunktet, efter afkapsling, er den indre pakke almindelig trafik under den private videresendelsespolitik.

Skriv interfacet og retningen på hver optagelse, før du fortolker den. Et spor fra en fysisk adapter vil aldrig vise den indre applikations adresser som almindelige ydre felter, og at læse den manglende synlighed som en krypteringsfejl er en almindelig fejl. Et spor inde fra tunnelen viser slet ingen bærer, så det kan ikke besvare et spørgsmål om udbyderens syn. Den samme disciplin gælder endepunktets logfiler, som registrerer forhandlingsrækkefølgen og ikke indholdet.

Behold de kontroller, som diagrammet ikke kan bevise

Lagrækkefølge beviser ikke, at en udrulning validerer servercertifikatet, forhandler en understøttet TLS-version eller autoriserer kontoen. Hver af dem er en konfigurationsbeslutning, der fejler uafhængigt af indkapslingen.

Kontrollér dem med en klient, der rapporterer, hvad den forhandlede, i stedet for at ræsonnere ud fra en tegning. Start med TLS-handshake, derefter SSTP-udvekslingen, derefter PPP, og stop ved det første trin, der rapporterer en fejl. Den første kommando udskriver kæden og den forhandlede version, og den anden viser de handshakes, der findes i en optagelse.

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