5. Considerazioni sulla sicurezza

Questa sezione affronta i problemi di sicurezza legati all'uso di un ticket. I ticket devono essere autenticati e cifrati per prevenire modifiche o intercettazioni da parte di un attaccante. Diversi attacchi descritti di seguito saranno possibili se ciò non viene fatto con attenzione.

Le implementazioni dovrebbero prestare attenzione a garantire che l'elaborazione dei ticket non aumenti la possibilità di un denial of service come descritto di seguito.

5.1. Invalidazione delle sessioni

La specifica TLS richiede che le sessioni TLS siano invalidate quando si verificano errori. [CSSC] discute in dettaglio le implicazioni di sicurezza di ciò. Nell'analisi contenuta in questo documento, il mancato annullamento delle sessioni non costituisce un rischio per la sicurezza. Questo perché l'handshake TLS usa una funzione non reversibile per derivare le chiavi di una sessione, quindi le informazioni su una sessione non forniscono un vantaggio per attaccare il master secret o una sessione diversa. Se viene usato uno schema di annullamento delle sessioni, l'implementazione dovrebbe verificare l'integrità del ticket prima di usarne il contenuto per annullare una sessione, per garantire che un attaccante non possa annullare una sessione scelta.

5.2. Ticket rubati

Un intercettatore o un man-in-the-middle può ottenere il ticket e tentare di usarlo per stabilire una sessione con il server; tuttavia, poiché il ticket è cifrato e l'attaccante non conosce la chiave segreta, un ticket rubato non aiuta un attaccante a riprendere una sessione. Un server TLS DEVE (MUST) usare una cifratura forte e una protezione dell'integrità per il ticket, per impedire a un attaccante di usare un meccanismo di forza bruta per ottenere il contenuto del ticket.

5.3. Ticket contraffatti

Un utente malintenzionato potrebbe contraffare o alterare un ticket per riprendere una sessione, per estenderne la durata, per impersonare un altro utente o per ottenere privilegi aggiuntivi. Questo attacco non è possibile se il ticket è protetto usando un algoritmo di protezione dell'integrità forte, come un HMAC-SHA-256 con chiave.

5.4. Attacchi di denial of service

Il campo key_name definito nel formato di ticket raccomandato aiuta il server a rifiutare in modo efficiente i ticket che non ha emesso. Tuttavia, un avversario potrebbe memorizzare o generare un gran numero di ticket da inviare al server TLS per la verifica. Per ridurre al minimo la possibilità di un denial of service, la verifica del ticket dovrebbe essere leggera (ad esempio, usando algoritmi crittografici a chiave simmetrica efficienti).

5.5. Gestione delle chiavi di protezione del ticket

Una descrizione completa della gestione delle chiavi usate per proteggere il ticket esula dallo scopo del presente documento. Di seguito è fornito un elenco di pratiche RACCOMANDATE (RECOMMENDED).

• Le chiavi dovrebbero essere generate in modo sicuro seguendo le raccomandazioni sulla casualità di [RFC4086].

• Le chiavi e gli algoritmi di protezione crittografica dovrebbero avere una forza di almeno 128 bit. Alcune suite di cifratura e applicazioni possono richiedere una protezione crittografica superiore a 128 bit di forza.

• Le chiavi non dovrebbero essere usate per scopi diversi dalla generazione e dalla verifica dei ticket.

• Le chiavi dovrebbero essere cambiate regolarmente.

• Le chiavi dovrebbero essere cambiate se il formato del ticket o gli algoritmi di protezione crittografica cambiano.

5.6. Durata del ticket

Il server TLS controlla la durata del ticket. I server determinano la durata accettabile in base ai requisiti operativi e di sicurezza degli ambienti in cui sono distribuiti. La durata del ticket può essere superiore alla durata di 24 ore raccomandata in [RFC4346]. Ai client TLS può essere fornito un suggerimento sulla durata del ticket. Poiché la durata di un ticket può essere non specificata, il client ha una propria politica locale che determina quando scarta i ticket.

5.7. Formati di ticket alternativi e schemi di distribuzione

Se il formato del ticket o lo schema di distribuzione definiti nel presente documento non vengono usati, è necessario prestare grande attenzione nell'analisi della sicurezza della soluzione. In particolare, se informazioni riservate, come una chiave segreta, vengono trasferite al client, ciò DEVE (MUST) essere fatto usando una comunicazione sicura, in modo da impedire agli attaccanti di ottenere o modificare la chiave. Inoltre, l'integrità e la riservatezza del ticket DEVONO (MUST) essere protette con tecniche crittografiche forti, per prevenire una violazione della sicurezza del sistema.

5.8. Privacy dell'identità, anonimato e non collegabilità

Il presente documento impone che il contenuto del ticket sia protetto nella riservatezza, al fine di evitare la fuga del suo contenuto, come informazioni relative all'utente. In quanto tale, impedisce la divulgazione di informazioni potenzialmente sensibili trasportate all'interno del ticket.

Lo scambio di handshake iniziale, usato per ottenere il ticket, potrebbe non fornire la riservatezza dell'identità del client in base alle proprietà di TLS. Un'altra minaccia rilevante per la sicurezza è la capacità di un avversario on-path di osservare più handshake TLS in cui viene usato lo stesso ticket, concludendo quindi che appartengono agli stessi endpoint di comunicazione. I progettisti di applicazioni che usano il meccanismo del ticket descritto nel presente documento dovrebbero considerare che la non collegabilità (unlinkability) [ANON] non è necessariamente fornita.

Sebbene una discussione completa di questi argomenti esuli dallo scopo del presente documento, va notato che è possibile emettere un ticket usando un handshake di rinegoziazione TLS che avviene dopo che è stato stabilito un tunnel sicuro da un handshake precedente. Ciò può aiutare a risolvere alcuni problemi di privacy e di non collegabilità in alcuni ambienti.