SSTP-laga forklart: kva den indre pakken framleis avslører

SSTP pakkar PPP og ein indre pakke inn i TLS, men den ytre TCP-tilkoplinga viser framleis kven som snakka med kven. Merk kvart lag før du les eit opptak.

To tilhøve ved SSTP smeltar saman i dei fleste forklaringar, og nettopp den samansmeltinga gjer opptak forvirrande. Applikasjonspakken overlever inne i den verna kanalen, og TCP-tilkoplinga som ber kanalen held på sine eigne adresser heile vegen. Det som går på leidningen, er ein bera pluss lasta, aldri ei erstatning for nokon av dei. Gå gjennom stakken frå utsida og inn, og merk kvar grense du kryssar.

Start ved den ytre beraen

Det første på leidningen er ei vanleg TCP-tilkopling til port 443, med verkelege adresser som rutarar sender vidare. Det er denne tilkoplinga som overlever nettverksadresseomsetjing, og som ein tilgangsleverandør kan telje. Å verne lasta fjernar ikkje beraen, og det skjuler korkje volum eller tid.

Alt etter dette punktet blir bore i staden for ruta. Beraen held fram med å verke sjølv når den indre utvekslinga sviktar.

Følg innkapslinga innover

Inne i den verna kanalen ligg ei SSTP-kontrollutveksling, deretter ein PPP-økt og deretter nettverkspakken som klienten vil ha levert. Kvart lag har si eiga forhandling, sine eigne feilmeldingar og si eiga tilstandsmaskin. Derfor kan ein feil sjå ut som ein TLS-feil frå eitt ståstad og ein PPP-feil frå eit anna. Å lese laga i rekkjefølgje fortel kva tilstandsmaskin som stoppa.

Eitt opptak viser sjeldan heile stakken. Ytre headarar er berre synlege utanfor endepunktet, og indre først etter avkapsling. Den asymmetrien kjem frå kvar du står, ikkje frå protokollen.

Diagrammet nedanfor grupperer laga slik at dei i det heile kan drøftast. Det er ikkje eit byte-oppsett, det lovar ikkje éin post per pakke, og det seier ingenting om kor mange kryptografiske operasjonar ein implementasjon utfø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

Merk observatøren før du les eit opptak

To opptak av same økt svarar på ulike spørsmål, og grensesnittet dei vart tekne på avgjer kva for nokre. På tilgangsvegen ser du beraen og TLS-postane, og du kan måle storleikar og intervall utan å sjå ei indre adresse. Ved endepunktet, etter avkapsling, er den indre pakken vanleg trafikk under den private vidaresendingspolitikken.

Skriv grensesnittet og retninga på kvart opptak før du tolkar det. Eit spor frå ein fysisk adapter vil aldri vise adressene til den indre applikasjonen som vanlege ytre felt, og å lese den mangelen som ein krypteringsfeil er ein vanleg feil. Eit spor frå innsida av tunnelen viser ingen bera i det heile, så det kan ikkje svare på eit spørsmål om synet til leverandøren. Den same disiplinen gjeld loggane til endepunktet, som registrerer forhandlingsrekkjefølgja og ikkje innhaldet.

Hald på kontrollane som diagrammet ikkje kan prove

Lagrekkjefølgja beviser ikkje at ein utrulling validerer servercertifikatet, forhandlar ein støtta TLS-versjon eller autoriserer kontoen. Kvar av dei er ei konfigurasjonsavgjerd som sviktar uavhengig av innkapslinga.

Stadfest dei med ein klient som rapporterer kva han forhandla, i staden for å resonnere frå ei teikning. Start med TLS-handtrykket, deretter SSTP-utvekslinga, deretter PPP, og stopp ved det første trinnet som rapporterer ein feil. Den første kommandoen skriv ut kjeda og den forhandla versjonen, og den andre listar opp handtrykka som finst i eit opptak.

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

Relaterte artiklar