Devo usare la rinegoziazione SSL / TLS?

Il problema non sta facendo una rinegoziazione; è nel credere nelle caratteristiche di sicurezza che la rinegoziazione fornisce non .

La rinegoziazione sta facendo una nuova stretta di mano mentre si trova nel bel mezzo di una connessione SSL / TLS. Questo è descritto in lo standard , anche se non in termini molto chiari, specialmente quando si tratta di definire ciò che garantisce l'offerta di rinegoziazione.

La rinegoziazione è molto comune quando utilizzata con i certificati client, specialmente con IIS. Le cose vanno così:

• Il server riceve una richiesta di connessione sulla porta 443; inizia una stretta di mano. Il server non richiede un certificato client.
• Una volta completata l'handshake, il client invia l' URL di destinazione effettivo come richiesta HTTP nel tunnel SSL. Fino a quel momento, il server non sapeva a quale pagina era indirizzato; sapeva solo, nel migliore dei casi, il server desiderato nome (tramite l' Indicazione del nome del server ). Ora che il server sa a quale pagina è indirizzato, sa quale "sito" (vale a dire parte del server, nella terminologia IIS) deve essere usato.
• Se il sito specifico richiede o richiede almeno un'autenticazione client basata su certificati, il server attiva un nuovo handshake, questa volta con un messaggio CertificateRequest .

Il problema di sicurezza qui è una questione di livelli. I messaggi di handshake appaiono "sotto la copertura" come interazioni amministrative out-of-band amministrative, attorno al traffico principale "dati applicativi", che è solo HTTP. Una volta eseguito il nuovo handshake, i dati delle applicazioni successivamente inviati sono coperti dall'omologazione dell'autenticazione SSL. Tuttavia, quale dei dati dell'applicazione è stato inviato prima del secondo handshake, in particolare la richiesta HTTP iniziale che ha deciso di eseguire una seconda stretta di mano del server o, in modo cruciale, altre richieste HTTP inoltrate dopo (ma prima della nuova stretta di mano)?

Succede che i server Web tendevano solo a assumere che qualsiasi autenticazione appena eseguita nella seconda stretta di mano potesse essere "trasportata" ai dati precedenti, retroattivamente. Accade così che non sia vero. Questo non è mai detto chiaramente nello standard SSL / TLS, ma tale autenticazione agisce solo in modo diretto: nessun viaggio nel tempo. La parola importante nel paragrafo precedente è "successivamente". Questo ha permesso un attacco reale (vedi questa pagina per i puntatori a estese spiegazioni).

Un punto cruciale per l'attacco pratico è che i secondi messaggi di handshake sono indistinguibili dai messaggi di handshake per una nuova connessione (ad esempio una "prima stretta di mano"). RFC 5746 descrive la patch, che è stata implementata nei principali browser e server (che assumiamo sia aggiornata con correzioni di sicurezza, altrimenti sei comunque in grossi guai). Questo è anche ciò che OpenSSL riporta come "Rinegoziazione sicura". Si noti che RFC afferma candidamente che:

While this extension mitigates the man-in-the-middle attack described in the overview, it does not resolve all possible problems an application may face if it is unaware of renegotiation.

In altri termini, questa è una patch per risolvere un problema dimostrato, ma non pretende di coprire tutti i motivi. Quale offerta di rinegoziazione davvero non è ancora chiaramente definita ovunque. Se i tuoi client e server supportano "Secure Renegotiation" allora le cose vanno bene per ora (previene tutti gli attacchi attualmente noti ). L'intero concetto di rinegoziazione e strette di mano intercalate ha ancora disperatamente bisogno di un'analisi più formale.

Durante la rinegoziazione un utente malintenzionato può inserire informazioni nella connessione. È descritto in dettaglio qui .