Overzicht uitgebreide beveiliging voor verificatie
Uitgebreide beveiliging voor verificatie beschermt tegen MAN-in-the-middle-aanvallen (MITM), waarbij een aanvaller de referenties van een client onderschept en doorstuurt naar een server.
Overweeg een scenario met drie deelnemers: een client, server en aanvaller. De server heeft de URL https://server, terwijl de aanvaller de URL https://attackerheeft. De aanvaller misleidt de client om toegang te krijgen tot de aanvaller alsof het de server was. De aanvaller verzendt vervolgens een aanvraag naar de server. Als de aanvaller toegang probeert te krijgen tot een beveiligde resource, reageert de server op de aanvaller met een WWW-Authenticate-header. De aanvaller beschikt niet over de verificatiegegevens. De header WWW-Authentication wordt daarom naar de client verzonden. De client verzendt de autorisatieheader naar de aanvaller en de aanvaller stuurt de header naar de server en krijgt toegang tot de beveiligde resources met behulp van de referenties van de client.
Wanneer een clienttoepassing zich momenteel verifieert bij de server met behulp van Kerberos, Digest of NTLM met https, wordt er eerst een TLS-kanaal (Transport Level Security) tot stand gebracht en vindt verificatie plaats met behulp van dit kanaal. Er is echter geen binding tussen de sessiesleutel die wordt gegenereerd door Secure Sockets Layer (SSL) en de sessiesleutel die tijdens de verificatie wordt gegenereerd. Dus, in het vorige scenario, als de communicatie plaatsvindt via een TLS (zoals een HTTPS-kanaal), zijn er twee SSL-kanalen gemaakt: een tussen de client en de aanvaller, en een andere tussen de aanvaller en de server. De referenties van de client worden eerst vanaf de client naar de server verzonden via het SSL-kanaal tussen de client en de aanvaller en vervolgens via het kanaal tussen de aanvaller en de server. Zodra de referenties van de client de server bereiken, verifieert de server de referenties zonder te detecteren dat het kanaal waarover deze referenties zijn verzonden, afkomstig is van de aanvaller en niet van de client.
De oplossing is het gebruik van een met TLS beveiligd buitenkanaal en een door de client geverifieerd binnenkanaal en het doorgeven van een CBT (Channel Binding Token) aan de server. De CBT is een eigenschap van het met TLS beveiligde buitenkanaal en wordt gebruikt om het buitenste kanaal te verbinden met een gesprek via het door de client geverifieerde binnenkanaal.
In het vorige scenario wordt de CBT van het TLS-kanaal van de client-aanvaller samengevoegd met de autorisatiegegevens die naar de server worden verzonden. Een CBT-bewuste server vergelijkt de CBT in de clientverificatiegegevens, die overeenkomt met het kanaal van de client-aanvaller, met de CBT die is gekoppeld aan het kanaal van de aanvaller-server. Een CBT is specifiek voor de bestemming van een kanaal, dus de CLIENT-aanvaller CBT komt niet overeen met de CBT van de aanvaller-server. Hierdoor kan de server de MITM-aanval detecteren en de verificatieaanvraag weigeren.
Voor de clientzijde is geen configuratie-instelling vereist. Zodra de client is bijgewerkt om de CBT door te geven aan de server, doet deze dit altijd. Als de server ook is bijgewerkt, kan deze worden geconfigureerd om de CBT te gebruiken of te negeren. Als deze niet is bijgewerkt, wordt deze genegeerd.
De server kan de volgende beveiligingsniveaus hebben:
Geen. Er wordt geen validatie van kanaalbindingen uitgevoerd. Dit is het gedrag van alle servers die niet zijn bijgewerkt.
Gedeeltelijk. Alle clients die zijn bijgewerkt, moeten kanaalbindingsinformatie verstrekken aan de server. Clients die niet zijn bijgewerkt, hoeven dit niet te doen. Dit is een tussenliggende optie waarmee toepassingscompatibiliteit mogelijk is.
Volledig. Alle clients moeten informatie over kanaalbinding opgeven. De server weigert verificatieaanvragen van clients die dit niet doen.
Zie het Win7 CBT/Extended Protection-voorbeeld voor meer informatie.