Come è stata riparata la rinegoziazione TLS?

6

Ho letto l'RFC 5746 sull'estensione della rinegoziazione sicura TLS. Tuttavia, non capisco come risolve il problema.

Client e server devono includere il parametro verify_data dall'handshake precedente nei messaggi ClientHello e ServerHello. La correzione protegge contro un attaccante che è un MITM attivo. Non è possibile che questo aggressore includa solo il suo verify_data nel ClientHello che intercetta dal client (ricorda, questo è tutto senza firma, lo scambio di chiavi sta succedendo) e spoglia il parametro verify_data dal ServerHello con cui il server risponde? In questo modo, il server penserà che sia in corso una rinegoziazione sicura, mentre il client vedrà un campo renegotiated_connection vuoto che corrisponde al fatto che sta avviando una nuova connessione.

Il mio ragionamento deve essere sbagliato, qualcuno può indicarlo?

    
posta chris 09.12.2011 - 10:50
fonte

1 risposta

10

In un handshake TLS, i messaggi "Finished" contengono un valore che è un hash di tutti i messaggi di handshake scambiati finora (per questa stretta di mano). Se l'attaccante altera ClientHello, l'hash non corrisponde: quando termina il secondo handshake (il primo e unico handshake nella vista del client, la seconda stretta di mano dal punto di vista del server), il client invia un 'Finito 'messaggio che l'utente malintenzionato non può modificare (è crittografato e dotato di MAC con la chiave appena negoziata) e quel messaggio contiene un computer hash, tra le altre cose, il Client che il client ha inviato . Se il server ha visto un ClientHello distinto (uno senza l'estensione di rinegoziazione), allora calcolerà un hash distinto, i contenuti "Finito" non corrisponderanno e la connessione verrà interrotta.

    
risposta data 09.12.2011 - 14:40
fonte

Leggi altre domande sui tag