SSTP-lagene forklart: hva den indre pakken fortsatt avslører

SSTP pakker PPP og en indre pakke inn i TLS, men den ytre TCP-forbindelsen viser fortsatt hvem som snakket med hvem. Merk hvert lag før du leser et opptak.

To forhold ved SSTP smelter sammen i de fleste forklaringer, og nettopp den sammensmeltingen gjør opptak forvirrende. Applikasjonspakken overlever inne i den beskyttede kanalen, og TCP-forbindelsen som bærer kanalen beholder sine egne adresser hele veien. Det som går på ledningen, er en bærer pluss lasten, aldri en erstatning for noen av dem. Gå gjennom stakken fra utsiden og inn, og merk hver grense når du krysser den.

Start ved den ytre bæreren

Det første på ledningen er en vanlig TCP-forbindelse til port 443, med virkelige adresser som rutere videresender. Det er denne forbindelsen som overlever nettverksadresseoversettelse, og som en tilgangsleverandør kan telle. Å beskytte lasten fjerner ikke bæreren, og det skjuler verken volum eller tid.

Alt etter dette punktet bæres i stedet for å rutes. Bæreren fortsetter å virke selv når den indre utvekslingen feiler.

Følg innkapslingen innover

Inne i den beskyttede kanalen ligger en SSTP-kontrollutveksling, deretter en PPP-økt og deretter nettverkspakken som klienten vil ha levert. Hvert lag har sin egen forhandling, sine egne feilmeldinger og sin egen tilstandsmaskin. Derfor kan en feil se ut som en TLS-feil fra ett ståsted og en PPP-feil fra et annet. Å lese lagene i rekkefølge forteller hvilken tilstandsmaskin som stoppet.

Ett opptak viser sjelden hele stakken. Ytre headere er bare synlige utenfor endepunktet, og indre først etter avkapsling. Den asymmetrien kommer fra hvor du står, ikke fra protokollen.

Diagrammet nedenfor grupperer lagene slik at de i det hele tatt kan drøftes. Det er ikke et byte-oppsett, det lover ikke én post per pakke, og det sier ingenting om hvor mange kryptografiske operasjoner en 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 leser et opptak

To opptak av samme økt svarer på ulike spørsmål, og grensesnittet de ble tatt på avgjør hvilke. På tilgangsveien ser du bæreren og TLS-postene, og du kan måle størrelser og intervaller uten å se en indre adresse. Ved endepunktet, etter avkapsling, er den indre pakken vanlig trafikk under den private videresendingspolitikken.

Skriv grensesnittet og retningen på hvert opptak før du tolker det. Et spor fra en fysisk adapter vil aldri vise den indre applikasjonens adresser som vanlige ytre felt, og å lese den mangelen som en krypteringsfeil er en vanlig feil. Et spor fra innsiden av tunnelen viser ingen bærer i det hele tatt, så det kan ikke svare på et spørsmål om leverandørens syn. Den samme disiplinen gjelder endepunktets logger, som registrerer forhandlingsrekkefølgen og ikke innholdet.

Behold kontrollene som diagrammet ikke kan bevise

Lagrekkefølgen beviser ikke at en utrulling validerer servercertifikatet, forhandler en støttet TLS-versjon eller autoriserer kontoen. Hver av dem er en konfigurasjonsbeslutning som feiler uavhengig av innkapslingen.

Verifiser dem med en klient som rapporterer hva den forhandlet, i stedet for å resonnere fra en tegning. Start med TLS-håndtrykket, deretter SSTP-utvekslingen, deretter PPP, og stopp ved det første trinnet som rapporterer en feil. Den første kommandoen skriver ut kjeden og den forhandlede versjonen, og den andre lister opp håndtrykkene som finnes i et opptak.

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

Relaterte artikler