SSTP is PPP oer HTTPS, net in webside op poarte 443
TLS en in HTTP-fersyk iepenje it kanaal, dan dogge kontrôleberjochten en PPP de rest. Rin de fases troch en sjoch wêrom’t in browserproef sa min bewiist.
SSTP draacht PPP binnen in HTTPS-ferbining, dêrom liket it foar alles yn it midden op webtrafyk. TLS en HTTP sette it bûtenkanaal op, dan meitsje SSTP-kontrôleberjochten de tunnel klear en PPP leveret it gedrach fan ’e sesje. In browser dy’t in side op itselde adres laden hat mar in diel fan ’e earste fase foltôge. Dat as VPN-proef beskôgje is de manier wêrop’t in wurkjende proxy de skuld kriget fan in protokolferskil.
Rin de fjouwer fases yn folchoarder troch, en de flater dy’tsto sjochst falt yn ien fan har.
Fase 1: TCP en TLS
De klient iepenet in TCP-ferbining nei poarte 443 en docht in TLS-hânskodding. De sertifikaatkeatling moat oerienkomme mei de hostnamme dêr’t de klient mei konfigurearre is. In namferskil hjir jout in flater foardat der hokker SSTP-berjocht dan ek útwiksele wurdt, en de SSTP-spesifikaasje giet derfan út dat dit bûtenste HTTPS-kanaal al bestiet. Neat yn ’e lettere fases kin in fertrouwensflater hjir kompensearje.
In gewoane webserver kin dizze fase perfekt ôfmeitsje en dochs misse yn ’e folgjende. TLS-sukses is bewiis oer it sertifikaat, net oer it protokol dêrefter.
Fase 2: it HTTPS-fersyk
SSTP docht syn fersyk mei in spesifike metoade, SSTP_DUPLEX_POST, en hâldt de útwikseling iepen yn stee fan in dokumint werom te jaan. In server of proxy dy’t foar gewoane sidefersiken konfigurearre is, kin de ferbining akseptearje en dan de metoade ôfwize. Dy ôfwizing is it kompatibiliteitsprobleem dat minsken meastentiids beskriuwe as in blokkearre poarte 443.
Lês de antwurdkoade en de metoade yn it serverlog. In ôfwizing yn dizze fase is in oar probleem as in TCP-timeout, en beide liede ta ferskate reparaasjes.
Fase 3: kontrôleberjochten
Sadree’t it fersyk akseptearre is, wikselet SSTP kontrôleberjochten út dy’t de tunnel ûnderhannelje en klearmeitsje. It binne protokolberjochten binnen it HTTPS-lichem, net HTTP-fersiken, dus in proxy dy’t lichems ynspektearret en oerskriuwt kin se brekke wylst sidefersiken ûnoantaast bliuwe.
Hjir fertsjinnet in middleware foar djipynspeksje syn reputaasje. As siden lade en de VPN misse, kontrolearje dan of it lichem feroare wurdt yn stee fan oft de poarte iepen is.
Fase 4: PPP nimt oer
Dan leveret PPP it gedrach fan ’e sesje: keppelingsûnderhanneling, autentikaasje en de konfiguraasje fan ’e netwurklaach dy’t folget. PPP-autentikaasje stiet apart fan ’e TLS-kontrôle dy’t de klient al slagge is. In serversertifikaat dat de klient akseptearret seit neat oer oft de ynloggegevens fan ’e brûker jildich binne of it akkount autorisearre is.
In akseptearre sertifikaat en in ôfwiisde oanmelding binne net tsjinstridich. It binne opienfolgjende fases mei ûnôfhinklike útkomsten.
Autentikaasje hat ferskate rollen
De klient falidearret de identiteit fan ’e TLS-server tsjin syn fertrouwensopslach en de konfigurearre namme. Dan autentisearret PPP de brûker of de masine, ôfhinklik fan ’e útrôl. De server kin syn eigen belied tafoegje oer wa’t ferbine mei en wat se berikke meie. Hâld de hostnamme yn oerienstimming mei de sertifikaatidentiteit, want in rûge adres ferfangt in wurkjende opset troch in namkontrôleflater.
Skriuw op hokker fase de flater rapportearre. Sertifikaat, metoade, kontrôleberjocht, PPP-autentikaasje, dan rûtes: fiif plakken, fiif reparaasjes.
Wat in browserproef sjen kin en wat net
In side op it adres lade bewiist DNS-oplossing, TCP-berikberens en dat der eat harket dat HTTP praat. It bewiist net dat de metoade akseptearre wurdt, de kontrôleútwikseling oerlibbet of PPP-autentikaasje konfigurearre is. Brûk in klient dy’t SSTP ymplementearret yn stee fan in oar profyl om te setten troch de poarte te feroarjen.
As de sesje ienris stiet, beslute rûtes, DNS en trochstjoering oan ’e serverkant noch hieltiten wat de brûker berikke kin. De tunnel is in paad, gjin autorisaasje.