OAuth ndani ya VPN: sehemu zipi bado zinahitaji TLS

Uelekezaji wa faragha huamua nani anafikia seva; kanuni za usafirishaji za OAuth huamua jinsi kila ujumbe unasafiri. Kivinjari, seva ya idhini, kituo cha mwisho cha tokeni na seva ya rasilimali zote zinaweza kuwa nyuma ya VPN moja na bado kubadilishana jumbe kupitia sehemu tofauti. Kila sehemu ina hitaji lake la usafirishaji, na VPN hailegezi hata moja. Mpaka wa VPN na mpaka wa itifaki ni mistari miwili tofauti.

Uamuzi ni rahisi ikiwa utaacha kuuliza kama mtandao unaaminika na uanze kuuliza ubadilishanaji upi unavuka mpaka upi.

Amua kwa sehemu, si kwa mtandao

Andika vituo vya mwisho kando: kituo cha mwisho cha idhini, kituo cha mwisho cha tokeni, URI ya uelekezaji upya, URL ya seva ya rasilimali, kituo cha mwisho cha TLS na lango la VPN. Kisha onyesha upande upi unaanzisha kila ombi na jibu linaenda wapi.

VPN inayoishia kwenye lango husimba sehemu hadi lango hilo. Ombi linaweza kuendelea kama HTTP ya kawaida nyuma yake, na sehemu hiyo iliyobaki haijawa HTTPS kwa sababu sehemu ya awali ilisimbwa. Mwendelezo huo ndio sehemu ambayo itifaki inajali. Kusimba hatua ya kwanza hakufanyi hatua ya pili kuwa salama.

Usafirishaji pia hubeba ukaguzi wa utambulisho wa huduma. Kivinjari huthibitisha cheti cha URL ya programu; VPN haifanyi uthibitisho huo kwa niaba ya kivinjari, na haifanyi kituo cha mwisho kisichothibitishwa kuwa kinachokubalika. Cheti hutaja kituo cha mwisho ambacho mteja anadhani anakiita. Handaki kuelekea lango hailipi jina la kituo hicho cha mwisho na haithibitishi.

Jibu la idhini na URI ya uelekezaji upya

Mazoea bora ya sasa ya usalama ya OAuth yanakataza kupeleka majibu ya idhini kupitia miunganisho isiyosimbwa. Hilo linajumuisha uelekezaji upya unaobeba msimbo wa idhini au tokeni kurudi kwa mteja, si ombi la awali pekee.

Mwongozo huo huo hauruhusu URI za uelekezaji upya za HTTP, isipokuwa kisa maalum cha loopback kwa wateja asilia. Jina la mwenyeji wa ndani haliundi msamaha mpya, na jina la DNS linalotatuliwa tu ndani ya VPN bado ni URL ya HTTP ikiwa mpango unasema hivyo. Angalia mpango katika URI iliyosajiliwa, si jina la mwenyeji pekee.

Sajili URI kamili ya uelekezaji upya wa HTTPS kwenye seva ya idhini na uweke uthibitisho wa vyeti ukiwa umewashwa kwa mteja. Njia ya mkato ya maendeleo inayokandamiza hitaji la HTTPS huzalisha mtiririko unaofanya tofauti na usanidi wa uzalishaji ambao inapaswa kuiga.

Kituo cha mwisho cha tokeni na maombi ya tokeni ya mbebaji

Ombi la tokeni hubeba vitambulisho au msimbo unaoweza kubadilishwa kwa ufikiaji. Kulituma kupitia sehemu isiyolindwa kunaweka wazi nyenzo ambazo seva ya rasilimali itaamini baadaye, hata kama mtandao unaozunguka ni wa faragha. Proksi inayoweza kusoma ombi inaweza pia kusoma kitambulisho anachobeba.

Kwa maombi ya rasilimali yenye tokeni ya mbebaji, RFC 6750 inachukulia TLS kuwa lazima kutekelezwa na kutumiwa kwa vipimo hivyo. Kuita subneti ya ofisi inayoweza kuaminiwa si msamaha wa jumla wa itifaki unaohitajika na usambazaji wa mbebaji katika maandishi wazi.

Tumia URL salama zilizoandikwa za vituo vya mwisho kwa sehemu zote mbili. Ikiwa maktaba inakataa kuita kituo cha mwisho cha tokeni cha HTTP, kukataa huko ndiko vipimo vinavyofanya kazi, si hitilafu ya usanidi ya kuepukwa. Andika URL hiyo katika usanidi wa mteja badala ya kuitoa wakati wa utekelezaji.

TLS inaishia wapi na hilo huacha nini

Ikiwa TLS inaishia kwenye sehemu ya mbele iliyoidhinishwa, taja sehemu hiyo ya mbele na pitia njia kutoka hapo hadi programu. Sehemu ya mbele inakuwa na jukumu la upelekaji, uaminifu na usiri kwenye sehemu iliyobaki, na usanifu unaoungwa mkono wa huduma unapaswa kueleza mpangilio huo.

VPN mahali pengine kwenye njia haiwezi kutatua majukumu hayo. Pia haikuambii ikiwa URL ya programu anayoiona kivinjari inalingana na cheti anachowasilisha sehemu ya mbele.

Kwa usambazaji wa ndani, andika kituo cha mwisho na utambulisho unaowasilisha. Sehemu ya mbele inayomaliza TLS na cheti cha jina lingine huunda onyo la kivinjari ambalo waendeshaji mara nyingi hulikandamiza badala ya kulirekebisha.

Msamaha wa loopback asilia ni mwembamba

Msamaha wa uelekezaji upya wa loopback unahusu mwito wa kurudi kwenye kifaa cha mtumiaji mwenyewe, ambapo mteja na kivinjari hushiriki kifaa hicho. Mpangilio huo ni wa mwito wa kurudi kwenye kifaa kimoja, na hauruhusu kuhudumia seva ya idhini ya kawaida au API inayobeba tokeni kupitia HTTP kwa subneti ya ofisi.

Weka msamaha ukiwa umezungukwa na aina ya mteja na mwito wa kurudi unaoeleza. Kuutekeleza kwa programu ya wavuti, huduma ya ndani inayoshirikiwa au URI ya uelekezaji upya kwenye mwenyeji mwingine hubadilisha usambazaji, si msamaha.

Jaribu mtiririko halisi kwenye kila mpaka na uulinganishe na aina ya mteja. Uelekezaji upya unaofanya kazi hausemi chochote kuhusu ikiwa kila sehemu iliyobeba tokeni ilitumia ulinzi unaohitajika, na aikoni ya kijani ya VPN haisemi chochote kuhusu mpango wa ombi linalofuata.