SSTP-lae verduidelik: wat die binneste pakket steeds verraai

SSTP verpak PPP en 'n binneste pakket in TLS, maar die buitenste TCP-verbinding wys steeds wie met wie gepraat het. Benoem elke laag voordat jy 'n opname lees.

Twee feite oor SSTP word in die meeste verklarings saamgevoeg, en juis dié samevoeging maak opnames verwarrend. Die toepassingspakket bly binne die beskermde kanaal voortbestaan, en die TCP-verbinding wat daardie kanaal dra, behou deurgaans sy eie adresse. Wat oor die draad beweeg, is 'n draer plus sy vrag, nooit 'n plaasvervanger vir enigeen van die twee nie. Stap die stapel van buite na binne en benoem elke grens wanneer jy dit oorsteek.

Begin by die buitenste draer

Die eerste ding op die draad is 'n gewone TCP-verbinding na poort 443, met werklike adresse wat routers aanstuur. Daardie verbinding is wat netwerkadresvertaling oorleef en wat 'n toegangsverskaffer kan tel. Die beskerming van die vrag verwyder nie die draer nie, en dit verberg ook nie volume of tydsberekening.

Alles ná hierdie punt word gedra eerder as gerouteer. Die draer bly werk selfs wanneer die binneste uitruiling misluk.

Volg die inkapseling na binne

Binne die beskermde kanaal sit 'n SSTP-beheersuitruiling, dan 'n PPP-sessie, dan die netwerkpakket wat die kliënt wil hê afgelewer moet word. Elke laag het sy eie onderhandeling, sy eie foutboodskappe en sy eie toestandmasjien. 'n Fout kan dus van een oogpunt soos 'n TLS-fout lyk en van 'n ander soos 'n PPP-fout. Om die lae in volgorde te lees, sê vir jou watter toestandmasjien gestop het.

Een enkele opname wys selde die hele stapel. Buitenste kopskrifte is net buite die eindpunt sigbaar, en binneste kopskrifte net ná dekapsulering. Daardie asimmetrie kom uit waar jy staan, nie uit die protokol se reëls nie.

Die diagram hieronder groepeer die lae sodat mense daaroor kan praat. Dit is nie 'n grepe-uitleg nie, dit belowe nie een rekord per pakket nie, en dit sê niks oor hoeveel kriptografiese bewerkings 'n implementering uitvoer nie.

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

Benoem die waarnemer voordat jy 'n opname lees

Twee opnames van een sessie beantwoord verskillende vrae, en die koppelvlak waarop hulle geneem is, bepaal watter een. Op die toegangspad sien jy die draer en die TLS-rekords, en jy kan groottes en tussenposes meet sonder om 'n binneste adres te sien. By die eindpunt, ná dekapsulering, is die binneste pakket gewone verkeer onder die private aanstuurbeleid.

Skryf die koppelvlak en die rigting op elke opname voordat jy dit interpreteer. 'n Spoor vanaf 'n fisiese adapter sal nooit die binneste toepassing se adresse as gewone buitenste velde wys nie, en om daardie afwesigheid as 'n versuleringsfout te lees, is 'n algemene fout. 'n Spoor van binne die tonnel wys glad geen draer nie, so dit kan nie 'n vraag oor die verskaffer se siening beantwoord nie. Dieselfde dissipline geld vir eindpuntlogboeke, wat onderhandelingsorde eerder as inhoud aanteken.

Behou die kontroles wat die diagram nie kan bewys nie

Laagorde bewys nie dat 'n ontplooiing die sertifikaat van die bediener valideer, 'n ondersteunde TLS-weergawe onderhandel of die rekening magtig nie. Elkeen van dié is 'n konfigurasiebesluit wat onafhanklik van die inkapseling misluk.

Verifieer hulle met 'n kliënt wat rapporteer wat dit onderhandel het eerder as om uit 'n tekening af te lei. Begin met die TLS-handdruk, dan die SSTP-uitruiling, dan PPP, en stop by die eerste stadium wat 'n fout rapporteer. Die eerste opdrag druk die ketting en die onderhandelde weergawe, en die tweede lys die handdrukke wat in 'n opname voorkom.

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

Verwante artikels