Grunnleggende autentisering over HTTPS mot IPsec: hva hver av dem beskytter

Åpne utviklerverktøyene, last den interne appen og se én forespørsel passere fire kontrollpunkter før siden vises. Først løses navnet opp, deretter åpnes en TCP-tilkobling, deretter fastslår et TLS-håndtrykk hvem serveren er, og først etter det spør applikasjonen hvem du er. Behandle disse som separate hendelser, fordi hver av dem feiler med ulike bevis og hver av dem eies av et ulikt team. Mest forvirring i hendelser kommer fra å lese en 401 som et tunnelproblem, eller et tunnelproblem som et dårlig passord.

Kontrollpunkt én: er dette serveren du mente å snakke med

TLS-håndtrykket svarer på det spørsmålet før noen legitimasjon sendes. Klienten din validerer sertifikatkjeden mot et tillitslager og kontrollerer at navnet i sertifikatet samsvarer med verten du skrev. Hvis det feiler, viser nettleseren en sertifikatfeil og sender ikke Authorization-headeren i det hele tatt. En passordforespørsel er derfor ikke bevis for at serveren er ekte; det er bevis for at applikasjonen svarte.

Her dukker den første grensen opp. TLS beskytter tilkoblingen frem til endepunktet sitt. Hvis en lastbalanserer avslutter TLS og videresender vanlig HTTP til applikasjonen, slutter det krypterte segmentet ved lastbalansereren, og legitimasjonen er bare beskyttet på det første hoppet.

Kontrollpunkt to: hva som faktisk reiser i en 401-utveksling

HTTP grunnleggende autentisering sender brukeridentifikatoren og passordet i en header, kodet med Base64 som beskrevet i RFC 7617. Authorization: Basic dXNlcjpwYXNz er formen; kodingen kan reverseres av alle som kan lese forespørselen, så all hemmeligholdelsen kommer fra transporten under. curl -v viser både WWW-Authenticate: Basic-utfordringen og headeren du sender tilbake.

Den headeren forteller applikasjonen hvem som spør. Den forteller ikke nettverket hvem som kan koble til, og den krypterer ikke noe i seg selv. Applikasjonen må fortsatt kontrollere legitimasjonen mot et lager og bestemme hva den kontoen kan gjøre, noe som er autorisasjon og skjer etter autentisering.

Hvor IPsec-tunnelen ligger i den banen

Gå nå utover fra nettleseren. En IPsec-tunnel mellom gateways beskytter utvalgt trafikk mellom to sikkerhetsgateways, ikke mellom den bærbare datamaskinen din og applikasjonsprosessen. ESP i tunnelmodus pakker inn den opprinnelige pakken, gatewayene krypterer og autentiserer den, og de indre adressene overlever slik at den fjerne siden kan rute forespørselen til applikasjonen.

Utvalget er den delen folk snubler i. Policybaserte tunneler bruker trafikkvelgere, ofte uttrykt som tilgangskontrollister, for å avgjøre hvilke pakker som kommer inn i tunnelen. Rutebaserte tunneler bruker i stedet et virtuelt grensesnitt og rutetabellen. På Linux viser ip xfrm policy velgerne og ip xfrm state de etablerte sikkerhetstilknytningene; på en brannmurenhet er ekvivalenten tunnelens SA-tabell pluss en pakkesporer.

Konsekvensen er verdt å si rett ut. En pakke kan sitte inne i en helt sunn tunnel og likevel bære en HTTPS-forespørsel som applikasjonen avviser, og gyldig legitimasjon kan ankomme via en bane uten noen tunnel i det hele tatt hvis rutingen tillater det.

Les feilen på laget som rapporterte den

En 401 betyr at applikasjonen ikke godtok legitimasjonen. En 403 betyr at den godtok identiteten og avviste operasjonen. En TLS-feil betyr at klienten ikke godtok serveren. Ingen rute eller en policy-avvik betyr at pakken aldri nådde den fjerne gatewayen. Fire ulike feil, fire ulike eiere, og ingen av dem diagnostiseres ved å stirre på påloggingsskjemaet.

Bruk bevisene hvert lag produserer: nettleserens nettverkspanel for status og headere, openssl s_client -connect host:443 for sertifikatkjeden, gatewayens SA-tellere og logger for tunneltrafikk, og applikasjonens logg for kontobeslutningen. Når to lag rapporterer feil samtidig, reparer det laveste først, fordi en død tunnel lett kan skjule en autentiseringsfeil og omvendt.

Kartlegg én tjeneste fra ende til annen

Skriv fem linjer for tjenesten du feilsøker: hvilke par tunnelen forbinder, hvilke subnett og porter velgerne tillater, hvor TLS avsluttes og hvilken identitet sertifikatet hevder, hvilken applikasjonskonto og rolle som brukes, og hvor hvert lag logger. Hold dem på én side, fordi poenget med kartet er å vise hvor ansvaret til ett lag slutter og det neste begynner.

Test deretter ett negativt tilfelle per lag. Bruk et feil passord og bekreft at du får en 401, ikke en tidsavbrudd. Koble til fra et subnett utenfor velgerne og bekreft at pakken ikke går gjennom tunnelen. Vis et sertifikat for feil navn og bekreft at klienten avviser før den sender legitimasjon. De tre resultatene forteller deg mer om designet enn noe diagram med bokser.

Til slutt, bestem bevisst hvilken beskyttelse hver relasjon trenger. Grunnleggende autentisering over TLS er et rimelig valg for et lite internt verktøy bak en gateway; det erstatter ikke autorisasjon per bruker eller beskyttelse av trafikk utover TLS-endepunktet. Tunnelen beskytter banen, sertifikatet beskytter hoppet, og 401 beskytter kontoen, og bare det siste vet hvem du er.