SSTP nyuma ya proksi inayokagua TLS: mahali ambapo kikao kinavunjika

Kivinjari chako kinapakia intraneti ya kampuni, cheti cha proksi kinaaminika, na bado mteja wa SSTP huanguka karibu na mwisho wa muunganisho. Mtindo huu unaonyesha tofauti kati ya ombi la wavuti na kikao kilichopitishwa kwenye handaki, si nenosiri lisilo sahihi. Pitia muunganisho kutoka TCP kwenda juu na uandike hatua ya kwanza inayoshindikana. Hatua, si msimbo wa hitilafu, inakuambia kama proksi ndiyo sababu.

Anza mahali mteja anaposimama

Mteja hupitia mfuatano maalum: muunganisho wa TCP kwenye bandari 443, makubaliano ya TLS, uthibitisho wa cheti, ubadilishanaji wa HTTP wa SSTP, majadiliano na uthibitishaji wa PPP, kisha usanidi wa IP. Kushindikana kwa kila hatua huacha alama tofauti, na kuzichanganya kunakuleta kwenye ukurasa usio sahihi wa usanidi.

Kushindikana kwa TCP ni kuzidi muda au kuweka upya kabla ya baiti yoyote ya TLS kutokea. Kushindikana kwa TLS ni onyo au kuzidi muda kwa makubaliano. Kushindikana kwa cheti hutoa onyo kuhusu mnyororo au jina. Kushindikana kwa HTTP huja baada ya makubaliano yenye mafanikio, mara nyingi kama msimbo wa hali au kufungwa papo hapo. Kushindikana kwa PPP huja baada ya handaki kuwekwa kitaalamu, ndiyo sababu huonekana kama tatizo la uthibitishaji.

Soma kumbukumbu ya mteja kwa hatua ya mwisho iliyofanikiwa, si mstari wa kwanza wa hitilafu. Mstari wa hitilafu kwa kawaida huripoti tokeo, wakati mpaka wa hatua hutaja sehemu iliyokataa.

Kile SSTP inachoomba mtandao kubeba

SSTP huendeshwa juu ya TLS kwenye TCP 443 na kisha hutuma ombi la HTTP linaloitwa SSTP_DUPLEX_POST, lililofafanuliwa katika vipimo vya SSTP, kwenda kwenye njia ya umbo /sra_{GUID}/. Ombi hilo hutangaza urefu wa maudhui usio na kikomo kivitendo na huweka mtiririko wazi pande zote mbili kwa muda wote wa kikao. Fremu za PPP husafiri ndani ya mtiririko huo.

Ndiyo sababu proksi inayoshughulikia uvinjari wa kawaida bado inaweza kushindikana. GET au POST yenye mwili wenye kikomo inaweza kuhifadhiwa kwa muda, kukaguliwa na kusambazwa; mtiririko wa dupleksi wenye mwili usioisha kamwe hauwezi. Proksi inayosubiri mwili ukamilike husubiri milele, na mteja hatimaye huzidi muda.

Uchujaji wa mbinu na uthibitishaji huongeza mbinu zao za kushindikana. Ikiwa proksi inaomba vitambulisho kwa ombi, mteja wa VPN anaweza asijibu ingawa kivinjari kingejibu. Ikiwa inaondoa au kuandika upya mbinu, lango hukataa ombi kabla PPP haijaanza.

Kwa nini ukaguzi hubadilisha utambulisho

Proksi inayokagua TLS humaliza muunganisho wa TLS wa mteja na kufungua muunganisho tofauti kwa lango. Kwa hiyo mteja huthibitisha cheti cha proksi, si cha lango, na lango huona proksi kama mwenzake. Kampuni inaposambaza mzizi wake, kivinjari na mteja wa VPN wote wanaweza kukubali mnyororo huo, hivyo makubaliano hufanikiwa na tatizo huhamia hatua inayofuata.

Uthibitisho wenye mafanikio haumaanishi kuwa proksi inaweza kubeba kikao. Bado inapaswa kusambaza POST ya pande mbili isiyo na kikomo bila kuhifadhi, na kuweka muunganisho wote wawili hai kwa saa nyingi. Bidhaa nyingi za ukaguzi zimejengwa kwa trafiki ya ombi-jibu na hushughulikia kisa hiki vibaya au kabisa.

Ndiyo sababu kuongeza mzizi usiojulikana au kuzima uthibitisho ni urekebishaji usio sahihi. Hubadilisha cheti ambacho mteja anakubali; haifanyi chochote kuhusu ushughulikiaji wa mtiririko uliovunja kikao kwa kweli.

Tambua mtoaji kabla ya kubadilisha mipangilio

Uliza kituo cha mwisho ni cheti gani kinachowasilisha na nani alisaini. Amri zilizo hapa chini zinaonyesha mnyororo na mtoaji bila kuanzisha kikao cha VPN:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Ikiwa mtoaji ni CA ya umma, muunganisho wa mwenyeji huyu haukatizwi na kushindikana kuko mahali pengine. Ikiwa mtoaji ni CA ya kampuni yenyewe, ukaguzi unafanya kazi na lango hufikiwa kwa njia ya proksi. Linganisha alama ya kidole na ile ambayo timu ya mtandao inatarajia kabla ya kuhitimisha kwa jina pekee.

Jaribio la kivinjari kwa mwenyeji huyo huyo linathibitisha tu kuwa proksi inakubali GET. Halisemi chochote kuhusu mbinu ya SSTP, URI ya ombi au maisha ya mwili, kwa hiyo usichukue ukurasa wa intraneti unaofanya kazi kama ushahidi kuwa njia ya handaki inatumika.

Chagua njia inayotumika

Uliza mmiliki wa mtandao swali moja mahususi: je, proksi inaruhusu POST ya dupleksi isiyohifadhiwa kwa lango hili kwenye bandari 443? Ndiyo hupelekea msamaha ndani ya proksi au upitishaji ulioandikwa kwa mwenyeji wa VPN. Hapana humaanisha kuwa njia iliyokaguliwa haiwezi kubeba SSTP, na suluhisho linalotumika ni njia au itifaki nyingine, si marekebisho ya mteja.

Chaguo kwa kawaida hujumuisha toka lisilokaguliwa kwa lango la VPN, muundo wa handaki lililogawanywa linalotuma trafiki ya kampuni pekee kupitia proksi, au itifaki mbadala ambayo kampuni inaunga mkono kwenye bandari nyingine. Kila moja ni sehemu ya muundo wa mtandao, na kila moja inapaswa kujaribiwa kwa kifaa na wasifu sawa ili ulinganisho utenganishe njia.

Andika matokeo: mtoaji, hatua iliyoshindikana, kanuni ya proksi na njia iliyochaguliwa. Mtu anayefuata atakayeona kusimama kulekule kwa asilimia 98 ataweza kuangalia ukweli mmoja badala ya kurudia safari yote.