Con quale frequenza devono essere ruotate le chiavi del ticket di sessione TLS?

RFC 4346 è la fonte della raccomandazione "giornaliera":

An upper limit of 24 hours is suggested for session ID lifetimes, since an attacker who obtains a master_secret may be able to impersonate the compromised party until the corresponding session ID is retired.

Mancando una guida migliore, probabilmente stai andando bene con 24 ore. Non sono a conoscenza di alcuna ricerca o esperienza che suggerisca che i tempi più brevi siano necessari o appropriati per il traffico corrente.

Puoi anche andare molto più in basso. La ripresa della sessione può essere un grosso problema quando un cliente ti sta martellando con centinaia di connessioni in pochi minuti. Ma dover rinegoziare una volta all'ora, per esempio, non è oneroso per il cliente o per il server. Si risparmia il colpo della CPU di costante rinegoziazione, ma c'è un enorme divario tra "ogni singola connessione" e un'ora - o 30 minuti - o addirittura 5 minuti in alcuni casi.

Per rispondere in modo specifico ai tuoi punti:

1. 24 ore è il limite superiore perché è specificato nella RFC 4346. (Ovviamente, "perché è nella RFC" non riflette le pressioni del mondo reale).
2. Nella finestra delle 24 ore, solo il tuo traffico può guidarti. Con quale frequenza si ricongiungono gli stessi clienti? Approfittano della ripresa se disponibili? Quanto durano le loro sessioni in media?

I periodi di validità del certificato non entrano in esso (poiché 24 ore sono molto al di sotto del loro orizzonte di preoccupazione). I tempi di cache della sessione del client sono interessanti, ma ahimè, probabilmente non disponibili per te - che risale a quello che ho detto sul vedere quanto spesso i tuoi clienti approfittano della ripresa quando disponibili.

I miei consigli personali : puoi giocare con periodi da 1 a 12 ore e probabilmente scoprirai che ti danno tutti l'aumento delle prestazioni di cui hai bisogno con rendimenti decrescenti ( su uso di ripresa) che mostra fino a un certo punto. Trova un modo per registrare la ripresa e le nuove negoziazioni e crea il tuo caso sulle statistiche dei tuoi traffici.

A CloudFlare, abbiamo ruotali ogni ora . *

Per quanto riguarda la tua seconda domanda, devi considerare il supporto UA. Con i ticket di sessione di lunga durata, ad es. 24 ore, è molto meno probabile che si verifichino implementazioni interrotte sul lato client. Ma, con quelli più brevi, come abbiamo scoperto (con un'assistenza formidabile da parte di clienti e utenti), si inizia a vedere sistemi operativi con supporto RFC 5077 incompleto o errato.

Poiché questo bug descrive, sia IE che .NET balk quando la loro libreria crittografica sottostante (SChannel) prova ad elaborare il messaggio NewSessionTicket inviato dal nostro edge. Siamo stati in stretto contatto con Microsoft per una correzione, ma a volte devi risolvere situazioni come questa quando imposti aggressivamente nuovi protocolli e procedure di sicurezza.

In breve, vai al livello che desideri, ma tieni d'occhio i problemi del lato client. Se dovessi indovinare, potrebbero essere più diffusi rispetto a Microsoft.

* Il collegamento discute la nostra implementazione Keyless SSL ma è valida per la nostra terminazione HTTPS standard