HTTPS Basic Auth kundrejt IPsec: çfarë mbron secili

Hapni mjetet e zhvilluesit, ngarkoni aplikacionin e brendshëm dhe vëzhgoni një kërkesë që kalon nëpër katër pika kontrolli përpara se faqja të vizatohet. Fillimisht zgjidhet emri, pastaj hapet një lidhje TCP, pastaj një shtrëngim duarsh TLS përcakton kush është serveri, dhe vetëm atëherë aplikacioni pyet kush jeni. Trajtoni ato si ngjarje të veçanta, sepse secila dështon me prova të ndryshme dhe secila i përket një ekipi të ndryshëm. Pjesa më e madhe e konfuzionit në incidente vjen nga leximi i një 401 si problem tuneli, ose i një problemi tuneli si fjalëkalim i gabuar.

Pika kontrolli e parë: a është ky serveri me të cilin donit të flisnit

Shtrëngimi i duarsh TLS i përgjigjet atij pyetjeje përpara se të dërgohet ndonjë kredencial. Klienti juaj vërteton zinxhirin e certifikatave kundrejt një depoje besimi dhe kontrollon që emri në certifikatë përputhet me hostin që shtypët. Nëse kjo dështon, shfletuesi shfaq një gabim certifikate dhe nuk e dërgon fare kokën Authorization. Një kërkesë për fjalëkalim, pra, nuk është provë që serveri është i vërtetë; është provë që aplikacioni u përgjigj.

Këtu shfaqet kufiri i parë. TLS mbron lidhjen deri në pikën e përfundimit të saj. Nëse një balancues ngarkese e përfundon TLS dhe përcjell HTTP të thjeshtë te aplikacioni, segmenti i kriptuar përfundon te balancuesi, dhe kredencialet mbrohen vetëm në atë hapin e parë.

Pika kontrolli e dytë: çfarë udhëton vërtetë në një shkëmbim 401

HTTP Basic dërgon identifikuesin e përdoruesit dhe fjalëkalimin në një kokë, të koduara me Base64 siç përshkruhet në RFC 7617. Authorization: Basic dXNlcjpwYXNz është forma; kodimi është i kthyeshëm për këdo që mund të lexojë kërkesën, prandaj e gjithë fshehtësia vjen nga transporti poshtë. curl -v shfaq si sfidën WWW-Authenticate: Basic ashtu edhe kokën që ktheni.

Ajo kokë i thotë aplikacionit kush po pyet. Nuk i thotë rrjetit kush mund të lidhet, dhe nuk kripton asgjë në vetvete. Aplikacioni ende duhet të kontrollojë kredencialin në një depo dhe të vendosë çfarë mund të bëjë ai llogari, gjë që është autorizim dhe ndodh pas vërtetimit.

Ku qëndron tuneli IPsec në atë rrugë

Tani ecni nga shfletuesi nga jashtë. Një tunel IPsec mes portave mbron trafikun e zgjedhur mes dy portave sigurie, jo mes laptopit tuaj dhe procesit të aplikacionit. ESP në modalitetin tunel e mbështjell paketën origjinale, portat e kriptojnë dhe e vërtetojnë, dhe adresat e brendshme mbijetojnë në mënyrë që ana tjetër të mund ta drejtojë kërkesën te aplikacioni.

Përzgjedhja është pjesa ku njerëzit pengohen. Tunelet e bazuara në politikë përdorin përzgjedhës trafiku, shpesh të shprehur si lista të kontrollit të aksesit, për të vendosur cilat paketa hyjnë në tunel. Tunelet e bazuara në rrugë përdorin në vend të tyre një ndërfaqe virtuale dhe tabelën e rrugëtimit. Në Linux ip xfrm policy shfaq përzgjedhësit dhe ip xfrm state shoqatat e sigurisë të vendosura; në një pajisje firewall ekuivalenti është tabela SA e tunelit plus një gjurmues paketash.

Pasoja ia vlen të thuhet pa dredha. Një paketë mund të rrijë brenda një tuneli krejt të shëndoshë dhe gjithsesi të mbajë një kërkesë HTTPS që aplikacioni e refuzon, dhe kredenciale të vlefshme mund të mbërrijnë në një rrugë pa asnjë tunel nëse rrugëtimi e lejon.

Lexoni dështimin në shtresën që e raportoi

Një 401 do të thotë që aplikacioni nuk e pranoi kredencialin. Një 403 do të thotë që e pranoi identitetin dhe e refuzoi veprimin. Një gabim TLS do të thotë që klienti nuk e pranoi serverin. Pa rrugë ose një mospërputhje politike do të thotë që paketa nuk arriti kurrë te porta e largët. Katër dështime të ndryshme, katër pronarë të ndryshëm, dhe asnjëri prej tyre nuk diagnostikohet duke ia ngulur sytë formularit të hyrjes.

Përdorni provat që prodhon secila shtresë: paneli i rrjetit të shfletuesit për statusin dhe kokën, openssl s_client -connect host:443 për zinxhirin e certifikatave, numëruesit SA dhe regjistrat e portës për trafikun e tunelit, dhe regjistri i aplikacionit për vendimin mbi llogarinë. Kur dy shtresa raportojnë gabime njëkohësisht, rregulloni më të ulëtën i pari, sepse një tunel i vdekur mund të maskojë lehtë një dështim vërtetimi dhe anasjelltas.

Hartoni një shërbim nga fillimi në fund

Shkruani pesë rreshta për shërbimin që po diagnostikoni: cilat palë lidh tuneli, cilat nënrrjeta dhe porta lejojnë përzgjedhësit, ku përfundon TLS dhe cilin identitet pohon certifikata, cila llogari aplikacioni dhe rol përdoren, dhe ku regjistron secila shtresë. Mbajini në një faqe, sepse qëllimi i hartës është të tregojë ku mbaron përgjegjësia e një shtrese dhe ku fillon tjetra.

Pastaj provoni një rast negativ për shtresë. Përdorni një fjalëkalim të gabuar dhe konfirmoni që merrni një 401, jo një skadim kohe. Lidhuni nga një nënrrjet jashtë përzgjedhësve dhe konfirmoni që paketa nuk tunelohet. Paraqisni një certifikatë për emrin e gabuar dhe konfirmoni që klienti refuzon përpara se të dërgojë kredenciale. Këto tre rezultate ju thonë më shumë për projektimin sesa çdo diagram kutive.

Së fundi, vendosni me vetëdije çfarë mbrojtje i nevojitet secilës marrëdhënie. Basic authentication mbi TLS përshtatet në mënyrë të arsyeshme për një mjet të vogël të brendshëm pas një porte; nuk zëvendëson autorizimin për përdorues ose mbrojtjen e trafikut përtej pikës fundore TLS. Tuneli mbron rrugën, certifikata mbron hapin, dhe 401 mbron llogarinë, dhe vetëm i fundit e di kush jeni.