HTTPS Basic Auth proti IPsec: kaj vsak od njiju ščiti

Odprite razvijalska orodja, naložite notranjo aplikacijo in opazujte, kako ena zahteva preide štiri kontrolne točke, preden se stran izriše. Najprej se ime razreši, nato se odpre povezava TCP, nato rokovanje TLS ugotovi, kdo je strežnik, in šele nato aplikacija vpraša, kdo ste. Obravnavajte jih kot ločene dogodke, ker vsak odpove z drugačnimi dokazi in vsak pripada drugi ekipi. Večina zmede v incidentih izhaja iz branja 401 kot težave tunela ali težave tunela kot napačnega gesla.

Kontrolna točka prva: je to strežnik, s katerim ste hoteli govoriti

Rokovanje TLS odgovori na to vprašanje, preden se pošlje kakršna koli poverilnica. Vaš odjemalec preveri verigo potrdil glede na shrambo zaupanja in preveri, ali se ime v potrdilu ujema z gostiteljem, ki ste ga vnesli. Če to spodleti, brskalnik pokaže napako potrdila in glave Authorization sploh ne pošlje. Poziv za geslo torej ni dokaz, da je strežnik pristen; je dokaz, da je aplikacija odgovorila.

Tu se pojavi prva meja. TLS ščiti povezavo do točke njene zaključitve. Če razbremenilnik zaključi TLS in v aplikacijo posreduje navaden HTTP, se šifrirani odsek konča pri razbremenilniku in poverilnice so zaščitene le na prvem skoku.

Kontrolna točka druga: kaj v izmenjavi 401 v resnici potuje

HTTP Basic pošlje identifikator uporabnika in geslo v glavi, kodirano z Base64, kot je opisano v RFC 7617. Authorization: Basic dXNlcjpwYXNz je oblika; kodiranje je povratno za vsakogar, ki lahko prebere zahtevo, zato vsa tajnost prihaja iz prevoza spodaj. curl -v prikaže izziv WWW-Authenticate: Basic in glavo, ki jo pošljete nazaj.

Ta glava pove aplikaciji, kdo sprašuje. Ne pove omrežju, kdo se sme povezati, in sama po sebi ničesar ne šifrira. Aplikacija mora še vedno preveriti poverilnico v shrambi in odločiti, kaj ta račun sme, kar je pooblastilo in se zgodi po overjanju.

Kje v tej poti sedi tunel IPsec

Zdaj pojdite od brskalnika navzven. Tunel IPsec med prehodi ščiti izbrani promet med dvema varnostnima prehodoma, ne med vašim prenosnikom in procesom aplikacije. ESP v tunelskem načinu ovije izvirni paket, prehoda ga šifrirata in overita, notranji naslovi pa preživijo, da lahko druga stran zahtevo usmeri v aplikacijo.

Izbor je del, na katerem se ljudje spotaknejo. Tuneli na osnovi pravilnikov uporabljajo izbirnike prometa, pogosto izražene kot sezname za nadzor dostopa, da odločijo, kateri paketi vstopijo v tunel. Tuneli na osnovi usmeritev namesto tega uporabljajo navidezni vmesnik in usmerjevalno tabelo. V Linuxu ip xfrm policy prikaže izbirnike, ip xfrm state pa vzpostavljene varnostne povezave; na napravi požarnega zidu je ustreznica tabela SA tunela plus sledilnik paketov.

Posledico velja povedati naravnost. Paket je lahko v popolnoma zdravem tunelu in vseeno nosi zahtevo HTTPS, ki jo aplikacija zavrne, veljavne poverilnice pa lahko prispejo po poti brez vsakršnega tunela, če usmerjanje to dopušča.

Napako berite na sloju, ki jo je prijavil

401 pomeni, da aplikacija ni sprejela poverilnice. 403 pomeni, da je sprejela identiteto in zavrnila operacijo. Napaka TLS pomeni, da odjemalec ni sprejel strežnika. Brez usmeritve ali neujemanje pravilnika pomeni, da paket nikoli ni dosegel oddaljenega prehoda. Štiri različne odpovedi, štirje različni lastniki, in nobene ni mogoče diagnosticirati s strmenjem v prijavni obrazec.

Uporabite dokaze, ki jih daje vsak sloj: omrežno ploščo brskalnika za stanje in glave, openssl s_client -connect host:443 za verigo potrdil, števce SA in dnevnike prehoda za tunelski promet ter dnevnik aplikacije za odločitev o računu. Ko dva sloja hkrati poročata o napakah, najprej popravite nižjega, ker mrtvi tunel zlahka zamaskira napako overjanja in obratno.

Zarišite eno storitev od začetka do konca

Napišite pet vrstic za storitev, ki jo diagnosticirate: katere partnerje tunel povezuje, katera podomrežja in vrata izbirniki dovoljujejo, kje se TLS zaključi in katero identiteto potrjuje potrdilo, kateri račun aplikacije in vloga se uporabljata in kje vsak sloj beleži. Imejte jih na eni strani, ker je smisel zemljevida pokazati, kje se odgovornost enega sloja konča in začne naslednji.

Nato preizkusite en negativni primer na sloj. Uporabite napačno geslo in potrdite, da dobite 401, ne časovne prekinitve. Povežite se iz podomrežja zunaj izbirnikov in potrdite, da paket ne gre skozi tunel. Predstavite potrdilo za napačno ime in potrdite, da odjemalec zavrne, preden pošlje poverilnice. Ti trije rezultati povedo o zasnovi več kot katera koli shema škatel.

Na koncu zavestno odločite, kakšno zaščito potrebuje vsak odnos. Basic overjanje prek TLS se razumno prilega majhnemu notranjemu orodju za prehodom; ne nadomešča pooblastila na uporabnika ali zaščite prometa onkraj končne točke TLS. Tunel ščiti pot, potrdilo ščiti skok in 401 ščiti račun, in le zadnji ve, kdo ste.