Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Utökat skydd för autentisering hjälper till att skydda mot MITM-attacker (man-in-the-middle), där en angripare fångar upp en klients autentiseringsuppgifter och vidarebefordrar dem till en server.
Tänk dig ett scenario med tre deltagare: en klient, en server och en angripare. Servern har URL:en https://server, medan angriparen har URL:en https://attacker. Angriparen lurar klienten att komma åt angriparen som om det vore servern. Angriparen skickar sedan en begäran till servern. Om angriparen försöker komma åt en säker resurs svarar servern angriparen med ett WWW-Authenticate-huvud. Angriparen har inte autentiseringsinformationen, så den skickar WWW-Authenticate-huvudet vidare till klienten. Klienten skickar auktoriseringshuvudet till angriparen och angriparen skickar huvudet till servern och får åtkomst till de säkra resurserna med klientens autentiseringsuppgifter.
När ett klientprogram för närvarande autentiserar sig till servern med Kerberos, Digest eller NTLM med HTTPS upprättas först en TLS-kanal (Transport Level Security) och autentisering sker med den här kanalen. Det finns dock ingen bindning mellan sessionsnyckeln som genereras av Secure Sockets Layer (SSL) och sessionsnyckeln som genereras under autentiseringen. I föregående scenario, om kommunikationen sker via en TLS (till exempel en HTTPS-kanal), skapas två SSL-kanaler: en mellan klienten och angriparen och en annan mellan angriparen och servern. Klientens autentiseringsuppgifter skickas från klienten till servern först via SSL-kanalen mellan klienten och angriparen och sedan över kanalen mellan angriparen och servern. När klientens autentiseringsuppgifter når servern verifierar servern autentiseringsuppgifterna utan att identifiera att den kanal som dessa autentiseringsuppgifter skickades via kom från angriparen och inte klienten.
Lösningen är att använda en TLS-skyddad yttre kanal och en klientautentiserad inre kanal och skicka en kanalbindningstoken (CBT) till servern. KBT är en egenskap för den TLS-skyddade yttre kanalen och används för att binda den yttre kanalen till en konversation över den klientautentiserade inre kanalen.
I föregående scenario sammanfogas KBT för TLS-kanalen för klient-angripare med den auktoriseringsinformation som skickas till servern. En CBT-medveten server jämför CBT som finns i klientautentiseringsinformationen, som motsvarar klient-angripare-kanalen, med den CBT som är kopplad till kanalen för angripare-server. En KBT är specifik för en kanals mål, så kbt för klient-angripare matchar inte CBT:t för angripare-servern. På så sätt kan servern identifiera MITM-attacken och neka autentiseringsbegäran.
Klientsidan kräver ingen konfigurationsinställning. När klienten har uppdaterats för att skicka KBT till servern gör den alltid det. Om servern också har uppdaterats kan den konfigureras att använda KBT eller ignorera den. Om den inte har uppdaterats ignoreras den.
Servern kan ha följande skyddsnivåer:
Ingen. Ingen validering av kanalbindning utförs. Det här är beteendet för alla servrar som inte har uppdaterats.
Partiell. Alla klienter som har uppdaterats måste tillhandahålla kanalbindningsinformation till servern. Klienter som inte har uppdaterats behöver inte göra det. Det här är ett mellanliggande alternativ som möjliggör programkompatibilitet.
Fullständig. Alla klienter måste ange kanalbindningsinformation. Servern avvisar autentiseringsbegäranden från klienter som inte gör det.
Mer information finns i Win7 CBT/Extended Protection-exemplet.