TLS Session Tickets: qual è il rischio di una chiave del ticket del server divulgata?

Naviga le tue risposte
2

Quindi esiste questo metodo di ripresa della sessione TLS che utilizza i ticket di sessione che trasferisce lo stato segreto del server TLS al client (crittografato e autenticato con una chiave nota solo al server)

Se un cliente desidera riprendere una sessione, include semplicemente il ticket di sessione nella richiesta, che consente al server di riprendere la sessione.

Domande:

  • Cosa succede se la chiave di sessione (server) viene rubata?
  • Che cosa può fare un utente malintenzionato se registra ALL pacchetti tra il server e vari client? Sarà in grado di decodificare tutto?

Il ticket di sessione include master_secret (che viene utilizzato per la crittografia simmetrica come AES?) ( RFC 5077, pagina 11 ).

  • In che modo esattamente questo master_secret viene riutilizzato dopo la ripresa della sessione? Server e client continueranno a riutilizzare questo master_secret per tutti i crypto simmetrici (ad esempio AES)?
posta Peter Mueller 07.10.2015 - 11:38
fonte

1 risposta

5

Crittografia ticket errata - > PFS rotto.

Credo che questa citazione di un grande post sul blog CloudFlare risponda a ciascuna delle tue domande.

this key becomes [a] critical single point of failure for TLS security: if an adversary gets hold of it, the session key information is exposed for every session ticket! Even after the lifetime of a session ticket, such a loss would invalidate supposed “perfect forward secrecy” (as evangelized here on our blog).

Therefore, it is important to:
“generate session ticket keys randomly, distribute them to the servers without ever touching persistent storage and rotate them frequently.” (Adam Langley)

E si collegano a un post sul blog di Adam Langley che fornisce lo sfondo per questo:

risposta data 07.10.2015 - 13:14
fonte

Leggi altre domande sui tag

Il nome, il DOB e l'ID possono essere PHI? Politica HSTS applicata * a volte *