Di seguito è riportato uno screenshot dal documento "Prudent Engineering Practice for Cryptographic Protocols" di Martin Abadi e Roger Needham. Non riesco a vedere cosa c'è che non va nel protocollo e ciò che la correzione raggiunge. Aiuto per favore? Mi sta facendo impazzire.
Lascia che C sia l'attaccante. C esegue un altro server, con il proprio nome ( C ), con la propria chiave pubblica K c . Occasionalmente, A si connette a C (consapevolmente, ma non sapendo che C è il Male, o credendo che la malvagità di C non si estenderà oltre C stesso). L'attacco va così:
E, voilà! C ha eseguito correttamente il protocollo con B , inviando un certificato e una firma appropriati da A , calcolati sul valore di sfida che B inviato a C . C è quindi autenticato come A per quanto riguarda il server B . Il A originale non ha notato nulla e non è a conoscenza del fatto che qualcosa è stato fatto in relazione al server B .
La correzione descritta nell'articolo risolve il problema, che è quello nel protocollo originale, la firma di A è retargetable: nell'attacco, A firma una sfida ricevuto dal server C , ma la firma funziona anche come risposta per la stessa sfida dal server B . Includere il nome di B in ciò che è firmato impedisce la manipolazione: ora, una risposta a una sfida da un determinato server non può essere utilizzata come risposta alla stessa sfida da un altro server distinto.
Ci sono altri attacchi simili che costringono anche l'inclusione del nome A in ciò che è firmato. In SSL / TLS come è attualmente definito, la firma dal client (nel messaggio ClientKeyExchange ) viene calcolata su un hash di tutti i precedenti messaggi di handshake (inviati e ricevuti), che include sia i nomi client che i nomi dei server (come parte dei rispettivi messaggi Certificate ).
Leggi altre domande sui tag authentication client tls