SSL / TLS: modifica della versione durante la rinegoziazione o la ripresa?

Question

SSL / TLS: modifica della versione durante la rinegoziazione o la ripresa?

#1 da (4 voti)
#2 da (3 voti)

3

La versione proposta dal Cliente può essere modificata durante la ripresa o la rinegoziazione SSL?

caso di ripresa:
In caso di ripresa, come ho capito, il Cliente invierà a un cliente Hello l'ID sessione di una sessione già stabilita. La crittografia deve essere mantenuta uguale, ma è possibile modificare la versione in Client Hello? Non riesco a trovare quale sezione in RFC 5246 o nelle RFC precedenti ne parli.

Caso di rinegoziazione:
SSL / TLS supporta la funzionalità di rinegoziazione per consentire al client e al server di modificare il cifrario negoziato durante il primo handshake che ha fornito la flessibilità necessaria per modificare il metodo di autenticazione e la crittografia per il trasferimento dei dati. Ma può anche essere modificata la versione?

tls

posta Jay 27.12.2012 - 17:20

fonte

2 risposte

3

Sembra, tecnicamente, sì - poiché la versione fa parte del client hello, che viene ripetuta sia in ripresa che in rinegoziazione.

Ma hai ragione che non c'è una sezione esplicita nella RFP su di essa.

Ho trovato, tuttavia, questo:

Extensions should, as far as possible, be designed to prevent any attack that forces use (or non-use) of a particular feature by manipulation of handshake messages. This principle should be followed regardless of whether the feature is believed to cause a security problem. Often the fact that the extension fields are included in the inputs to the Finished message hashes will be sufficient, but extreme care is needed when the extension changes the meaning of messages sent in the handshake phase. Designers and implementors should be aware of the fact that until the handshake has been authenticated, active attackers can modify messages and insert, remove, or replace extensions.

E alla fine c'è una sezione su attacchi di rollback della versione . Questi suoni sono molto diversi da entrambi i casi menzionati nella domanda, ma mi sembra che se hai usato l'impostazione di versione del client ciao nei casi che menzioni, rischieresti un attacco di rollback della versione, e mi chiedo se ciò implicasse che non dovresti davvero usarlo in quel modo.

risposta data 27.12.2012 - 18:02
fonte

Leggi altre domande sui tag tls

Come impedire completamente i flussi di bufferover nel software di rete? Attacca l'ambiente circostante / etc / hosts /

score 4 · Accepted Answer

Lo standard TLS corrente non è molto chiaro su come devono essere gestite le versioni. L'allegato E.1 contiene alcune informazioni, dalle quali possiamo vedere che l'idea implicita è che la versione selezionata dipende da ciò che il supporto del client e del server , non da ciò che il client e il server può scegliere di usarlo per un capriccio. Se un client supporta fino a TLS 1.2 e un server fino a TLS 1.1, allora dovrebbe utilizzare TLS 1.1, sempre. Pertanto, non ci dovrebbe essere alcuna domanda su "cambiare la versione" quando si riprende una sessione o si rinegozia.

Esistono diversi campi di versione:

Ogni "record" ha un campo versione.

Il messaggio ClientHello contiene la versione più alta supportata dal client.

Il messaggio ServerHello contiene la versione che sarà utilizzata su questa connessione.

Presumibilmente, il client invierà il suo primo ClientHello come un record con un numero di versione 3.x per un certo valore di "x"; 3.0 ottimizzerà l'interoperabilità. Una volta che il server ha risposto con un ServerHello che indica che verrà utilizzata la versione 3.y, sia il client che il server devono utilizzare i record 3.y. Ciò rende la versione estremamente delicata durante una rinegoziazione. Inoltre, i record TLS 1.1+ crittografati CBC non sono compatibili con i record SSL 3.0 / TLS 1.0 (a causa del IV per record aggiuntivo), quindi le versioni a livello di record sono importanti una volta che il primo ChangeCipherSpec è stato inviato / ricevuto.

Per la ripresa della sessione, l'allegato E.1 afferma che:

Whenever a client already knows the highest protocol version known to a server (for example, when resuming a session), it SHOULD initiate the connection in that native protocol.

da cui deduco che se la sessione precedente usasse la versione 3.y, allora il client dovrebbe usare records con la versione 3.y. Tuttavia, nulla impedisce di pubblicizzare un numero di versione più elevato in ClientHello.

Inoltre, la derivazione della chiave master nella crittografia e le chiavi MAC utilizzano il TLS PRF, che dipende dalla versione del protocollo (TLS 1.0 e 1.1 utilizzano lo stesso PRF, ma non SSL 3.0 e né TLS 1.2). Riprendere una sessione con una versione diversa è in cerca di problemi.

L'intera area è torbida. Vedi ad esempio questo bug report di Mozilla / Firefox . Nella mia esperienza, le seguenti regole dovrebbero essere seguite per ridurre al minimo i problemi:

Regole per il cliente:

Invia il primo record come versione 3.0.

Pubblicizza sempre nella versione ClientHello la versione massima supportata (ad esempio 3.3 per TLS 1.2).

Quando il server risponde con ServerHello, usa la versione inviata dal server come nuova versione per tutti i record successivi, i calcoli crittografici e i dettagli del protocollo.

Una volta che il server ha inviato un ServerHello, applica le versioni dei record in entrata: i record successivi dal server dovrebbero usare quella . Se un record del server pubblicizza un'altra versione, interrompi.

Quando si rinegozia, se il server tenta di utilizzare un'altra versione rispetto a quella precedente, annulla

Regole per il server:

Ignora la versione sui record in entrata, durante i primi passi della connessione.

Una volta inviato ServerHello, applica le versioni dei record: tutti i record successivi del client devono utilizzare quella versione.

Quando si riprende una sessione, riutilizzare la stessa versione, a condizione che la versione in ClientHello lo consenta; in caso contrario, eseguire una stretta di mano completa (ad esempio se la sessione precedente era TLS 1.1 e il nuovo ClientHello dice 1.2, riprendere con la versione 1.1, se la sessione precedente era TLS 1.1 e il nuovo ClientHello dice 1.0, non riprendere, eseguire una nuova versione completa 1.0 stretta di mano).

Quando si rinegozia, verificare che la versione pubblicizzata nel nuovo ClientHello sia compatibile con la versione corrente, ma non modificare la versione corrente. Se il primo handshake era 1.1, il secondo handshake sarà 1.1, anche se il nuovo ClientHello dice 1.2.

È praticamente garantito che ci siano alcune implementazioni ampiamente implementate che a un certo punto sbagliano.