3. Raccomandazioni generali

Questa sezione fornisce raccomandazioni generali sull'uso sicuro di TLS. Le raccomandazioni relative alle suite di cifratura sono discusse nella sezione successiva.

3.1. Versioni del protocollo

3.1.1. Versioni del protocollo SSL/TLS

È importante sia smettere di usare vecchie versioni meno sicure di SSL/TLS sia iniziare a usare versioni moderne e più sicure; pertanto, le seguenti sono le raccomandazioni riguardanti le versioni del protocollo TLS/SSL:

• Le implementazioni NON DEVONO negoziare SSL versione 2.

  Motivazione: Oggi, SSLv2 è considerato insicuro [RFC6176].

• Le implementazioni NON DEVONO negoziare SSL versione 3.

  Motivazione: SSLv3 [RFC6101] era un miglioramento rispetto a SSLv2 e chiudeva alcune importanti falle di sicurezza, ma non supportava suite di cifratura forti. SSLv3 non supporta le estensioni TLS, alcune delle quali (ad esempio, renegotiation_info [RFC5746]) sono critiche per la sicurezza. Inoltre, con l'emergere dell'attacco Padding Oracle On Downgraded Legacy Encryption (POODLE) [POODLE], SSLv3 è ora ampiamente riconosciuto come fondamentalmente insicuro. Vedi [RFC7568] per ulteriori dettagli.

• Le implementazioni NON DEVONO negoziare TLS versione 1.0 [RFC2246].

  Motivazione: TLS 1.0 (pubblicato nel 1999) non supporta molte moderne suite di cifratura forti. Inoltre, a TLS 1.0 manca un vettore di inizializzazione (IV) per record per le suite di cifratura basate su Cipher Block Chaining (CBC) e non avverte contro i comuni errori di padding. Questa e altre raccomandazioni in questa sezione sono allineate con [RFC8996].

• Le implementazioni NON DEVONO negoziare TLS versione 1.1 [RFC4346].

  Motivazione: TLS 1.1 (pubblicato nel 2006) è un miglioramento della sicurezza rispetto a TLS 1.0 ma non supporta ancora alcune suite di cifratura più forti che sono state introdotte con la standardizzazione di TLS 1.2 nel 2008, comprese le suite di cifratura raccomandate per TLS 1.2 da questo documento (vedi Sezione 4.2 sotto).

• Le implementazioni DEVONO supportare TLS 1.2 [RFC5246].

  Motivazione: TLS 1.2 è implementato e distribuito più ampiamente di TLS 1.3 in questo momento, e quando le raccomandazioni di questo documento vengono seguite per mitigare gli attacchi noti, l'uso di TLS 1.2 è sicuro quanto l'uso di TLS 1.3. Per la maggior parte dei protocolli applicativi che riutilizzano TLS e DTLS, non c'è un bisogno immediato di migrare esclusivamente a TLS 1.3. Infatti, poiché molti client applicativi dipendono da librerie TLS o sistemi operativi che non supportano ancora TLS 1.3, deprecare proattivamente TLS 1.2 introdurrebbe significativi problemi di interoperabilità, danneggiando così la sicurezza più di quanto non l'aiuterebbe. Tuttavia, si prevede che una futura versione di questo BCP deprecherà l'uso di TLS 1.2 quando sarà appropriato.

• Le implementazioni DOVREBBERO supportare TLS 1.3 [RFC8446] e, se implementato, DEVONO preferire negoziare TLS 1.3 rispetto alle versioni precedenti di TLS.

  Motivazione: TLS 1.3 è una revisione importante del protocollo e risolve molti dei problemi di sicurezza con TLS 1.2. Nella misura in cui un'implementazione supporta TLS 1.2 (anche se di default usa TLS 1.3), DEVE seguire le raccomandazioni riguardanti TLS 1.2 specificate in questo documento.

• I nuovi protocolli di trasporto che integrano il protocollo di handshake TLS/DTLS e/o il livello record DEVONO usare solo TLS/DTLS 1.3 (per esempio, QUIC [RFC9001] ha adottato questo approccio). I nuovi protocolli applicativi che impiegano TLS/DTLS per la cifratura del canale o della sessione DEVONO integrarsi con entrambe le versioni 1.2 e 1.3 di TLS/DTLS; tuttavia, nel raro caso in cui un'ampia interoperabilità non sia una preoccupazione, i progettisti di protocolli applicativi POSSONO scegliere di rinunciare a TLS 1.2.

  Motivazione: La distribuzione sicura di TLS 1.3 è significativamente più facile e meno soggetta a errori rispetto alla distribuzione sicura di TLS 1.2. Quando si progetta un nuovo protocollo di trasporto sicuro come QUIC, non c'è motivo di supportare TLS 1.2. Al contrario, i nuovi protocolli applicativi che riutilizzano TLS devono supportare sia TLS 1.3 che TLS 1.2 al fine di sfruttare il supporto delle librerie sottostanti o del sistema operativo per entrambe le versioni.

Questo BCP si applica a TLS 1.3, TLS 1.2 e versioni precedenti. Non è sicuro per i lettori presumere che le raccomandazioni in questo BCP si applichino a qualsiasi versione futura di TLS.

3.1.2. Versioni del protocollo DTLS

DTLS, un adattamento di TLS per i datagrammi UDP, è stato introdotto al momento del rilascio di TLS 1.1. Le seguenti raccomandazioni si applicano a DTLS:

• Le implementazioni NON DEVONO negoziare DTLS versione 1.0 [RFC4347].

  La versione 1.0 di DTLS corrisponde alla versione 1.1 di TLS (vedi sopra).

• Le implementazioni DEVONO supportare DTLS 1.2 [RFC6347].

  La versione 1.2 di DTLS corrisponde alla versione 1.2 di TLS (vedi sopra). (Non esiste una versione 1.1 di DTLS.)

• Le implementazioni DOVREBBERO supportare DTLS 1.3 [RFC9147] e, se implementato, DEVONO preferire negoziare DTLS versione 1.3 rispetto alle versioni precedenti di DTLS.

  La versione 1.3 di DTLS corrisponde alla versione 1.3 di TLS (vedi sopra).

3.1.3. Fallback a versioni inferiori

I client TLS/DTLS 1.2 NON DEVONO ricorrere a versioni precedenti di TLS, poiché tali versioni sono state deprecate [RFC8996]. Di conseguenza, il meccanismo di valore della suite di cifratura di segnalazione (SCSV) per la protezione dal downgrade [RFC7507] non è più necessario per i client. Inoltre, TLS 1.3 implementa un nuovo meccanismo di negoziazione della versione.

3.2. Strict TLS

Le seguenti raccomandazioni sono fornite per aiutare a prevenire "SSL Stripping" e l'iniezione del comando STARTTLS (attacchi riassunti in [RFC7457]):

• Molti protocolli applicativi esistenti sono stati progettati prima che l'uso di TLS diventasse comune. Questi protocolli supportano tipicamente TLS in uno dei due modi: o tramite una porta separata per la sola comunicazione TLS (es. porta 443 per HTTPS) o tramite un metodo per aggiornare dinamicamente un canale non cifrato a un canale protetto da TLS (es. STARTTLS, che viene utilizzato in protocolli come IMAP e XMPP). Indipendentemente dal meccanismo di protezione del canale di comunicazione (solo porta TLS o aggiornamento dinamico), ciò che conta è lo stato risultante del canale. Quando un protocollo definisce sia un metodo di aggiornamento dinamico che un metodo separato solo TLS, allora il metodo separato solo TLS DEVE essere supportato dalle implementazioni e DEVE essere configurato dagli amministratori per essere utilizzato preferibilmente rispetto al metodo di aggiornamento dinamico. Quando un protocollo supporta solo un metodo di aggiornamento dinamico, le implementazioni DEVONO fornire un modo agli amministratori di impostare una politica locale rigorosa che proibisca l'uso del testo in chiaro in assenza di un canale TLS negoziato, e gli amministratori DEVONO usare questa politica.

• Le implementazioni di client e server HTTP destinate all'uso sul World Wide Web (vedi Sezione 5) DEVONO supportare il campo di intestazione HTTP Strict Transport Security (HSTS) [RFC6797] in modo che i server web possano annunciare di essere disposti ad accettare client solo TLS. I server web DOVREBBERO usare HSTS per indicare la loro disponibilità ad accettare client solo TLS, a meno che non siano distribuiti in modo tale che l'uso di HSTS indebolirebbe effettivamente la sicurezza complessiva (es. potrebbe essere problematico usare HSTS con certificati autofirmati, come descritto nella Sezione 11.3 di [RFC6797]). Esistono tecnologie simili per protocolli applicativi non HTTP, come Mail Transfer Agent Strict Transport Security (MTA-STS) per gli agenti di trasferimento di posta [RFC8461] e metodi basati su DNS-Based Authentication of Named Entities (DANE) [RFC6698] per SMTP [RFC7672] e XMPP [RFC7712].

Motivazione: La combinazione di comunicazione non protetta e protetta da TLS apre la strada allo SSL Stripping e ad attacchi simili, poiché una parte iniziale della comunicazione non è protetta nell'integrità e può quindi essere manipolata da un attaccante il cui obiettivo è mantenere la comunicazione in chiaro.

3.3. Compressione

Al fine di aiutare a prevenire attacchi legati alla compressione (riassunti nella Sezione 2.6 di [RFC7457]) quando si usa TLS 1.2, le implementazioni e le distribuzioni NON DOVREBBERO supportare la compressione a livello TLS (Sezione 6.2.2 di [RFC5246]); l'unica eccezione è quando il protocollo applicativo in questione ha dimostrato di non essere aperto a tali attacchi. Tuttavia, anche in questo caso, è necessaria estrema cautela a causa del potenziale per futuri attacchi legati alla compressione TLS. Più specificamente, il protocollo HTTP è noto per essere vulnerabile agli attacchi legati alla compressione. (Questa raccomandazione si applica solo a TLS 1.2, poiché la compressione è stata rimossa da TLS 1.3.)

Motivazione: La compressione TLS è stata oggetto di attacchi di sicurezza come l'attacco Compression Ratio Info-leak Made Easy (CRIME).

Gli implementatori dovrebbero notare che la compressione a livelli di protocollo più alti può consentire a un attaccante attivo di estrarre informazioni in chiaro dalla connessione. L'attacco Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) ne è un esempio. Questi problemi possono essere mitigati solo al di fuori di TLS e sono quindi al di fuori dell'ambito di questo documento. Vedi la Sezione 2.6 di [RFC7457] per ulteriori dettagli.

3.3.1. Compressione del certificato

Le catene di certificati spesso occupano la maggior parte dei byte trasmessi durante l'handshake. Per gestire le loro dimensioni, è possibile impiegare alcuni o tutti i seguenti metodi (vedi anche la Sezione 4 di [RFC9191] per ulteriori suggerimenti):

• Limitare il numero di nomi o estensioni.

• Utilizzare chiavi con piccole rappresentazioni di chiave pubblica, come l'Elliptic Curve Digital Signature Algorithm (ECDSA).

• Utilizzare la compressione del certificato.

Per realizzare quest'ultima, TLS 1.3 definisce l'estensione compress_certificate in [RFC8879]. Vedi anche la Sezione 5 di [RFC8879] per considerazioni sulla sicurezza e sulla privacy associate al suo utilizzo. Per evitare dubbi, gli attacchi in stile CRIME alla compressione TLS non si applicano alla compressione del certificato.

A causa dell'alta probabilità di interferenza da parte di middlebox, la compressione nello stile di [RFC8879] non è stata resa disponibile in TLS 1.2. In teoria, l'estensione cached_info definita in [RFC7924] potrebbe essere utilizzata, ma non è supportata abbastanza ampiamente da essere considerata un'alternativa pratica.

3.4. Ripresa della sessione TLS

La ripresa della sessione riduce significativamente il numero di handshake completi TLS ed è quindi una caratteristica prestazionale essenziale per la maggior parte delle distribuzioni.

La ripresa della sessione stateless con ticket di sessione è una strategia popolare. Per TLS 1.2, è specificata in [RFC5077]. Per TLS 1.3, un meccanismo più sicuro basato sull'uso di una Pre-Shared Key (PSK) è descritto nella Sezione 4.6.1 di [RFC8446]. Vedi [Springall16] per uno studio quantitativo dei rischi indotti dalle "scorciatoie" crittografiche TLS, inclusa la ripresa della sessione.

Quando utilizzate, le informazioni di ripresa DEVONO essere autenticate e cifrate per prevenire modifiche o intercettazioni da parte di un attaccante. Ulteriori raccomandazioni si applicano ai ticket di sessione:

• Una cifratura forte DEVE essere utilizzata durante la cifratura del ticket (almeno forte quanto la suite di cifratura TLS principale).

• Le chiavi di cifratura dei ticket DEVONO essere cambiate regolarmente, ad esempio una volta alla settimana, in modo da non annullare i benefici della robustezza in avanti (forward secrecy - vedi Sezione 7.3 per i dettagli sulla forward secrecy). Le vecchie chiavi di cifratura dei ticket DEVONO essere distrutte alla fine del periodo di validità.

• Per motivi simili, la validità del ticket di sessione DEVE essere limitata a una durata ragionevole (ad esempio, metà della validità della chiave di cifratura del ticket).

• TLS 1.2 non fa ruotare la chiave di sessione all'interno di una singola sessione. Pertanto, per prevenire un attacco in cui la chiave di cifratura del ticket del server viene rubata e utilizzata per decifrare l'intero contenuto di una sessione (annullando il concetto di forward secrecy), un server TLS 1.2 NON DOVREBBE riprendere sessioni troppo vecchie, ad esempio sessioni che sono aperte da più di due periodi di rotazione della chiave di cifratura del ticket.

Motivazione: La ripresa della sessione è un altro tipo di handshake TLS e deve quindi essere sicura quanto l'handshake iniziale. Questo documento (Sezione 4) raccomanda l'uso di suite di cifratura che forniscono forward secrecy, cioè che impediscono a un attaccante che ottiene l'accesso momentaneo all'endpoint TLS (client o server) e ai suoi segreti di leggere le comunicazioni passate o future. I ticket devono essere gestiti in modo da non annullare questa proprietà di sicurezza.

TLS 1.3 offre la potente opzione di forward secrecy anche all'interno di una connessione di lunga durata che viene periodicamente ripresa. La Sezione 2.2 di [RFC8446] raccomanda che i client DOVREBBERO inviare un "key_share" quando iniziano la ripresa della sessione. Per ottenere la forward secrecy, questo documento raccomanda che le implementazioni dei server DOVREBBERO selezionare la modalità di scambio chiavi PSK "psk_dhe_ke" e rispondere con un "key_share" per eseguire uno scambio Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) su ogni ripresa della sessione. Come alternativa più performante, le implementazioni dei server POSSONO astenersi dal rispondere con un "key_share" fino a quando non è trascorso un certo tempo (ad esempio, misurato in ore) dall'ultimo scambio ECDHE; questo implica che l'operazione "key_share" non avverrebbe per la presunta maggioranza delle richieste di ripresa della sessione (che avverrebbero entro poche ore) garantendo comunque la forward secrecy per le sessioni di durata più lunga.

La ripresa della sessione TLS introduce potenziali problemi di privacy in cui il server è in grado di tracciare il client, in alcuni casi a tempo indeterminato. Vedi [Sy2018] per ulteriori dettagli.

3.5. Rinegoziazione in TLS 1.2

Le raccomandazioni in questa sezione si applicano solo a TLS 1.2, poiché la rinegoziazione è stata rimossa da TLS 1.3.

La rinegoziazione in TLS 1.2 è un handshake che stabilisce nuovi parametri crittografici per una sessione esistente. Il meccanismo esisteva in TLS 1.2 e nelle versioni precedenti del protocollo ed è stato migliorato a seguito di numerosi attacchi importanti, incluso un attacco di iniezione di testo in chiaro, CVE-2009-3555 [CVE].

Client e server TLS 1.2 DEVONO implementare l'estensione renegotiation_info, come definito in [RFC5746].

I client TLS 1.2 DEVONO inviare renegotiation_info nel Client Hello. Se il server non riconosce l'estensione, il client DEVE generare un avviso fatale handshake_failure prima di terminare la connessione.

Motivazione: Non è sicuro per un client connettersi a un server TLS 1.2 che non supporta renegotiation_info, indipendentemente dal fatto che entrambi gli endpoint implementino effettivamente la rinegoziazione. Vedi anche la Sezione 4.1 di [RFC5746].

Un attacco correlato derivante da parametri di sessione TLS autenticati in modo inadeguato è un Triple Handshake [Triple-Handshake]. Per contrastare questo attacco, le implementazioni TLS 1.2 DEVONO supportare l'estensione extended_master_secret definita in [RFC7627].

3.6. Autenticazione Post-Handshake

La rinegoziazione in TLS 1.2 è stata sostituita (parzialmente) in TLS 1.3 da meccanismi separati di autenticazione post-handshake e aggiornamento delle chiavi. Nel contesto di protocolli che multiplexano le richieste su una singola connessione (come HTTP/2 [RFC9113]), l'autenticazione post-handshake presenta gli stessi problemi della rinegoziazione TLS 1.2. I protocolli multiplexati DOVREBBERO seguire le indicazioni fornite per HTTP/2 nella Sezione 9.2.3 di [RFC9113].

3.7. Server Name Indication (SNI)

Le implementazioni TLS DEVONO supportare l'estensione Server Name Indication (SNI) definita nella Sezione 3 di [RFC6066] per i protocolli di livello superiore che ne trarrebbero beneficio, incluso HTTPS. Tuttavia, l'uso effettivo di SNI in circostanze particolari è una questione di politica locale. Al momento della stesura, una tecnologia per cifrare l'SNI (denominata Encrypted Client Hello) è in fase di elaborazione all'interno del gruppo di lavoro TLS [TLS-ECH]. Una volta che questo metodo sarà standardizzato e implementato ampiamente, sarà probabilmente appropriato raccomandarne l'uso in una futura versione di questo BCP.

Motivazione: SNI supporta la distribuzione di più server virtuali protetti da TLS su un singolo indirizzo, e quindi abilita una sicurezza a grana fine per questi server virtuali, consentendo a ciascuno di avere il proprio certificato. Tuttavia, SNI fa trapelare anche il dominio di destinazione per una data connessione; questa perdita di informazioni sarà chiusa dall'uso di TLS Encrypted Client Hello una volta che tale metodo sarà standardizzato.

Al fine di prevenire gli attacchi descritti in [ALPACA], un server che non riconosce il nome del server presentato NON DOVREBBE riprendere l'handshake e DOVREBBE invece fallire con un avviso fatale unrecognized_name(112). Si noti che questa raccomandazione aggiorna la Sezione 3 di [RFC6066], che affermava:

| Se il server ha compreso l'estensione ClientHello ma non riconosce il nome del server, il server DOVREBBE intraprendere una delle due azioni: o interrompere l'handshake inviando un avviso fatale unrecognized_name(112) o continuare l'handshake.

I client DOVREBBERO interrompere l'handshake se il server riconosce l'estensione SNI ma presenta un certificato con un nome host diverso da quello inviato dal client.

3.8. Application-Layer Protocol Negotiation (ALPN)

Le implementazioni TLS (sia lato client che lato server) DEVONO supportare l'estensione Application-Layer Protocol Negotiation (ALPN) [RFC7301].

Al fine di prevenire attacchi cross-protocol derivanti dal mancato controllo che un messaggio destinato all'uso in un protocollo non possa essere confuso con un messaggio destinato all'uso in un altro protocollo, si consiglia ai server di applicare rigorosamente il comportamento prescritto nella Sezione 3.2 di [RFC7301]:

| Nel caso in cui il server non supporti nessuno dei protocolli pubblicizzati dal client, il server DEVE rispondere con un avviso fatale 'no_application_protocol'.

I client DOVREBBERO interrompere l'handshake se il server riconosce l'estensione ALPN ma non seleziona un protocollo dalla lista del client. Non farlo potrebbe portare ad attacchi come quelli descritti in [ALPACA].

Gli sviluppatori di protocolli sono fortemente incoraggiati a registrare un identificatore ALPN per i loro protocolli. Questo si applica ai nuovi protocolli così come ai protocolli consolidati; tuttavia, poiché questi ultimi potrebbero avere una grande base installata, l'applicazione rigorosa dell'uso di ALPN potrebbe non essere fattibile quando un identificatore ALPN viene registrato per un protocollo consolidato.

3.9. Distribuzione multi-server

Le distribuzioni che coinvolgono più server o servizi possono aumentare la dimensione della superficie di attacco per TLS. Due scenari sono di interesse:

1. Distribuzioni in cui più servizi gestiscono lo stesso nome di dominio tramite protocolli diversi (ad esempio, HTTP e IMAP). In questo caso, un attaccante potrebbe essere in grado di dirigere un endpoint di connessione al servizio che offre un protocollo diverso e montare un attacco cross-protocol. In un attacco cross-protocol, il client e il server credono di utilizzare protocolli diversi, cosa che l'attaccante potrebbe sfruttare se i messaggi inviati in un protocollo vengono interpretati come messaggi nell'altro protocollo con effetti indesiderati (vedi [ALPACA] per informazioni più dettagliate su questa classe di attacchi). Per mitigare questa minaccia, i fornitori di servizi DOVREBBERO distribuire ALPN (vedi Sezione 3.8). Inoltre, ove possibile, DOVREBBERO garantire che più servizi che gestiscono lo stesso nome di dominio offrano livelli di sicurezza equivalenti, coerenti con le raccomandazioni in questo documento; tali misure DOVREBBERO includere la gestione delle configurazioni su più server TLS e protezioni contro la compromissione delle credenziali detenute da questi server.

2. Distribuzioni in cui più server che forniscono lo stesso servizio hanno configurazioni TLS diverse. In questo caso, un attaccante potrebbe essere in grado di dirigere un endpoint di connessione a un server con una configurazione TLS più facilmente sfruttabile (vedi [DROWN] per informazioni più dettagliate su questa classe di attacchi). Per mitigare questa minaccia, i fornitori di servizi DOVREBBERO garantire che tutti i server che forniscono lo stesso servizio offrano livelli di sicurezza equivalenti, coerenti con le raccomandazioni in questo documento.

3.10. Dati Zero Round-Trip Time (0-RTT) in TLS 1.3

La funzione 0-RTT early data è nuova in TLS 1.3. Offre una latenza ridotta alla ripresa delle connessioni TLS, al costo potenziale di alcune proprietà di sicurezza. Pertanto, richiede particolare attenzione da parte degli implementatori sia lato server che lato client. In generale, questo si estende alla libreria TLS così come ai livelli di protocollo sopra di essa.

Per HTTP su TLS, fare riferimento a [RFC8470] per indicazioni.

Per QUIC su TLS, fare riferimento alla Sezione 9.2 di [RFC9001].

Per altri protocolli, indicazioni generiche sono fornite nella Sezione 8 e nell'Appendice E.5 di [RFC8446]. Per parafrasare l'Appendice E.5, le applicazioni DEVONO evitare questa funzione a meno che non esista una specifica esplicita per il protocollo applicativo in questione per chiarire quando 0-RTT è appropriato e sicuro. Questo può assumere la forma di una RFC IETF, uno standard non IETF o documentazione associata a un protocollo non standard.