Se un server ha una chiave pubblica conosciuta e uno scambio Diffie-Helman viene eseguito e firmato da quella chiave, c'è qualche vantaggio nell'autenticare il client prima di stabilire un canale sicuro invece di stabilire il canale sicuro? Mi sembra che firmare solo un lato dello scambio impedisca ancora un attacco man-in-the-middle.
Ispirato da link
L'autenticazione del client è a vantaggio del server. Prevenire un man-in-the-middle è una questione distinta.
Se lo scambio di chiavi usa DH con una firma dal server (relativamente a una chiave pubblica che è nota al client ) allora il client è protetto da un uomo -in-the-middle: il client ha una strong idea di chi dovrebbe parlare e la firma del server impedisce a un utente malintenzionato di impersonare il server in qualsiasi modo (ad esempio come "man-in-the-middle" , che è solo un tipo specifico di imitazione).
Senza l'autenticazione del client, il server non sa chi lo sta contattando. Il resto del protocollo (ad esempio SSL / TLS ) continuerà a fornire protezione contro gli attacchi nel seguente senso: sarà il stesso cliente per tutta la sessione, e nessun'altra parte può spiare il contenuto dei dati o alterare i dati in modo non rilevato. Come tale, un "man-in-the-middle" (come in: un utente malintenzionato che funge da relay, decifrare e ricodificare i dati al volo) viene evitato, perché il client ha verificato la firma dal server, e quindi ha usato la chiave Diffie-Hellman "giusta", impedendo agli attaccanti di uscire dallo scambio di chiavi.
Autenticazione client come firma, calcolata dal client con la propria chiave privata e corrispondente a una chiave pubblica nota al server, potrebbe aiutare a prevenire un man-in-the-middle in un subdolo situazione in cui il client non (stupidamente) controlla la firma dal server. Nulla può impedire a questo client sconsiderato di connettersi a un server falso, poiché non controlla nulla e può quindi essere sottratto a piacimento. Tuttavia, l'autenticazione del client è sufficiente perché il server si assicuri che, se il client parla a tutti, lo farà in modo sicuro.
Il punto chiave qui è una questione di definizione. Cos'è un "uomo in mezzo"? Questo è un caso in cui un utente malintenzionato impersona il peer previsto (perché sia un "vero centro", l'autore dell'attacco impersona il server per quanto riguarda il client e il client per quanto riguarda il server). Questo ha senso solo nella misura in cui è un "peer previsto". Se il server non si cura di chi lo sta contattando, non c'è idea di "man-in-the-middle".
Nel solito scenario HTTPS, il client è autenticato tramite una password: il client deve essere sicuro di parlare con il server giusto all'inizio (usando il certificato del server) perché il client fa non desidero inviare la sua password a nessuno. Il server vuole solo continuità : se ha ottenuto una password corretta attraverso un tunnel SSL, il tunnel è buono e continuerà a esserlo.
Bene ... sì, il vantaggio è esattamente questo: autenticare il client.
Nel caso di utilizzo principale oggi, il certificato del server viene utilizzato per autenticare il server ("Verisign dice che questo è veramente amazon.com") e per impostare la crittografia (evitando lo snooping e il man-in-the-middle) .
Poiché è usato raramente, le persone non pensano alla possibilità di autenticare il client. C'è una ragione pratica per questo, che è che un utente "utente" (umano) può accedere al server da qualsiasi numero di "macchine" client (computer), e se le chiavi client sono utilizzate devono essere distribuite in modo sicuro a tutti loro, le macchine client devono essere relativamente affidabili, ecc. ecc. Ma gli scenari do esistono laddove l'uso dell'autenticazione client (SSL) ha senso.
Se le smartcard fossero mai decollate, la vedresti dappertutto. Ma loro no. (O semplicemente non l'ho ancora, sinceramente non lo so)
L'autenticazione server solo assicurerà al client che sta parlando al server. Assicura al server che il client che ha eseguito l'handshake è il client che sta effettuando la comunicazione. Non fornisce al server alcuna altra informazione - in altre parole, il server non saprà chi è il client.
In alcuni casi, potrebbe andare bene, ad esempio, se l'accesso viene eseguito tramite nome utente / password dopo l'impostazione della sessione.
Non è sufficiente se si dispone di una situazione che richiede l'autenticazione del client tramite prova crittografica della chiave privata. In questi casi, dovresti aggiungere una trasmissione di livello superiore in cui il client ha firmato qualcosa, altrimenti dovresti richiedere l'autenticazione del client durante l'impostazione della sessione SSL.
Dipende tutto dall'applicazione.
Leggi altre domande sui tag authentication cryptography digital-signature tls key-exchange