HTTPS Basic-autentisering mot IPsec: vad var och en skyddar

Öppna utvecklarverktygen, ladda den interna appen och följ hur en begäran passerar fyra kontrollpunkter innan sidan renderas. Först slås namnet upp, sedan öppnas en TCP-anslutning, därefter fastställer en TLS-handskakning vem servern är, och först då frågar applikationen vem du är. Behandla dem som separata händelser, eftersom var och en misslyckas med olika bevis och var och en ägs av olika team. Den mesta förvirringen i incidenter kommer av att läsa en 401 som ett tunnelproblem, eller ett tunnelproblem som ett dåligt lösenord.

Kontrollpunkt ett: är detta servern du tänkte prata med

TLS-handskakningen svarar på den frågan innan någon inloggningsuppgift skickas. Din klient validerar certifikatkedjan mot ett betrott lager och kontrollerar att namnet i certifikatet matchar värden du skrev. Om det misslyckas visar webbläsaren ett certifikatfel och skickar aldrig Authorization-huvudet. En lösenordsfråga är därför inte bevis på att servern är äkta; det är bevis på att applikationen svarade.

Här dyker den första gränsen upp. TLS skyddar anslutningen fram till sin avslutningspunkt. Om en lastbalanserare avslutar TLS och vidarebefordrar ren HTTP till applikationen, slutar det krypterade segmentet vid lastbalanseraren, och uppgifterna skyddas bara på det första steget.

Kontrollpunkt två: vad som faktiskt färdas i ett 401-utbyte

HTTP Basic-autentisering skickar användaridentifieraren och lösenordet i ett huvud, kodade med Base64 enligt RFC 7617. Authorization: Basic dXNlcjpwYXNz är formen; kodningen kan vändas av alla som kan läsa begäran, så all hemlighet kommer från transporten under. curl -v visar både WWW-Authenticate: Basic-utmaningen och huvudet du skickar tillbaka.

Det huvudet talar om för applikationen vem som frågar. Det talar inte om för nätverket vem som får ansluta, och det krypterar ingenting i sig självt. Applikationen måste fortfarande kontrollera uppgiften mot ett lager och avgöra vad kontot får göra, vilket är auktorisering och sker efter autentiseringen.

Var IPsec-tunneln sitter på den vägen

Gå nu utåt från webbläsaren. En IPsec-tunnel mellan gateways skyddar vald trafik mellan två säkerhetsgateways, inte mellan din laptop och applikationsprocessen. ESP i tunnelläge packar in det ursprungliga paketet, gatewayerna krypterar och autentiserar det, och de inre adresserna bevaras så att andra sidan kan dirigera begäran till applikationen.

Urvalet är den del som får folk att snubbla. Policybaserade tunnlar använder trafikväljare, ofta uttryckta som åtkomstkontrollistor, för att avgöra vilka paket som går in i tunneln. Routningsbaserade tunnlar använder i stället ett virtuellt gränssnitt och routingtabellen. På Linux visar ip xfrm policy väljarna och ip xfrm state de etablerade säkerhetsassociationerna; på en brandväggsapparat är motsvarigheten tunnelns SA-tabell plus en paketspårare.

Konsekvensen är värd att säga rakt ut. Ett paket kan sitta inne i en helt frisk tunnel och ändå bära en HTTPS-begäran som applikationen avvisar, och giltiga uppgifter kan komma över en väg helt utan tunnel om routningen tillåter det.

Läs felet i det lager som rapporterade det

En 401 betyder att applikationen inte accepterade uppgiften. En 403 betyder att den accepterade identiteten och vägrade operationen. Ett TLS-fel betyder att klienten inte accepterade servern. Ingen rutt eller en policyavvikelse betyder att paketet aldrig nådde den bortre gatewayen. Fyra olika fel, fyra olika ägare, och inget av dem diagnostiseras genom att stirra på inloggningsformuläret.

Använd de bevis varje lager producerar: webbläsarens nätverkspanel för status och huvuden, openssl s_client -connect host:443 för certifikatkedjan, gatewayens SA-räknare och loggar för tunneltrafik, och applikationsloggen för kontobeslutet. När två lager rapporterar fel samtidigt, åtgärda det lägre först, eftersom en död tunnel lätt kan dölja ett autentiseringsfel och tvärtom.

Kartlägg en tjänst från början till slut

Skriv fem rader för tjänsten du felsöker: vilka parter tunneln förbinder, vilka subnät och portar väljarna tillåter, var TLS avslutas och vilken identitet certifikatet hävdar, vilket applikationskonto och vilken roll som används, och var varje lager loggar. Håll dem på en sida, för poängen med kartan är att visa var ett lagers ansvar slutar och nästa börjar.

Testa sedan ett negativt fall per lager. Använd ett fel lösenord och bekräfta att du får 401, inte timeout. Anslut från ett subnät utanför väljarna och bekräfta att paketet inte tunnlas. Presentera ett certifikat för fel namn och bekräfta att klienten vägrar innan den skickar uppgifter. De tre resultaten säger dig mer om designen än något diagram med rutor.

Bestäm till sist medvetet vilket skydd varje relation behöver. Basic-autentisering över TLS passar rimligt för ett litet internt verktyg bakom en gateway; det ersätter inte auktorisering per användare eller skydd av trafik bortom TLS-slutpunkten. Tunneln skyddar vägen, certifikatet skyddar steget och 401 skyddar kontot, och bara det sista vet vem du är.