Ho sentito che con il segreto in avanti che i codici ECDSA generano chiavi diverse per "ogni sessione" perché non dipendono dalla chiave privata del server. La mia domanda è: come viene definita "ogni sessione"? Questo approccio chiave diverso significa che accade con ogni connessione SSL consecutiva / diversa per dire lo stesso server o avviene all'interno della connessione SSL esistente come richiesta di rinegoziazione SSL lato server?
Ogni sessione indica ogni sessione SSL. Una sessione SSL può essere riutilizzata su più connessioni TCP (cioè connessioni SSL) se sia il client che il server implementano il riutilizzo della sessione e ciascuna delle connessioni SSL viene chiusa in modo pulito.
Una connessione SSL potrebbe anche consistere in più sessioni SSL se si fanno più handshake SSL completi all'interno della stessa connessione.
The key used to protect transmission of data must not be used to derive any additional keys, and if the key used to protect transmission of data is derived from some other keying material, then that material must not be used to derive any more keys. In this way, compromise of a single key permits access only to data protected by that single key.
PFS vale true sopra, ma soddisfa le due proprietà seguenti:
How is "each session" defined?
Ephemeral Diffie Hellman è usato per PFS . L'utilizzo di Ephemeral Diffie Hellman (DHE / ECDHE) obbliga ogni sessione a rinegoziare il proprio parametro DH ogni volta che si chiude una singola sessione SSL. Quindi "ogni sessione" significa letteralmente non appena la sessione termina le chiavi vengono distrutte. Nessun ID di sessione viene memorizzato dal server, quindi ogni volta vengono forzate nuove chiavi.
Does this different key approach mean it happens with each consecutive/different SSL connection to say the same server or does it happen within the existing SSL connection as server side SSL re-negotiation request happen?
Non importa se è lo stesso server, o una riconciliazione sul lato server il server non dovrebbe avere chiavi di sessione memorizzate nella cache. Quindi sono necessari nuovi parametri DH con le suite di crittografia DHE *. Ora è così che funziona la teoria. La configurazione è una specie di storia diversa. Alcuni server potrebbero dover disabilitare la ripresa della sessione per garantire che ciò si verifichi.
Implementations SHOULD generate a new X for each handshake when using DHE cipher suites.
Leggi altre domande sui tag cryptography encryption public-key-infrastructure tls certificates