Passa al contenuto principale

2. Convenzioni di notazione (Notational Conventions)

Le parole chiave "MUST (DEVE)", "MUST NOT (NON DEVE)", "REQUIRED (RICHIESTO)", "SHALL (DEVE)", "SHALL NOT (NON DEVE)", "SHOULD (DOVREBBE)", "SHOULD NOT (NON DOVREBBE)", "RECOMMENDED (RACCOMANDATO)", "NOT RECOMMENDED (NON RACCOMANDATO)", "MAY (PUÒ)" e "OPTIONAL (OPZIONALE)" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.

Questo documento utilizza la terminologia stabilita in [QUIC-TRANSPORT].

Per brevità, l'abbreviazione TLS viene utilizzata per riferirsi a TLS 1.3, sebbene possano essere utilizzate versioni più recenti di TLS; vedere la sezione 4.2.

2.1. Panoramica di TLS (TLS Overview)​

TLS fornisce un modo per due endpoint di stabilire un mezzo di comunicazione su un mezzo inaffidabile (come Internet). TLS consente l'autenticazione dei peer e fornisce protezione della riservatezza e dell'integrità per i messaggi scambiati tra gli endpoint.

Internamente, TLS è un protocollo a livelli, con una struttura illustrata nella Figura 1.

         +-------------+------------+--------------+---------+
Livello  |             |            |    Dati      |         |
di       | Handshake   |   Avviso   | applicazione |   ...   |
contenuto|             |            |              |         |
         +-------------+------------+--------------+---------+
Livello  |                                                   |
di       |                   Record                         |
record   |                                                   |
         +---------------------------------------------------+

Figura 1: Livelli TLS

Ogni messaggio del livello di contenuto (ad esempio, handshake, avviso e dati dell'applicazione) viene trasportato dal livello di record come una serie di record TLS tipizzati. I record sono protetti crittograficamente individualmente e poi trasmessi su un trasporto affidabile (tipicamente TCP) che fornisce ordinamento e garanzia di consegna.

L'handshake di scambio chiavi autenticato TLS avviene tra due endpoint: un client e un server. Il client avvia lo scambio e il server risponde. Se lo scambio di chiavi termina con successo, il client e il server concordano entrambi su un segreto. TLS supporta sia chiavi pre-condivise (PSK) che scambio di chiavi Diffie-Hellman basato su campi finiti o curve ellittiche ((EC)DHE). Le PSK sono la base per i dati precoci (0-RTT); questi ultimi forniscono segretezza in avanti (FS) quando le chiavi (EC)DHE vengono distrutte. Questi due modi possono anche essere combinati per fornire segretezza in avanti mentre si utilizza una PSK per l'autenticazione.

Dopo aver completato l'handshake TLS, il client avrà appreso e autenticato l'identità del server e il server può opzionalmente aver appreso e autenticato l'identità del client. TLS supporta l'autenticazione del server e del client basata su certificati X.509 [RFC5280]. Quando viene utilizzato uno scambio di chiavi PSK (come nella ripresa della sessione), la conoscenza della PSK viene utilizzata per autenticare il peer.

Lo scambio di chiavi TLS è resistente alla manomissione da parte di un attaccante e il segreto condiviso che produce non può essere controllato da alcun peer partecipante.

TLS fornisce due modalità di handshake di base che interessano QUIC:

  • Un handshake completo 1-RTT, in cui il client può inviare dati dell'applicazione dopo un round-trip e il server risponde immediatamente dopo aver ricevuto il primo messaggio di handshake del client.

  • Un handshake 0-RTT, in cui il client utilizza informazioni che ha precedentemente appreso sul server per inviare immediatamente dati dell'applicazione. Questi dati dell'applicazione possono essere riprodotti da un attaccante, quindi 0-RTT non è adatto per trasportare istruzioni che potrebbero innescare azioni la cui riproduzione potrebbe avere conseguenze indesiderate.

La Figura 2 mostra un handshake TLS semplificato con dati dell'applicazione 0-RTT.

Client                                             Server

ClientHello
(dati applicazione 0-RTT)  -------->
                                                     ServerHello
                                            {EncryptedExtensions}
                                                       {Finished}
                                    <--------   [dati applicazione]
{Finished}                -------->

[dati applicazione]       <------->   [dati applicazione]

() Indica messaggi protetti da chiavi dati precoci (0-RTT)
{} Indica messaggi protetti da chiavi handshake
[] Indica messaggi protetti da chiavi dati applicazione (1-RTT)

Figura 2: Handshake TLS con 0-RTT

La Figura 2 omette il messaggio EndOfEarlyData, che non viene utilizzato in QUIC; vedere la sezione 8.3. Allo stesso modo, QUIC non utilizza nemmeno i messaggi ChangeCipherSpec o KeyUpdate. ChangeCipherSpec è ridondante in TLS 1.3; vedere la sezione 8.4. QUIC ha il proprio meccanismo di aggiornamento delle chiavi; vedere la sezione 6.

I dati sono protetti utilizzando più livelli di crittografia:

  • Chiavi iniziali (Initial keys)
  • Chiavi dati precoci (0-RTT) (Early data (0-RTT) keys)
  • Chiavi handshake (Handshake keys)
  • Chiavi dati applicazione (1-RTT) (Application data (1-RTT) keys)

I dati dell'applicazione possono apparire solo ai livelli dati precoci e dati applicazione. I messaggi di handshake e avviso possono apparire a qualsiasi livello.

Un handshake 0-RTT può essere utilizzato se il client e il server hanno precedentemente comunicato. In un handshake 1-RTT, il client non può inviare dati dell'applicazione protetti fino a quando non ha ricevuto tutti i messaggi di handshake inviati dal server.

Ultimo aggiornamento il