Oinarrizko autentifikazioa HTTPS bidez IPsec-en aurrez aurre: bakoitzak zer babesten duen

Ireki garatzaile-tresnak, kargatu barneko aplikazioa eta ikusi eskaera bat lau kontrol-puntutatik nola igarotzen den orria marraztu aurretik. Lehenik izena ebazten da, gero TCP konexioa irekitzen da, gero TLS esku-emateak zehazten du nor den zerbitzaria, eta horren ondoren bakarrik galdetzen du aplikazioak nor zaren. Hartu hauek gertaera bereizi gisa, bakoitzak froga desberdinekin huts egiten duelako eta bakoitzak talde desberdin baten jabetzakoa delako. Istripuetan nahasmen gehiena 401 tunel-arazo gisa irakurtetik dator, edo tunel-arazoa pasahitz txar gisa irakurtetik.

Lehen kontrol-puntua: hau al da hitz egin nahi zenuen zerbitzaria

TLS esku-emateak galdera horri erantzuten dio kredentzialik bidali aurretik. Zure bezeroak ziurtagiri-katea fidagarritasun-biltegi baten aurka baliozkotzen du eta ziurtagiriko izena idatzi duzun ostalariarekin bat datorrela egiaztatzen du. Hori huts egiten badu, nabigatzaileak ziurtagiri-errore bat erakusten du eta ez du Authorization goiburua bat ere bidaltzen. Beraz, pasahitz-eskaera ez da zerbitzaria benetakoa denaren froga; aplikazioak erantzun duenaren froga da.

Hemen agertzen da lehen muga. TLS-k konexioa bere amaiera-punturaino babesten du. Karga-banatzaile batek TLS amaitzen badu eta HTTP soila aplikaziora bidaltzen badu, segmentu zifratua banatzailean amaitzen da, eta kredentzialak lehen jauzi horretan soilik babestuta daude.

Bigarren kontrol-puntua: zer bidaiatzen duen benetan 401 truke batean

HTTP autentifikazio basic-ak erabiltzaile-identifikatzailea eta pasahitza goiburu batean bidaltzen ditu, Base64-rekin kodetuta, RFC 7617 dokumentuan deskribatzen den moduan. Authorization: Basic dXNlcjpwYXNz da forma; eskaera irakur dezakeen edonork alderantzizka dezake kodetzea, beraz isilpekotasun osoa azpiko garraiotik dator. curl -v-ek WWW-Authenticate: Basic erronka eta bidaltzen duzun goiburua erakusten ditu.

Goiburu horrek aplikazioari esaten dio nork galdetzen duen. Ez dio sareari esaten nork konekta daitekeen, eta ez du ezer zifratzen berez. Aplikazioak oraindik kredentziala biltegi baten aurka egiaztatu behar du eta kontu horrek zer egin dezakeen erabaki, eta hori baimen-ematea da eta autentifikazioaren ondoren gertatzen da.

Non dagoen IPsec tunela bide horretan

Orain joan nabigatzailetik kanpora. Atezain arteko IPsec tunel batek bi segurtasun-atezainen arteko trafiko hautatua babesten du, ez zure eramangarriaren eta aplikazio-prozesuaren artean. Tunel moduko ESP-k jatorrizko paketea biltzen du, atezainek zifratu eta autentifikatzen dute, eta barneko helbideek bizirauten dute urruneko aldeak eskaera aplikaziora bideratu ahal izan dezan.

Hautaketa da jendea behaztoparazten duen zatia. Politikan oinarritutako tunelak trafiko-hautatzaileak erabiltzen ditu, sarritan sarbide-kontrol zerrenda gisa adierazita, zein pakete sartzen diren tunelera erabakitzeko. Ibilbideetan oinarritutako tunelak, aldiz, interfaze birtuala eta bideratze-taula erabiltzen dituzte. Linux-en ip xfrm policy-ek hautatzaileak erakusten ditu eta ip xfrm state-ek ezarritako segurtasun-elkarteak; suebaki-gailu batean baliokidea tunelaren SA taula gehi pakete-arrasto bat da.

Ondorioa garbi esateak merezi du. Pakete bat tunel osasuntsu baten barruan egon daiteke eta hala ere aplikazioak ukatzen duen HTTPS eskaera bat eraman, eta kredentzial baliodunak inolako tunelik gabeko bide batetik irits daitezke bideratzeak uzten badu.

Irakurri hutsegitea jakinarazi zuen geruzan

401 batek esan nahi du aplikazioak ez duela kredentziala onartu. 403 batek esan nahi du identitatea onartu eta eragiketa ukatu duela. TLS errore batek esan nahi du bezeroak ez duela zerbitzaria onartu. Ibilbiderik eza edo politika-desegokitzapenak esan nahi du paketea ez zela inoiz urruneko atezainera iritsi. Lau hutsegite desberdin, lau jabe desberdin, eta horietako bat ere ez da diagnostikatzen saio-hasierako inprimakia begira.

Erabili geruza bakoitzak sortzen dituen frogak: nabigatzailearen sare-panela egoeretarako eta goiburuetarako, openssl s_client -connect host:443 ziurtagiri-katerako, atezainaren SA kontagailuak eta erregistroak tunel-trafikorako, eta aplikazioaren erregistroa kontuaren erabakirako. Bi geruzek aldi berean erroreak jakinarazten dituztenean, konpondu lehenengo behekoa, tunel hil batek autentifikazio-hutsegitea erraz maskara baitezake eta alderantziz.

Mapatu zerbitzu bat hasieratik amaierara

Idatzi bost lerro konpontzen ari zaren zerbitzuarentzat: zein pare konektatzen dituen tunelak, zein azpisare eta portu uzten dituzten hautatzaileek, non amaitzen den TLS eta zein identitate baieztatzen duen ziurtagiriak, zein aplikazio-kontu eta rol erabiltzen diren, eta non erregistratzen duen geruza bakoitzak. Eduki itzazu orri bakarrean, maparen helburua geruza baten erantzukizuna non amaitzen den eta hurrengoa non hasten den erakustea baita.

Ondoren probatu kasu negatibo bat geruza bakoitzeko. Erabili pasahitz okerra eta egiaztatu 401 bat jasotzen duzula, ez denbora-muga bat. Konektatu hautatzaileetatik kanpoko azpisare batetik eta egiaztatu paketea ez dela tunelatik pasatzen. Aurkeztu ziurtagiri bat izen okerrarentzat eta egiaztatu bezeroak uko egiten duela kredentzialak bidali aurretik. Hiru emaitza horiek diseinuari buruz gehiago esaten dizute kaxen diagrama edozein baino.

Azkenik, erabaki kontzienteki harreman bakoitzak zein babes behar duen. TLS gaineko autentifikazio basic-a aukera arrazoizkoa da atezain baten atzeko barne-tresna txiki batentzat; ez du erabiltzaile bakoitzeko baimen-ematea ezta TLS amaiera-puntutik haragoko trafikoaren babesa ordezkatzen. Tunelak bidea babesten du, ziurtagiriak jauzia babesten du, eta 401-ek kontua babesten du, eta azkenak bakarrik daki nor zaren.