Cosa succede al browser di un utente se un certificato SSL viene sostituito a metà sessione?

Alla luce dei browser moderni che eliminano gradualmente i certificati di sicurezza firmati utilizzando l'algoritmo hash SHA1, siamo impegnati a sostituire tutti i nostri certificati SHA1 con SHA2. In genere, potremmo semplicemente sostituire i certificati per queste app web principalmente per uso interno la sera o nel fine settimana, quando c'era poco o nessun traffico.

Cosa accadrebbe se fossi inconsapevolmente nel mezzo di una sessione crittografata e il certificato per il dominio fosse sostituito?

Per essere al sicuro, abbiamo avvisato i nostri clienti che potevano presumere che gli utenti a metà sessione durante questa modifica potessero vedere un'interruzione della loro sessione e una possibile perdita di tutti i dati non ancora archiviati nel database. Se fossi a metà sessione durante una sostituzione del certificato, potrei supporre che quando ho caricato la pagina successiva, dopo la sostituzione del certificato, il mio browser vedrebbe un certificato firmato diverso da quello stabilito con la mia sessione e causerebbe la sessione " impazzire ". Mi aspetto che tutti i browser affrontino questa situazione in modo simile, ma per favore mi illumini se sbaglio.

Ho trascorso un bel po 'di tempo alla ricerca di maggiori dettagli su come i browser gestiranno questo scenario, ma non ho avuto molta fortuna a trovare informazioni generali o tecniche. Sono davvero curioso e ho deciso di pubblicare questa domanda nella speranza di ottenere una risposta che risponda in modo conciso alla Q, con riferimento ad alcune fonti credibili da convalidare.

https security-certificate session

— Dallas
fonte

... il mio browser vedrebbe un certificato firmato diverso rispetto a quello con cui è stata stabilita la mia sessione e causerebbe il "fuori controllo" della sessione.

Dal punto di vista di un webmaster, e senza entrare nei dettagli su " come funziona SSL " (che sarebbe meglio discusso su Sicurezza delle informazioni ) ...

La chiave di sessione non corrisponderebbe più, quindi il server o il browser client interromperebbe la connessione. Il browser client quindi farebbe un'altra richiesta per qualsiasi risorsa nella pagina successiva non ricevuta, che aprirà una nuova connessione, ristabilendo l'handshake SSL, il certificato, gli scambi di chiavi e di nuovo la chiave di sessione (come discusso in breve nella parte inferiore qui ).

Poiché il nuovo certificato SSL verrebbe emesso nello stesso dominio, gli utenti probabilmente non noterebbero nulla poiché cambierebbe solo il certificato (ovvero, il blocco verde verrà comunque visualizzato), che gli utenti in genere non visualizzano comunque, specialmente tra le pagine su lo stesso sito.

Quello che potresti non considerare, tuttavia, è che quando installi il nuovo certificato SSL, dovrai comunque configurare e riavviare il tuo server, in modo che le sessioni vengano chiuse, indipendentemente dal fatto che i browser non ricevano nulla ...

Pertanto, suggerirei di reindirizzare temporaneamente tutto il traffico su una pagina di "Manutenzione" utilizzando un reindirizzamento 302 , con una notifica anticipata pubblicata sul tuo sito che indica il tempo in cui si verificherà la manutenzione e per quanto tempo il sito non sarà disponibile.

Un'alternativa al reindirizzamento sarebbe quella di inviare un codice di risposta del server HTTP non disponibile 503 di servizio con un campo di risposta dell'intestazione HTTP Retry-After per indicare quando il server sarebbe nuovamente disponibile.

Ultimo ma non meno importante, se si dispone di più di un server per il front-end del sito, è possibile installare il certificato su un altro server e reindirizzare nuove connessioni a quello mentre si aggiornano gli altri server. Puoi verificare la presenza di connessioni esistenti in Apache qui e IIS qui per aiutarti, se non usi già una configurazione fail-safe o di bilanciamento del carico.

— dan
fonte

Certs si trova su un bilanciamento del carico di fronte ... quindi non vi è alcuna interruzione del servizio e non sono necessari reindirizzamenti 503 / temp.

— Dallas,

Quindi, se fossi sulla pagina 5 di un flusso di lavoro di 10 pagine ... la mia sessione manterrebbe le informazioni già inserite nelle pagine 1-5 e continuerebbe a pagina 6 con il nuovo certificato, oppure il ripristino della connessione perderebbe tutte le variabili di sessione e mi avvia di nuovo a pagina 1 fresco?

— Dallas,

Dipende da come è codificata la tua applicazione web. Dovrebbe tenere traccia dell'ID sessione per l'utente (memorizzato in un cookie, campo modulo, URL, ecc.), Che è diverso dalla sessione SSL / TLS . Pertanto, se si verifica un'interruzione della connessione (che può verificarsi normalmente), i dati della sessione dell'utente rimarranno per un periodo di tempo fino a quando non effettueranno un'altra connessione. Nella strana circostanza che gli ID di sessione non vengano tracciati, è necessario scaricare nuove connessioni su un altro server e attendere il completamento o il timeout delle connessioni esistenti prima di portare quel server offline per aggiornare il proprio certificato SSL.

— dan

Mi scuso per la scarsa espressione. Quello a cui stavo arrivando è se una sessione ha problemi quando la connessione successiva proviene da un certificato diverso da quello con cui è stata stabilita la sessione. Alla sessione non importa? Penserei che un certificato diverso avrebbe qualche effetto sulla ripresa di una sessione, ma ho l'impressione che tu stia dicendo che alla sessione non interessa la connessione. Non sono consapevole di quale sia la differenza tra sessione SSL e "sessione utente"? Ho avuto l'impressione che l'ID sessione che seguiamo sia l'ID sessione SSL / TLS, che pensavo fosse la stessa cosa della sessione dell'utente.

— Dallas,

Penso che tu stia mescolando un po 'la terminologia: l' ID sessione viene generato dal server e utilizzato per tracciare l'utente attraverso le richieste successive poiché HTTP è senza stato . Tutte le connessioni socket TCP possono terminare, quindi spetta all'applicazione tenere traccia dell'utente quando lo fa, il che viene fatto utilizzando un ID sessione . Ad esempio: accedi in modo sicuro a una banca o ad un altro sito sicuro, fai clic su alcuni link, quindi disabilita la tua nic card, quindi abilitala e fai clic su un altro link ... sarai comunque connesso mentre l'ID della sessione viene tracciato dal loro applicazione.

— dan