SSTP-lagren förklarade: vad det inre paketet fortfarande avslöjar

SSTP packar PPP och ett inre paket i TLS, men den yttre TCP-anslutningen visar fortfarande vem som talade med vem. Märk varje lager innan du läser en fångst.

Två fakta om SSTP smälter samman i de flesta förklaringar, och just den sammansmältningen gör fångster förvirrande. Applikationspaketet överlever inne i den skyddade kanalen, och TCP-anslutningen som bär kanalen behåller sina egna adresser hela vägen. Det som går på ledningen är en bärare plus dess last, aldrig en ersättning för någon av dem. Gå genom stacken utifrån och in och märk varje gräns du korsar.

Börja vid den yttre bäraren

Det första på ledningen är en vanlig TCP-anslutning till port 443, med riktiga adresser som routrar vidarebefordrar. Det är den anslutningen som överlever nätverksadressöversättning och som en åtkomstleverantör kan räkna. Att skydda lasten tar inte bort bäraren, och det döljer varken volym eller tid.

Allt efter denna punkt bärs i stället för att routas. Bäraren fortsätter att fungera även när det inre utbytet misslyckas.

Följ inkapslingen inåt

Inne i den skyddade kanalen ligger ett SSTP-styrutbyte, sedan en PPP-session och sedan nätverkspaketet som klienten vill få levererat. Varje lager har sin egen förhandling, sina egna felmeddelanden och sin egen tillståndsmaskin. Därför kan ett fel se ut som ett TLS-fel från en synvinkel och ett PPP-fel från en annan. Att läsa lagren i ordning säger vilken tillståndsmaskin som stannade.

En enda fångst visar sällan hela stacken. Yttre huvuden är bara synliga utanför ändpunkten, och inre först efter avkapsling. Den asymmetrin kommer från var du står, inte från protokollet.

Diagrammet nedan grupperar lagren så att de alls kan diskuteras. Det är ingen bytelayout, det lovar inte en post per paket, och det säger ingenting om hur många kryptografiska operationer en implementering utför.

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 innan du läser en fångst

Två fångster av samma session besvarar olika frågor, och gränssnittet de togs på avgör vilka. På åtkomstvägen ser du bäraren och TLS-posterna, och du kan mäta storlekar och intervall utan att se en inre adress. Vid ändpunkten, efter avkapsling, är det inre paketet vanlig trafik under den privata vidarebefordringspolicyn.

Skriv gränssnittet och riktningen på varje fångst innan du tolkar den. Ett spår från en fysisk adapter kommer aldrig att visa den inre applikationens adresser som vanliga yttre fält, och att läsa den frånvaron som ett krypteringsfel är ett vanligt misstag. Ett spår inifrån tunneln visar ingen bärare alls, så det kan inte besvara en fråga om leverantörens syn. Samma disciplin gäller ändpunktens loggar, som registrerar förhandlingsordningen och inte innehållet.

Behåll de kontroller som diagrammet inte kan bevisa

Lagerordningen bevisar inte att en driftsättning validerar servercertifikatet, förhandlar en stödd TLS-version eller auktoriserar kontot. Var och en av dem är ett konfigurationsbeslut som misslyckas oberoende av inkapslingen.

Verifiera dem med en klient som rapporterar vad den förhandlade i stället för att resonera från en ritning. Börja med TLS-handskakningen, sedan SSTP-utbytet, sedan PPP, och stanna vid det första steget som rapporterar ett fel. Det första kommandot skriver ut kedjan och den förhandlade versionen, och det andra listar handskakningarna som finns i en fångst.

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

Relaterade artiklar