Meta : la politica di SE è generalmente contro più domande in un solo post. Ma qui la tua seconda domanda è un duplicato di triplo handshake contro TLS a cui ho già risposto, lasciando una domanda aperta.
La formulazione nel glossario di rfc 5246 (e dei suoi predecessori) potrebbe essere un po 'pigra, perché ci si aspetta che presti attenzione all'intero documento. Il punto effettivo è che una connessione (TCP) è associata a una sessione TLS alla volta . La sequenza temporale è:
-
Per avviare TLS / SSL, fai (o talvolta hai già) una connessione TCP e fai un handshake completo per creare una nuova sessione o fai una stretta di mano abbreviata per riprendere una sessione esistente (se ce n'è una disponibile ). Dopo la negoziazione iniziale , tutti i dati trasmessi e ricevuti vengono crittografati (a meno che eNULL) e autenticati utilizzando chiavi derivate dal master_secret per quella sessione (più nonces correnti), e dovrebbero essere trattati da entrambe le parti come aventi i parametri di sicurezza (e altri) di quella sessione: master_secret, algoritmi, autenticazione del server in genere, autenticazione del client se utilizzata e compressione TLS se utilizzata, che non è mai stata molto popolare e dopo CRIME è spesso proibita completamente.
-
In qualsiasi momento successivo durante la stessa connessione, se entrambi gli endpoint sono d'accordo, puoi fare un altro handshake chiamato rinegoziazione sulla stessa connessione. Questa rinegoziazione può essere di nuovo una stretta di mano completa che crea una nuova sessione o una stretta di mano abbreviata che riprende una sessione esistente. Nel caso di ripresa, può riprendere la stessa sessione che era in uso prima della rinegoziazione, o potrebbe essere una sessione salvata diversa. Una volta effettuata la rinegoziazione, i dati successivi utilizzano le chiavi e i parametri della sessione selezionata dalla rinegoziazione, di solito anche se non necessariamente diversa dalla sessione dall'handshake iniziale.
-
In un secondo momento è possibile eseguire una seconda rinegoziazione, sempre con le stesse funzionalità. Successivamente, i dati utilizzano le chiavi e i parametri della sessione selezionata dalla seconda rinegoziazione, probabilmente diversa dalla / e sessione / i dalla prima rinegoziazione e dall'handshake iniziale.
-
Et cetera, et cetera, et cetera.
Dopo aver terminato una connessione, puoi creare un'altra connessione che può di nuovo creare una nuova sessione o riprenderne una esistente, se disponibile; spesso gli endpoint abbandonano una sessione dopo un limite di tempo di 5 minuti o 1 ora, oppure se esauriscono lo spazio o hanno un errore. E ancora, e ancora. Puoi anche creare più connessioni contemporaneamente, ognuna delle quali può creare una nuova sessione o riprenderne una esistente. E dopo averli terminati, puoi fare di più, idem.
La rinegoziazione al giorno d'oggi viene di solito eseguita quando una parte, solitamente il server, desidera modificare i parametri di sicurezza , ad esempio l'autenticazione del client che non è stata eseguita sull'handshake iniziale (o sulla rinegoziazione precedente). Per modificare i parametri di sicurezza, la rinegoziazione deve essere full handshake .
Ma il protocollo consente alla rinegoziazione di essere una stretta di mano abbreviata che riprende una sessione. L'unica ovvia ragione valida per questo è se hai crittografato abbastanza dati in un set di chiavi funzionanti che vuoi generare nuove chiavi di lavoro, tradizionalmente chiamate rekey [ing] . Con la modalità CBC è consigliabile non superare il limite di "compleanno" dei blocchi sqrt (2 ^ blocchi) sotto una chiave, e per 3DES (e DES negli anni precedenti alla sua obsoleta) si tratta di 2 ^ 35 ottetti o 512GiB. Con le reti moderne sottoposte a un carico prolungato potresti raggiungere questo volume e voler riprogrammare, in circa un'ora o forse meno, e anche con un minore carico questo potrebbe facilmente verificarsi in giorni o settimane.