HTTPS Basic Auth kontra 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 slås navnet opp, så åpnes en TCP-forbindelse, så fastslår et TLS-håndtrykk hvem serveren er, og først da spør applikasjonen hvem du er. Behandle dem som separate hendelser, fordi hver av dem feiler med ulikt bevis og hver av dem eies av et ulikt team. Det meste av forvirringen i hendelser kommer av å 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 besvarer 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 aldri Authorization-headeren i det hele tatt. En passordforespørsel er derfor ikke bevis på at serveren er ekte; det er bevis på at applikasjonen svarte.

Her dukker den første grensen opp. TLS beskytter forbindelsen fram til termineringspunktet. Hvis en lastbalanserer terminerer TLS og videresender ren HTTP til applikasjonen, slutter det krypterte segmentet ved balansereren, og legitimasjonen beskyttes bare på det første hoppet.

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

HTTP Basic-autentisering sender brukeridentifikatoren og passordet i en header, kodet med Base64 som beskrevet i RFC 7617. Authorization: Basic dXNlcjpwYXNz er formen; kodingen er reversibel for alle som kan lese forespørselen, så all hemmelighold 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 får koble til, og den krypterer ikke noe i seg selv. Applikasjonen må fortsatt kontrollere legitimasjonen mot et lager og avgjøre hva den kontoen får gjøre, og det er autorisasjon som skjer etter autentisering.

Hvor IPsec-tunnelen sitter i den veien

Gå nå utover fra nettleseren. En IPsec-tunnel mellom gatewayer beskytter utvalgt trafikk mellom to sikkerhetsgatewayer, ikke mellom din laptop og applikasjonsprosessen. ESP i tunnelmodus pakker den opprinnelige pakken, gatewayene krypterer og autentiserer den, og de indre adressene overlever slik at den andre siden kan rute forespørselen til applikasjonen.

Utvalget er delen som feller folk. Policybaserte tunneler bruker trafikkvelgere, ofte uttrykt som lister for tilgangskontroll, for å avgjøre hvilke pakker som går inn i tunnelen. Rutebaserte tunneler bruker et virtuelt grensesnitt og rutetabellen i stedet. På Linux viser ip xfrm policy velgerne og ip xfrm state de etablerte sikkerhetstilknytningene; på en brannmur-enhet er motstykket tunnelens SA-tabell pluss en pakkesporer.

Konsekvensen er verdt å si rett ut. En pakke kan sitte i en helt frisk tunnel og likevel bære en HTTPS-forespørsel som applikasjonen avviser, og gyldig legitimasjon kan komme over en vei uten tunnel i det hele tatt hvis rutingen tillater det.

Les feilen på laget som meldte den

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

Bruk beviset 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 applikasjonsloggen for kontobeslutningen. Når to lag melder feil samtidig, fiks det laveste først, fordi en død tunnel lett kan maskere en autentiseringsfeil og omvendt.

Kartlegg én tjeneste fra ende til ende

Skriv fem linjer for tjenesten du feilsøker: hvilke parter tunnelen forbinder, hvilke subnett og porter velgerne tillater, hvor TLS terminerer 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 i tunnelen. Presenter et sertifikat for feil navn og bekreft at klienten nekter før den sender legitimasjon. De tre resultatene sier mer om designet enn noe diagram med bokser.

Til slutt, avgjør bevisst hvilken beskyttelse hver relasjon trenger. Basic-autentisering over TLS passer rimelig for et lite internt verktøy bak en gateway; det er ikke en erstatning for autorisasjon per bruker eller for å beskytte trafikk utover TLS-endepunktet. Tunnelen beskytter veien, sertifikatet beskytter hoppet, og 401-en beskytter kontoen, og bare den siste vet hvem du er.