Questo documento afferma che un'autenticazione della risposta alla verifica dimostra l'identità dei server. Ma un uomo nell'attacco intermedio è ancora possibile se il client non verifica il nome di dominio? Per favore aiutami a capire questo.
Questo documento afferma che un'autenticazione della risposta alla verifica dimostra l'identità dei server. Ma un uomo nell'attacco intermedio è ancora possibile se il client non verifica il nome di dominio? Per favore aiutami a capire questo.
L'handshake SSL implica l'uso di certificati; il server ha un certificato che il client deve validare (per quanto riguarda i suoi noti ancore di sicurezza, ovvero "root CA"). Il certificato contiene una chiave pubblica e gli algoritmi crittografici utilizzati in SSL che la connessione è sicura nel seguente modo:
Il client sa che qualsiasi dato inviato e ricevuto sarà utilizzabile solo dal server che possiede la chiave privata associata alla chiave pubblica ricevuta (all'interno di un certificato).
Il certificato dimostra al cliente che la suddetta chiave privata è posseduta (controllata) da una certa entità il cui nome è scritto nel certificato; per SSL, il nome è un nome DNS come "www.example.com".
È ancora compito del cliente verificare che il nome nel certificato sia il nome del server che il cliente intendeva contattare in primo luogo.
Analogia: incontri qualcuno che ti dice che il suo nome è Bob. Gli chiedi di mostrarti una carta d'identità. Verificare che la carta d'identità sia una vera carta d'identità non è sufficiente; tu anche devi controllare che il nome sulla carta d'identità sia effettivamente "Bob". Altrimenti, Charlie potrebbe dirti "I am Bob" e mostrarti la sua carta d'identità con il nome "Charlie".
La risposta di Thomas è grandiosa. Prenderò solo nota che ci sono ancora buchi nel sistema, e hai ragione di prestare molta attenzione.
Il buco più grande è che di default hai probabilmente un numero enorme di certificati radice "attendibili", ognuno dei quali può certificare qualsiasi nome DNS. Penso che ci sia una ragione per non fidarsi di tutti loro.
Ad esempio, nel 2009, Etisalat (posseduta al 60% dal governo degli Emirati Arabi Uniti), ha lanciato una patch innocua per il BlackBerry che ha inserito spyware nei dispositivi RIM, consentendo il monitoraggio della posta elettronica, quindi difficilmente può essere considerata attendibile . Ma è in molti elenchi di CA attendibili: link
I meccanismi utilizzati da molte CA per convalidare il possesso di un nome di dominio sono vulnerabili a vari attacchi, quindi la gente può ottenere credenziali che non dovrebbero.
Inoltre, le persone possono rubare i certificati, come è stato fatto due volte dagli sviluppatori di stuxnet.
Le parti relative alle politiche del puzzle di chiavi pubbliche / private sono molto più difficili della stessa crypto.
Aggiornamento: Vedi anche un ottimo post sulla riparazione della nostra pericolosa infrastruttura CA su Freedom to Tinker: Creazione di una migliore infrastruttura CA
Un server dimostra la propria identità essendo firmato da un'autorità di certificazione di root (o intermediario) che il browser considera affidabile.
La CA radice (ad esempio Verisign) firma digitalmente la richiesta di certificato del sito. La firma digitale è il modo di Verisign di certificare l'identità del sito web originale. Verisign ha metodi per impedire a qualcuno come me di generare un certificato per eBay, di solito attraverso la registrazione di persona o utilizzando una combinazione di prove di identità.
L'elenco delle CA radice viene aggiornato e revocato con il passare del tempo, questo potrebbe essere notato nell'aggiornamento di Windows.
Detto questo, se qualcuno ha accesso fisico a una macchina, può sempre installare certificati radice falsi ... il che rende nuovamente possibile l'uomo nel mezzo, senza avvertimenti.
Leggi altre domande sui tag authentication cryptography public-key-infrastructure tls certificates