HTTPS Basic-autentisering mot IPsec: kva dei vernar kvar for seg

Opne utviklarverktøya, last den interne appen og følg med på korleis éin førespurnad passerer fire kontrollpunkt før sida blir teikna. Fyrst blir namnet slått opp, så blir det opna ei TCP-tilkopling, så fastset eit TLS-handtrykk kven tenaren er, og først då spør applikasjonen kven du er. Handsame desse som separate hendingar, for kvar av dei sviktar med ulike bevis og kvar av dei blir eigd av eit ulikt team. Den vanlegaste forvirringa i avvikssaker kjem av å lese ein 401 som eit tunnelproblem, eller eit tunnelproblem som eit dårleg passord.

Kontrollpunkt éin: er dette tenaren du meinte å snakke med

TLS-handtrykken svarar på det spørsmålet før noko passord blir sendt. Klienten din validerer sertifikatkjeda mot eit tillitslager og kontrollerer at namnet i sertifikatet samsvarar med verten du skreiv inn. Viss det sviktar, viser nettlesaren ein sertifikatfeil og sender aldri Authorization-hovudet i det heile. Ei passordførespurnad er derfor ikkje bevis på at tenaren er ekte; det er bevis på at applikasjonen svara.

Her dukkar den fyrste grensa opp. TLS vernar tilkoplinga fram til punktet der ho blir avslutta. Viss ein lastbalansar avsluttar TLS og videresender rein HTTP til applikasjonen, sluttar det krypterte segmentet ved lastbalansaren, og passorda er berre verna på den fyrste etappen.

Kontrollpunkt to: kva som faktisk blir sendt i ein 401-utveksling

HTTP Basic-autentisering sender brukaridentifikatoren og passordet i eit hovud, koda med Base64 slik det er skildra i RFC 7617. Authorization: Basic dXNlcjpwYXNz er forma; kodinga kan reverserast av alle som kan lese førespurnaden, så alt hemmeleghald kjem frå transporten under. curl -v viser både WWW-Authenticate: Basic-utfordringa og hovudet du sender tilbake.

Det hovudet fortel applikasjonen kven som spør. Det fortel ikkje nettverket kven som får kople seg til, og det krypterer ingenting i seg sjølv. Applikasjonen må framleis kontrollere passordet mot eit lager og avgjere kva den kontoen får gjere, og det er autorisasjon, som skjer etter autentiseringa.

Kvar IPsec-tunnelen ligg i den vegen

Gå no utover frå nettlesaren. Ein IPsec-tunnel mellom gatewayar vernar utvald trafikk mellom to sikkerheitsgatewayar, ikkje mellom den berbare maskinen din og applikasjonsprosessen. ESP i tunnelmodus pakkar den opphavlege pakken inn, gatewayane krypterer og autentiserer han, og dei indre adressene blir bevarte slik at den andre sida kan rute førespurnaden til applikasjonen.

Utvalet er den delen som lurar folk. Policybaserte tunneler brukar trafikkveljarar, ofte uttrykte som tilgangskontrollister, for å avgjere kva pakkar som går inn i tunnelen. Rutebaserte tunneler brukar eit virtuelt grensesnitt og rutetabellen i staden. På Linux viser ip xfrm policy veljarane og ip xfrm state dei etablerte sikkerheitssambanda; på ein brannmur er det tilsvarande tunnelens SA-tabell pluss ein pakkesporar.

Konsekvensen er verdt å seie rett ut. Ein pakke kan liggje inne i ein heilt frisk tunnel og likevel bere ein HTTPS-førespurnad som applikasjonen avviser, og gyldige passord kan kome over ein veg heilt utan tunnel viss rutinga tillèt det.

Les feilen i det laget som melde han

Ein 401 betyr at applikasjonen ikkje godtok passordet. Ein 403 betyr at han godtok identiteten og avviste handlinga. Ein TLS-feil betyr at klienten ikkje godtok tenaren. Manglande rute eller eit policyavvik betyr at pakken aldri nådde gatewayen på hi sida. Fire ulike feil, fire ulike eigarar, og ingen av dei blir diagnostiserte ved å stirre på innloggingsskjemaet.

Bruk bevisa kvart lag produserer: nettverkspanelet i nettlesaren for status og hovud, openssl s_client -connect host:443 for sertifikatkjeda, SA-teljarane og loggane til gatewayen for tunneltrafikk, og applikasjonsloggen for kontobeslutninga. Når to lag melder feil samtidig, rettar du det lågaste fyrst, for ein daud tunnel kan lett skjule ein autentiseringsfeil, og omvendt.

Kartlegg éin teneste frå ende til ende

Skriv fem linjer for tenesta du feilsøkjer: kva partar tunnelen knyter saman, kva subnett og portar veljarane tillèt, kvar TLS blir avslutta og kva identitet sertifikatet hevdar, kva applikasjonskonto og rolle som blir brukt, og kvar kvart lag loggar. Hald dei på éi side, for poenget med kartet er å vise kvar ansvaret til eitt lag sluttar og det neste tek over.

Test så eitt negativt tilfelle per lag. Bruk eit feil passord og stadfest at du får 401, ikkje tidsavbrot. Kople til frå eit subnett utanfor veljarane og stadfest at pakken ikkje blir tunnellert. Presenter eit sertifikat for feil namn og stadfest at klienten nektar før han sender passord. Dei tre resultata fortel deg meir om designet enn noko boksdiagram.

Til slutt bør du medvite avgjere kva vern kvar relasjon treng. Basic-autentisering over TLS passar rimeleg godt for eit lite internt verktøy bak ein gateway; det er ikkje ei erstatning for autorisasjon per brukar eller for å verne trafikk utover TLS-endepunktet. Tunnelen vernar vegen, sertifikatet vernar etappen, og 401 vernar kontoen, og berre den siste veit kven du er.