HTTPS Basic Auth versus IPsec: wat elk ervan beschermt

Open de ontwikkelaarstools, laad de interne app en kijk hoe één verzoek vier controlepunten passeert voordat de pagina verschijnt. Eerst wordt de naam omgezet, dan opent een TCP-verbinding, dan stelt een TLS-handshake vast wie de server is, en pas daarna vraagt de applicatie wie jij bent. Behandel die als afzonderlijke gebeurtenissen, want elk faalt met ander bewijs en elk valt onder een ander team. De meeste verwarring bij incidenten komt van een 401 lezen als een tunnelprobleem, of een tunnelprobleem als een verkeerd wachtwoord.

Controlepunt één: is dit de server waarmee je wilde praten

De TLS-handshake beantwoordt die vraag voordat er enige inloggegevens worden verstuurd. Je client valideert de certificaatketen tegen een truststore en controleert of de naam in het certificaat overeenkomt met de host die je typte. Als dat mislukt, toont de browser een certificaatfout en wordt de Authorization-header helemaal niet verstuurd. Een wachtwoordprompt is dus geen bewijs dat de server echt is; het is bewijs dat de applicatie antwoordde.

Hier verschijnt de eerste grens. TLS beschermt de verbinding tot het punt waar die eindigt. Als een load balancer TLS beëindigt en gewoon HTTP naar de applicatie doorstuurt, eindigt het versleutelde deel bij de balancer en zijn de inloggegevens alleen op die eerste hop beschermd.

Controlepunt twee: wat er werkelijk reist in een 401-uitwisseling

HTTP Basic-authenticatie stuurt de gebruikersnaam en het wachtwoord in een header, gecodeerd met Base64 zoals beschreven in RFC 7617. Authorization: Basic dXNlcjpwYXNz is de vorm; de codering is omkeerbaar door iedereen die het verzoek kan lezen, dus alle geheimhouding komt van het transport eronder. curl -v toont zowel de WWW-Authenticate: Basic-uitdaging als de header die je terugstuurt.

Die header vertelt de applicatie wie er vraagt. Hij vertelt het netwerk niet wie er mag verbinden, en hij versleutelt zelf niets. De applicatie moet het aanmeldgeheim nog steeds tegen een opslag controleren en beslissen wat dat account mag doen; dat is autorisatie en gebeurt na authenticatie.

Waar de IPsec-tunnel in dat pad zit

Loop nu vanaf de browser naar buiten. Een gateway-naar-gateway IPsec-tunnel beschermt geselecteerd verkeer tussen twee beveiligingsgateways, niet tussen je laptop en het applicatieproces. ESP in tunnelmodus verpakt het oorspronkelijke pakket, de gateways versleutelen en authenticeren het, en de binnenste adressen blijven bestaan zodat de andere kant het verzoek naar de applicatie kan routeren.

De selectie is het deel waar mensen over struikelen. Policy-gebaseerde tunnels gebruiken verkeersselectoren, vaak uitgedrukt als access control lists, om te bepalen welke pakketten de tunnel in gaan. Route-gebaseerde tunnels gebruiken juist een virtuele interface en de routetabel. Op Linux tonen ip xfrm policy de selectoren en ip xfrm state de opgezette security associations; op een firewall-appliance is het equivalent de SA-tabel van de tunnel plus een packet tracer.

De consequentie is het waard ronduit te zeggen. Een pakket kan in een volkomen gezonde tunnel zitten en toch een HTTPS-verzoek dragen dat de applicatie weigert, en geldige inloggegevens kunnen aankomen over een pad zonder enige tunnel als de routering dat toestaat.

Lees de storing op de laag die hem meldde

Een 401 betekent dat de applicatie het aanmeldgeheim niet accepteerde. Een 403 betekent dat zij de identiteit accepteerde en de handeling weigerde. Een TLS-fout betekent dat de client de server niet accepteerde. Geen route of een policy-mismatch betekent dat het pakket de verre gateway nooit bereikte. Vier verschillende fouten, vier verschillende eigenaren, en geen ervan wordt gediagnosticeerd door naar het inlogformulier te staren.

Gebruik het bewijs dat elke laag oplevert: het netwerkpaneel van de browser voor status en headers, openssl s_client -connect host:443 voor de certificaatketen, de SA-tellers en logboeken van de gateway voor tunnelverkeer, en het applicatielog voor de accountbeslissing. Wanneer twee lagen tegelijk fouten melden, los dan de laagste eerst op, want een dode tunnel kan een authenticatiefout gemakkelijk maskeren en andersom.

Breng één dienst van begin tot eind in kaart

Schrijf vijf regels voor de dienst die je onderzoekt: welke peers de tunnel verbindt, welke subnetten en poorten de selectoren toestaan, waar TLS eindigt en welke identiteit het certificaat claimt, welk applicatieaccount en welke rol worden gebruikt, en waar elke laag logt. Houd ze op één pagina, want het doel van de kaart is te laten zien waar de verantwoordelijkheid van de ene laag eindigt en de volgende begint.

Test daarna één negatief geval per laag. Gebruik een verkeerd wachtwoord en bevestig dat je een 401 krijgt, geen time-out. Verbind vanaf een subnet buiten de selectoren en bevestig dat het pakket niet door de tunnel gaat. Bied een certificaat voor de verkeerde naam aan en bevestig dat de client weigert voordat er inloggegevens worden verstuurd. Die drie resultaten vertellen je meer over het ontwerp dan welk diagram van dozen dan ook.

Beslis ten slotte bewust welke bescherming elke relatie nodig heeft. Basic-authenticatie over TLS past redelijk bij een klein intern hulpmiddel achter een gateway; het is geen vervanging voor autorisatie per gebruiker of voor het beschermen van verkeer voorbij het TLS-eindpunt. De tunnel beschermt het pad, het certificaat beschermt de hop en de 401 beschermt het account, en alleen de laatste weet wie je bent.