Grundlæggende godkendelse over HTTPS kontra IPsec: hvad beskytter hver af dem

Åbn udviklerværktøjerne, indlæs den interne app, og se én anmodning passere fire kontrolpunkter, før siden vises. Først opløses navnet, derefter åbnes en TCP-forbindelse, derefter fastslår et TLS-håndtryk, hvem serveren er, og først derefter spørger applikationen, hvem du er. Behandl dem som adskilte hændelser, fordi hver af dem fejler med forskellige beviser, og hver af dem ejes af et forskelligt team. Det meste forvirring i hændelser kommer fra at læse en 401 som et tunnelproblem, eller et tunnelproblem som en dårlig adgangskode.

Kontrolpunkt et: er dette den server, du mente at tale med

TLS-håndtrykket besvarer det spørgsmål, før nogen legitimationsoplysning sendes. Din klient validerer certifikatkæden mod et tillidslager og kontrollerer, at navnet i certifikatet matcher den vært, du skrev. Hvis det fejler, viser browseren en certifikatfejl og sender slet ikke Authorization-headeren. En adgangskodeanmodning er derfor ikke bevis for, at serveren er ægte; det er bevis for, at applikationen svarede.

Her opstår den første grænse. TLS beskytter forbindelsen frem til dens afslutningspunkt. Hvis en loadbalancer afslutter TLS og videresender almindelig HTTP til applikationen, slutter det krypterede segment ved loadbalanceren, og legitimationsoplysningerne er kun beskyttet på det første hop.

Kontrolpunkt to: hvad der faktisk rejser i en 401-udveksling

HTTP Basic-godkendelse sender brugeridentifikatoren og adgangskoden i en header, kodet med Base64 som beskrevet i RFC 7617. Authorization: Basic dXNlcjpwYXNz er formen; kodningen kan vendes af enhver, der kan læse anmodningen, så al hemmeligheden kommer fra transporten nedenunder. curl -v viser både WWW-Authenticate: Basic-udfordringen og den header, du sender tilbage.

Den header fortæller applikationen, hvem der spørger. Den fortæller ikke netværket, hvem der må forbinde, og den krypterer ikke noget i sig selv. Applikationen skal stadig kontrollere legitimationsoplysningen mod et lager og beslutte, hvad den konto må gøre, hvilket er autorisation og sker efter godkendelse.

Hvor IPsec-tunnelen ligger i den vej

Gå nu udad fra browseren. En IPsec-tunnel mellem gateways beskytter udvalgt trafik mellem to sikkerhedsgateways, ikke mellem din bærbare computer og applikationsprocessen. ESP i tunnelmode indpakker den oprindelige pakke, gateways krypterer og godkender den, og de indre adresser overlever, så den fjerne side kan rute anmodningen til applikationen.

Udvalget er den del, der får folk til at snuble. Politikbaserede tunneler bruger trafikvælgere, ofte udtrykt som adgangskontrollister, til at afgøre, hvilke pakker der kommer ind i tunnelen. Rutebaserede tunneler bruger i stedet en virtuel grænseflade og routingtabellen. På Linux viser ip xfrm policy vælgerne, og ip xfrm state viser de etablerede sikkerhedsassociationer; på en firewall-enhed er ækvivalenten tunnelens SA-tabel plus en pakkesporer.

Konsekvensen er værd at sige rent ud. En pakke kan sidde inde i en fuldstændig sund tunnel og stadig bære en HTTPS-anmodning, som applikationen afviser, og gyldige legitimationsoplysninger kan ankomme ad en vej uden tunnel overhovedet, hvis routing tillader det.

Læs fejlen på det lag, der rapporterede den

En 401 betyder, at applikationen ikke accepterede legitimationsoplysningen. En 403 betyder, at den accepterede identiteten og afviste handlingen. En TLS-fejl betyder, at klienten ikke accepterede serveren. Ingen rute eller en politikujævnhed betyder, at pakken aldrig nåede den fjerne gateway. Fire forskellige fejl, fire forskellige ejere, og ingen af dem diagnosticeres ved at stirre på loginformularen.

Brug de beviser, hvert lag producerer: browserens netværkspanel til status og headere, openssl s_client -connect host:443 til certifikatkæden, gatewayens SA-tællere og logfiler til tunneltrafik, og applikationens log til kontobeslutningen. Når to lag rapporterer fejl samtidig, så ret det nederste først, fordi en død tunnel let kan skjule en godkendelsesfejl og omvendt.

Kortlæg én tjeneste fra ende til anden

Skriv fem linjer for den tjeneste, du fejlretter: hvilke par tunnel en forbinder, hvilke undernet og porte vælgerne tillader, hvor TLS afsluttes, og hvilken identitet certifikatet hævder, hvilken applikationskonto og rolle der bruges, og hvor hvert lag logger. Hold dem på én side, fordi pointen med kortet er at vise, hvor ét lags ansvar slutter, og det næste begynder.

Test derefter ét negativt tilfælde pr. lag. Brug en forkert adgangskode, og bekræft, at du får en 401, ikke en timeout. Forbind fra et undernet uden for vælgerne, og bekræft, at pakken ikke sendes gennem tunnelen. Fremvis et certifikat til det forkerte navn, og bekræft, at klienten afviser, før den sender legitimationsoplysninger. De tre resultater fortæller dig mere om designet end noget diagram med kasser.

Beslut endelig bevidst, hvilken beskyttelse hver relation har brug for. Grundlæggende godkendelse over TLS er en rimelig løsning til et lille internt værktøj bag en gateway; det er ikke en erstatning for autorisation pr. bruger eller for at beskytte trafik ud over TLS-endepunktet. Tunnelen beskytter vejen, certifikatet beskytter hoppet, og 401 beskytter kontoen, og kun det sidste ved, hvem du er.