Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La protezione estesa per l'autenticazione consente di proteggersi dagli attacchi MAN-in-the-middle (MITM), in cui un utente malintenzionato intercetta le credenziali di un client e le inoltra a un server.
Si consideri uno scenario con tre partecipanti: un client, un server e un utente malintenzionato. Il server ha l'URL https://server, mentre l'utente malintenzionato ha l'URL https://attacker. L'attaccante inganna il client facendogli accedere all'attaccante come se fosse il server. L'utente malintenzionato invia quindi una richiesta al server. Se l'utente malintenzionato sta tentando di accedere a una risorsa sicura, il server risponde all'utente malintenzionato con un'intestazione WWW-Authenticate. L'utente malintenzionato non dispone delle informazioni di autenticazione, quindi invia l'intestazione WWW-Authenticate al client. Il client invia l'intestazione Authorization all'utente malintenzionato e l'autore dell'attacco invia l'intestazione al server e ottiene l'accesso alle risorse protette usando le credenziali del client.
Attualmente, quando un'applicazione client esegue l'autenticazione al server usando Kerberos, Digest o NTLM tramite HTTPS, viene stabilito un canale TLS (Transport Level Security) e viene eseguita l'autenticazione usando questo canale. Tuttavia, non esiste alcuna associazione tra la chiave di sessione generata da Secure Sockets Layer (SSL) e la chiave di sessione generata durante l'autenticazione. Quindi, nello scenario precedente, se la comunicazione avviene su un tls (ad esempio un canale HTTPS), sono stati creati due canali SSL: uno tra il client e l'utente malintenzionato e un altro tra l'utente malintenzionato e il server. Le credenziali del client vengono inviate dal client al server prima tramite il canale SSL tra il client e l'utente malintenzionato e quindi sul canale tra l'utente malintenzionato e il server. Quando le credenziali del client raggiungono il server, il server verifica le credenziali senza rilevare che il canale su cui sono state inviate tali credenziali ha avuto origine con l'autore dell'attacco e non con il client.
La soluzione consiste nell'usare un canale esterno protetto da TLS e un canale interno autenticato dal client e passare un token cbt (Channel Binding Token) al server. CbT è una proprietà del canale esterno protetto da TLS e viene usato per associare il canale esterno a una conversazione tramite il canale interno autenticato dal client.
Nello scenario precedente, il CBT del canale TLS tra client e attaccante è unito alle informazioni di autorizzazione inviate al server. Un server compatibile con CBT confronta il CBT contenuto nelle informazioni di autenticazione del client, che corrisponde al canale client-attacker, al CBT collegato al canale attacker-server. Un CBT è specifico per la destinazione di un canale, quindi il CBT client-attaccante non corrisponde al CBT attaccante-server. In questo modo il server rileva l'attacco MITM e rifiuta la richiesta di autenticazione.
Il lato client non richiede alcuna impostazione di configurazione. Dopo che il client è stato aggiornato per passare il CBT al server, continuerà sempre a farlo. Se il server è stato aggiornato, può essere configurato per utilizzare il CBT o ignorarlo. Se non è stato aggiornato, lo ignora.
Il server può avere i livelli di protezione seguenti:
Nessuno. Non viene eseguita alcuna convalida dell'associazione di canale. Si tratta del comportamento di tutti i server che non sono stati aggiornati.
Parziale. Tutti i client che sono stati aggiornati devono fornire informazioni sull'associazione di canali al server. I client che non sono stati aggiornati non devono farlo. Si tratta di un'opzione intermedia che consente la compatibilità delle applicazioni.
Completo. Tutti i clienti devono fornire informazioni sull'associazione di canale. Il server rifiuta le richieste di autenticazione dai client che non lo fanno.
Per ulteriori informazioni, vedere l'esempio CBT/Protezione Estesa di Win7.