2. Protocol Overview (Panoramica del protocollo)
I parametri crittografici utilizzati dal canale sicuro sono prodotti dal protocollo TLS Handshake (Protocollo di handshake). Questo sottoprotocollo di TLS viene utilizzato quando il client e il server comunicano per la prima volta. Il protocollo di handshake consente ai peer di negoziare una versione del protocollo, selezionare algoritmi crittografici, autenticarsi reciprocamente in modo opzionale e stabilire il materiale di chiave segreta condiviso. Una volta completato l'handshake, i peer utilizzano le chiavi stabilite per proteggere il traffico a livello applicativo.
Un fallimento dell'handshake o un altro errore di protocollo attiva la terminazione della connessione, eventualmente preceduta da un Alert Message (messaggio di avviso) (Sezione 6).
TLS supporta tre modalità di scambio chiavi di base (Key Exchange Modes):
- (EC)DHE (Diffie-Hellman su campi finiti o curve ellittiche)
- PSK-only (solo chiave pre-condivisa)
- PSK with (EC)DHE (chiave pre-condivisa con (EC)DHE)
La Figura 1 di seguito mostra l'handshake TLS completo di base:
Client Server
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* -------->
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
+ Indica estensioni degne di nota inviate nel
messaggio precedentemente menzionato.
* Indica messaggi/estensioni opzionali o dipendenti
dalla situazione che non sono sempre inviati.
{} Indica messaggi protetti utilizzando chiavi
derivate da un [sender]_handshake_traffic_secret.
[] Indica messaggi protetti utilizzando chiavi
derivate da [sender]_application_traffic_secret_N.
Figura 1: Flusso di messaggi per l'handshake TLS completo
L'handshake può essere considerato come avente tre fasi (indicate nel diagramma sopra):
-
Key Exchange (Scambio chiavi): Stabilire il materiale di chiave condiviso e selezionare i parametri crittografici. Tutto dopo questa fase è crittografato.
-
Server Parameters (Parametri del server): Stabilire altri parametri dell'handshake (se il client è autenticato, supporto del protocollo a livello applicativo, ecc.).
-
Authentication (Autenticazione): Autenticare il server (e opzionalmente il client) e fornire conferma della chiave e integrità dell'handshake.
Nella fase Key Exchange, il client invia il messaggio ClientHello (Sezione 4.1.2), che contiene un nonce casuale (ClientHello.random); le sue versioni di protocollo offerte; un elenco di coppie cipher/hash HKDF simmetriche; un set di condivisioni di chiavi Diffie-Hellman (nell'estensione "key_share" (Sezione 4.2.8)), un set di etichette di chiavi pre-condivise (nell'estensione "pre_shared_key" (Sezione 4.2.11)), o entrambi; e potenzialmente estensioni aggiuntive. Possono essere presenti anche campi e/o messaggi aggiuntivi per la compatibilità con i middlebox.
Il server elabora il ClientHello e determina i parametri crittografici appropriati per la connessione. Quindi risponde con il proprio ServerHello (Sezione 4.1.3), che indica i parametri di connessione negoziati. La combinazione del ClientHello e del ServerHello determina le chiavi condivise. Se viene utilizzato lo stabilimento di chiavi (EC)DHE, allora il ServerHello contiene un'estensione "key_share" con la condivisione Diffie-Hellman effimera del server; la condivisione del server DEVE essere nello stesso gruppo di una delle condivisioni del client. Se viene utilizzato lo stabilimento di chiavi PSK, allora il ServerHello contiene un'estensione "pre_shared_key" che indica quale dei PSK offerti dal client è stato selezionato. Si noti che le implementazioni possono utilizzare insieme (EC)DHE e PSK, nel qual caso saranno fornite entrambe le estensioni.
Il server invia quindi due messaggi per stabilire i Server Parameters:
EncryptedExtensions: Risposte alle estensioni ClientHello che non sono necessarie per determinare i parametri crittografici, diverse da quelle specifiche per i singoli certificati. [Sezione 4.3.1]
CertificateRequest: Se è desiderata l'autenticazione client basata su certificato, i parametri desiderati per quel certificato. Questo messaggio viene omesso se l'autenticazione client non è desiderata. [Sezione 4.3.2]
Infine, il client e il server scambiano messaggi di Authentication. TLS utilizza lo stesso set di messaggi ogni volta che è necessaria l'autenticazione basata su certificato. (L'autenticazione basata su PSK avviene come effetto collaterale dello scambio di chiavi.) In particolare:
Certificate: Il certificato dell'endpoint e qualsiasi estensione per certificato. Questo messaggio viene omesso dal server se non si autentica con un certificato e dal client se il server non ha inviato CertificateRequest (indicando quindi che il client non dovrebbe autenticarsi con un certificato). Si noti che se vengono utilizzate chiavi pubbliche raw [RFC7250] o l'estensione cached information [RFC7924], allora questo messaggio non conterrà un certificato ma piuttosto un altro valore corrispondente alla chiave a lungo termine del server. [Sezione 4.4.2]
CertificateVerify: Una firma sull'intero handshake utilizzando la chiave privata corrispondente alla chiave pubblica nel messaggio Certificate. Questo messaggio viene omesso se l'endpoint non si autentica tramite un certificato. [Sezione 4.4.3]
Finished: Un MAC (Message Authentication Code) sull'intero handshake. Questo messaggio fornisce conferma della chiave, vincola l'identità dell'endpoint alle chiavi scambiate e, in modalità PSK, autentica anche l'handshake. [Sezione 4.4.4]
Dopo aver ricevuto i messaggi del server, il client risponde con i suoi messaggi di autenticazione, ovvero Certificate e CertificateVerify (se richiesti) e Finished.
A questo punto, l'handshake è completato e il client e il server derivano il materiale di chiave richiesto dal livello dei record per scambiare dati a livello applicativo protetti tramite crittografia autenticata. I dati applicativi NON DEVONO essere inviati prima dell'invio del messaggio Finished, tranne come specificato nella Sezione 2.3. Si noti che sebbene il server possa inviare dati applicativi prima di ricevere i messaggi di autenticazione del client, tutti i dati inviati in quel momento sono, ovviamente, inviati a un peer non autenticato.
2.1 Incorrect DHE Share (Condivisione DHE errata)
Se il client non ha fornito un'estensione "key_share" sufficiente (ad esempio, include solo gruppi DHE o ECDHE non accettabili o non supportati dal server), il server corregge la mancata corrispondenza con un HelloRetryRequest e il client deve riavviare l'handshake con un'estensione "key_share" appropriata, come mostrato nella Figura 2. Se non è possibile negoziare parametri crittografici comuni, il server DEVE interrompere l'handshake con un avviso appropriato.
Client Server
ClientHello
+ key_share -------->
HelloRetryRequest
<-------- + key_share
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Figura 2: Flusso di messaggi per handshake completo con
parametri non corrispondenti
Nota: Il Handshake Transcript (trascrizione dell'handshake) include lo scambio iniziale ClientHello/HelloRetryRequest; non viene ripristinato con il nuovo ClientHello.
TLS consente anche diverse varianti ottimizzate dell'handshake di base, come descritto nelle sezioni seguenti.
2.2 Resumption and Pre-Shared Key (PSK) (Ripresa e chiave pre-condivisa)
Sebbene i PSK TLS possano essere stabiliti fuori banda, i PSK possono anche essere stabiliti in una connessione precedente e poi utilizzati per stabilire una nuova connessione ("Session Resumption (ripresa della sessione)" o "ripresa" utilizzando un PSK). Una volta completato un handshake, il server può inviare al client una PSK Identity (identità PSK) che corrisponde a una chiave unica derivata dall'handshake iniziale (vedere Sezione 4.6.1). Il client può quindi utilizzare quell'identità PSK in futuri handshake per negoziare l'uso del PSK associato. Se il server accetta il PSK, allora il contesto di sicurezza della nuova connessione è crittograficamente legato alla connessione originale e la chiave derivata dall'handshake iniziale viene utilizzata per avviare lo stato crittografico invece di un handshake completo. In TLS 1.2 e versioni precedenti, questa funzionalità era fornita da "Session IDs (ID di sessione)" e "Session Tickets (ticket di sessione)" [RFC5077]. Entrambi questi meccanismi sono obsoleti in TLS 1.3.
I PSK possono essere utilizzati con lo scambio di chiavi (EC)DHE per fornire Forward Secrecy in combinazione con chiavi condivise, o possono essere utilizzati da soli, al costo della perdita della Forward Secrecy per i dati applicativi.
La Figura 3 mostra una coppia di handshake in cui il primo stabilisce un PSK e il secondo lo utilizza:
Client Server
Initial Handshake:
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
<-------- [NewSessionTicket]
[Application Data] <-------> [Application Data]
Subsequent Handshake:
ClientHello
+ key_share*
+ pre_shared_key -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Figura 3: Flusso di messaggi per ripresa e PSK
Poiché il server si autentica tramite un PSK, non invia un messaggio Certificate o CertificateVerify. Quando un client offre la ripresa tramite un PSK, DOVREBBE anche fornire un'estensione "key_share" al server per consentire al server di rifiutare la ripresa e tornare a un handshake completo, se necessario. Il server risponde con un'estensione "pre_shared_key" per negoziare l'uso dello stabilimento di chiavi PSK e può (come mostrato qui) rispondere con un'estensione "key_share" per eseguire lo stabilimento di chiavi (EC)DHE, fornendo così Forward Secrecy.
Quando i PSK sono provvisionati fuori banda, l'identità PSK e l'algoritmo hash KDF da utilizzare con il PSK DEVONO essere provvisionati anch'essi.
Nota: Quando si utilizza un segreto pre-condiviso provvisionato fuori banda, una considerazione critica è l'utilizzo di entropia sufficiente durante la generazione delle chiavi, come discusso in [RFC4086]. Derivare un segreto condiviso da una password o da altre fonti a bassa entropia non è sicuro. Un segreto o una password a bassa entropia è soggetto ad attacchi dizionario basati sul PSK Binder (legante PSK). L'autenticazione PSK specificata non è uno scambio di chiavi autenticato basato su password forte anche quando utilizzato con lo stabilimento di chiavi Diffie-Hellman. In particolare, non impedisce a un attaccante che può osservare l'handshake di eseguire un attacco di forza bruta sulla password/chiave pre-condivisa.
2.3 0-RTT Data (Dati 0-RTT)
Quando i client e i server condividono un PSK (ottenuto esternamente o tramite un handshake precedente), TLS 1.3 consente ai client di inviare dati alla prima trasmissione ("Early Data (dati anticipati)"). Il client utilizza il PSK per autenticare il server e crittografare i dati anticipati.
Come mostrato nella Figura 4, i dati 0-RTT vengono semplicemente aggiunti all'handshake 1-RTT alla prima trasmissione. Il resto dell'handshake utilizza gli stessi messaggi di un handshake 1-RTT con ripresa PSK.
Client Server
ClientHello
+ early_data
+ key_share*
+ psk_key_exchange_modes
+ pre_shared_key
(Application Data*) -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
+ early_data*
{Finished}
<-------- [Application Data*]
(EndOfEarlyData)
{Finished} -------->
[Application Data] <-------> [Application Data]
+ Indica estensioni degne di nota inviate nel
messaggio precedentemente menzionato.
* Indica messaggi/estensioni opzionali o dipendenti
dalla situazione che non sono sempre inviati.
() Indica messaggi protetti utilizzando chiavi
derivate da un client_early_traffic_secret.
{} Indica messaggi protetti utilizzando chiavi
derivate da un [sender]_handshake_traffic_secret.
[] Indica messaggi protetti utilizzando chiavi
derivate da [sender]_application_traffic_secret_N.
Figura 4: Flusso di messaggi per un handshake 0-RTT
NOTA IMPORTANTE: Le proprietà di sicurezza dei dati 0-RTT sono più deboli di quelle degli altri tipi di dati TLS. Specificamente:
-
Questi dati non sono Forward Secret (segreti in avanti), poiché sono crittografati esclusivamente sotto chiavi derivate dal PSK offerto.
-
Non ci sono garanzie di Non-Replay (non ripetizione) tra le connessioni. La protezione contro il replay per i dati TLS 1.3 1-RTT ordinari è fornita tramite il valore Random del server, ma i dati 0-RTT non dipendono dal ServerHello e quindi hanno garanzie più deboli. Questo è particolarmente rilevante se i dati sono autenticati con l'autenticazione client TLS o all'interno del protocollo applicativo. Gli stessi avvertimenti si applicano a qualsiasi uso dell'early_exporter_master_secret.
I dati 0-RTT non possono essere duplicati all'interno di una connessione (ovvero, il server non elaborerà gli stessi dati due volte per la stessa connessione), e un attaccante non sarà in grado di far apparire i dati 0-RTT come dati 1-RTT (perché sono protetti con chiavi diverse). L'Appendice E.5 contiene una descrizione degli attacchi potenziali, e la Sezione 8 descrive i meccanismi che il server può utilizzare per limitare l'impatto del replay.