Modifica del certificato lato server durante la connessione in corso: è supportato? quali sono gli effetti sulle connessioni esistenti?

Question

Modifica del certificato lato server durante la connessione in corso: è supportato? quali sono gli effetti sulle connessioni esistenti?

#1 da (1 voti)

0

Mi stavo chiedendo (basato sul TLS RFC e sulla sua attuale implementazione da parte dei principali fornitori / piattaforme - IIS di Microsoft): come si comporterebbe / reagirebbe una sessione SSL / TLS attiva esistente se il server in cui cambiare il certificato che era usato per negoziare inizialmente quella sessione con un intero nuovo certificato?

Il server chiuderà automaticamente le sessioni esistenti? (e in particolare, in che modo IIS e Windows Server 2008R2 / 2012R2 gestiscono questo caso: il lato server potrebbe iniziare a utilizzare il certificato server appena selezionato senza influire sulle sessioni SSL / TLS già stabilite?)

Oppure il server sarebbe in grado di cambiare il suo certificato senza influenzare (chiudendo) le sessioni crittografate già esistenti?

Il client avrebbe rilevato il cambiamento in una fase successiva durante la sessione (ad esempio, se si dovesse eseguire una rinegoziazione della sessione)?

Grazie in anticipo.

tls certificates updates windows-server

posta Ottootto 28.04.2017 - 07:41

fonte

1 risposta

Leggi altre domande sui tag tls certificates updates windows-server

Questo algoritmo di rotazione su RSA è possibile? Impostazione di un indirizzo di ritorno in un semplice exploit C

score 1 · Accepted Answer

Il certificato del server viene utilizzato solo durante l'handshake TLS. È irrilevante per la sessione rimanente e quindi non è necessario chiudere una sessione quando il certificato cambia. Infatti, il client non si accorgerà nemmeno che un certificato è cambiato (o se un certificato è stato revocato) a meno che non venga fatto un nuovo handshake TLS, ovvero quando si fa una nuova connessione o quando si fa una rinegoziazione all'interno di una connessione esistente.

Ma potrebbe essere che specifiche implementazioni del server chiudano una sessione come un effetto collaterale quando il certificato viene modificato per motivi tecnici, ad esempio perché il processo deve essere riavviato.

Esistono implementazioni client che limitano le modifiche dei certificati alla rinegoziazione al fine di gestire l'attacco triplo handshake . Pertanto, se il server modifica il certificato e viene attivata una rinegoziazione (forse perché è necessario controllare un certificato client), ciò può risultare con le attuali implementazioni Java in la modifica del certificato del server è limitata durante la rinegoziazione .