"Insecure Renegotiation" non riguarda la selezione della suite di cifratura; si tratta di una sorta di attacco Man-in-the-Middle che va così:
- L'attaccante si connette al server ed esegue un primo handshake.
- L'attaccante invia alcuni dati (ad esempio una richiesta POST HTTP).
- Il client si connette al malintenzionato e invia la sequenza iniziale di handshake.
- L'attaccante inoltra i messaggi di handshake del client al server e viceversa. Dal punto di vista del cliente, questa è l'iniziale stretta di mano; dal punto di vista del server, questa è una rinegoziazione all'interno del contesto stabilito inizialmente con l'autore dell'attacco.
- Da quel momento in poi, l'attaccante passa ciecamente avanti e indietro i dati. Il server avvia un meccanismo di autenticazione con il client.
- Il server considera erroneamente che il risultato dell'autenticazione copre il dialogo completo , inclusi i dati che l'utente malintenzionato ha spinto prima della rinegoziazione. Di conseguenza, il server può applicare la richiesta dell'attaccante come se provenisse dal client autenticato.
RFC 5746 è un meccanismo (un'estensione TLS) che mira a rendere distinta l'iniziale stretta di mano e la stretta di mano di rinegoziazione. Se supportato sia dal client che dal server, il server, nello scenario precedente, noterà che ClientHello nella seconda stretta di mano è contrassegnato come "iniziale", non come "rinegoziazione" e pertanto rifiuterà il tentativo. Quando alcuni report ti dicono che il tuo server fa "rinegoziazione insicura", ti dice veramente che il tuo server non supporta RFC 5746. Questo è completamente estraneo alla selezione della suite di crittografia, e non c'è alcun cambiamento nella tua lista di pacchetti di crittografia che farà qualsiasi cosa a favore o contro ciò; questa è un'impostazione ortogonale.
Si può notare che consentire una rinegoziazione insicura non implica necessariamente un buco sfruttabile. Dipende davvero da come il server gestisce l'autenticazione dell'utente, in particolare per quanto riguarda le rinegoziazioni. Concettualmente, un server che riceve una richiesta non autenticata può avviare una rinegoziazione (ad es. Con autenticazione client basata su certificato) e quindi, dopo la seconda stretta di mano, inviare un reindirizzamento HTTP in modo che il client risponda nuovamente alla richiesta. In tal caso, non ci sarebbe alcun problema con la mancanza di supporto di RFC 5746. Tuttavia, i server Web esistenti non operano in questo modo, quindi un bisogno comune di "rafforzare" le negoziazioni sistematiche a livello TLS.
(In termini generali, il problema con la rinegoziazione è che SSL / TLS fornisce sicurezza solo nella direzione cronologicamente avanzata, mentre gli utenti di SSL / TLS, cioè il server Web, comunemente ritengono che anche la sicurezza si estenda all'indietro, anche attraverso rinegoziazioni. La RFC 5746 corregge una modalità di attacco esplicita nota, ma non è chiaro - o almeno non documentato - se garantisce realmente l'autenticazione a ritroso fino all'handshake iniziale.)