Modo corretto per chiedere la rinegoziazione dei parametri con SSL

Question

Modo corretto per chiedere la rinegoziazione dei parametri con SSL

#1 da (2 voti)

4

Data una specifica connessione SSL / TLS, vorrei sapere qual è il modo corretto di avviare una rinegoziazione dei parametri, richiesta dal lato client.

1) Sono previsti requisiti dall'handshake precedente nei parametri stabiliti?

2) Qual è la struttura esatta del primo messaggio inviato dal client che chiede la rinegoziazione?

3) Quali sono i successivi messaggi scambiati dal server e dal client. Se sono diversi da una solita stretta di mano, in che modo?

Grazie in anticipo per le tue risposte

Ulteriori domande dopo la risposta di Thomas Pornin:

A. Per quanto riguarda la RFC 5746

Ora capisco un po 'meglio come funziona, tuttavia non riesco ancora a capire perché i parametri di rinegoziazione siano un problema quando un MITM lo lancia, secondo il tuo link rfc5746 # section-1 . Ciò che interessa è che un MITM richieda una rinegoziazione, poiché non conoscerà in alcun modo i segreti scambiati (in particolare il pre-master secret [PMS] inviato durante il ClientKeyExchanged).

Una volta effettuata la rinegoziazione, il MITM non ha modo di decodificare i messaggi in arrivo inviati dal client / server.

Vedo solo 2 possibilità durante la rinegoziazione per lo scambio del PMS:

il MITM fornisce il suo certificato al client, in modo che il client crittografi il PMS con il certificato MITM. In tal caso, il client lo rileva facilmente, poiché non è il certificato che sta aspettando;
il MITM inoltra il certificato del server, ma in tal caso il MITM non avrà alcun modo di decrittografarlo e decrittografare i seguenti messaggi scambiati, poiché non avrà recuperato il PMS.

Quindi dov'è il problema di sicurezza che consente la rinegoziazione del protocollo?

B. Riguardo la struttura

Hai sottolineato che non vi era una struttura definita e precisa fornita dalla RFC. Come ha fatto questo il team di OpenSSL a capirlo? Quale struttura hanno scelto?

openssl tls

posta Janie 21.07.2014 - 10:19

fonte

1 risposta

Leggi altre domande sui tag openssl tls

John the Ripper - Calcolo del tempo di forza bruta per decifrare la password BYOD: conferma che i dispositivi sono approvati

score 2 · Accepted Answer

Vedi lo standard :

The client can also send a ClientHello in response to a HelloRequest or on its own initiative in order to renegotiate the security parameters in an existing connection.

(l'enfasi è mia)

Quindi il client invia un messaggio ClientHello quando vuole eseguire un nuovo handshake. Questo è lo stesso messaggio che il client inviava quando apriva la connessione, con lo stesso contenuto (eccetto il punto sotto dettagliato). Non esiste alcuna relazione con il precedente contenuto dell'handshake, tranne che ClientHello e i successivi messaggi fino a (e includendo) il successivo ChangeCipherSpec , vengono inviati all'interno del contesto crittografico corrente. Ciò significa che questi messaggi di handshake vengono crittografati e MACizzati con gli algoritmi e le chiavi che sono stati negoziati durante la prima stretta di mano. Quando la seconda stretta di mano raggiunge lo stage ChangeCipherSpec , gli algoritmi e le chiavi appena negoziati sostituiscono quelli in vigore fino a quel momento.

La leggera differenza tra ClientHello e ServerHello per una re-handshake è l' Estensione di indicazione di rinegoziazione : è un metodo mediante il quale un cliente può (e dovrebbe) indicare se, dal suo punto di vista, la stretta di mano è la prima o una nuova stretta di mano nel contesto di quella corrente. L' introduzione di RFC 5746 spiega il problema che RIE intende correggere. Il problema strutturale , tuttavia, è che non esiste una definizione chiara in nessuna parte delle proprietà di sicurezza che un handshake dovrebbe fornire; gli implementatori hanno fatto ricorso a indovinare e l'attacco per il quale RFC 5746 è una contromisura dimostra che tale ipotesi, come al solito, è andata male.

(Un modo per vederlo è che la sicurezza della stretta di mano va avanti : le garanzie di sicurezza da un handshake TLS vengono trasportate in successive strette di mano. RIE prova a farle andare anche all'indietro: qualsiasi autenticazione risultante dal secondo l'handshake sarebbe considerato sufficiente per lo scambio di dati prima di quella seconda stretta di mano, ma RFC 5746 non promette in tal senso e non sono a conoscenza di alcuna analisi coerente, coerente e completa del problema. / p>