11. Considerazioni sulla sicurezza

11.1. Considerazioni sulla sicurezza per server_name

Se un server implementa domini di sicurezza a livello di nome, DOVREBBE gestire correttamente i tentativi da parte dei client di risolvere nomi nel dominio di sicurezza sbagliato. Un avviso NON DOVREBBE essere utilizzato; un server DOVREBBE rifiutare la connessione con un avviso fatale appropriato, o procedere utilizzando il dominio di sicurezza che ha selezionato.

Si noti che i nomi dei server nelle estensioni server_name non sono autenticati dall'handshake TLS. Non c'è garanzia che il nome del server presentato dal client corrisponda al nome nel certificato del server, e non c'è autenticazione del nome stesso. Le applicazioni che si affidano all'autenticazione del server DEVONO eseguire le proprie verifiche di identità (come quelle descritte in [RFC6125]) utilizzando il nome presentato nel certificato del server.

Potrebbero esserci casi in cui un server ospita più domini e sarebbe inappropriato per un dominio apprendere che il client stava tentando di contattare un altro dominio. In tali casi, potrebbe essere preferibile per i server rispondere in modo identico indipendentemente dal nome del server; ad esempio, un server multi-dominio potrebbe restituire un certificato valido per tutti i domini che ospita, o potrebbe restituire lo stesso avviso in tutti i casi. Ciò impedisce a un osservatore di determinare quale dei domini del server un client stava tentando di contattare.

Esiste un rischio di denial of service se un server carica molti certificati diversi in base al nome del server dall'estensione server_name. Il server DOVREBBE implementare meccanismi per limitare il carico causato dall'elaborazione dell'estensione server_name, come la memorizzazione nella cache dei certificati o la limitazione del numero di certificati diversi che caricherà.

11.2. Considerazioni sulla sicurezza per max_fragment_length

La riduzione delle dimensioni massime dei frammenti può aumentare la vulnerabilità agli attacchi side-channel, poiché può rivelare informazioni sul pattern di traffico. Ad esempio, se un'applicazione invia una piccola quantità di dati sensibili, gli attaccanti potrebbero essere in grado di dedurre la quantità di dati semplicemente osservando il numero di frammenti.

Le implementazioni DOVREBBERO considerare i rischi dei canali laterali quando si negoziano dimensioni di frammento ridotte, specialmente per applicazioni che gestiscono dati sensibili.

La negoziazione di dimensioni di frammento più piccole può anche esporre le implementazioni ad attacchi di frammentazione in cui un attaccante tenta di sopraffare l'implementazione con molti piccoli frammenti. Le implementazioni DOVREBBERO avere limiti appropriati sul numero di frammenti che elaboreranno.

11.3. Considerazioni sulla sicurezza per client_certificate_url

Quando vengono utilizzati URL di certificati client, il server ottiene i certificati da una posizione di rete esterna. Ciò introduce diversi rischi di sicurezza:

Attacchi di spoofing degli URL: Un attaccante potrebbe fornire URL che puntano a certificati che controlla, consentendo potenzialmente l'autenticazione non autorizzata. I server DEVONO:

• Validare che il certificato ottenuto dall'URL sia firmato da una CA affidabile.
• Eseguire tutte le verifiche dei certificati standard richieste da [RFC5246].
• Validare che il client possieda la chiave privata corrispondente alla chiave pubblica del certificato (questo viene fatto durante l'handshake TLS).

Attacchi man-in-the-middle: Se un attaccante può intercettare o modificare la comunicazione tra il server e l'URL del certificato, potrebbe sostituire un certificato diverso. Per mitigare questo rischio:

• I server DOVREBBERO utilizzare HTTPS per ottenere certificati dagli URL.
• Quando viene fornito un hash del certificato, i server DEVONO verificare che l'hash del certificato ottenuto corrisponda all'hash fornito.

Attacchi denial-of-service: Un client malevolo potrebbe fornire URL che:

• Puntano a server che sono lenti a rispondere o non rispondono affatto.
• Puntano a risorse estremamente grandi.
• Sono progettati per causare un'elaborazione lato server eccessiva.

Per mitigare questi rischi, i server DOVREBBERO:

• Implementare timeout appropriati per il recupero degli URL.
• Limitare la dimensione massima dei certificati che recupereranno.
• Limitare il numero di tentativi di recupero che eseguiranno.
• Implementare la limitazione della velocità per le richieste di recupero dei certificati.

Preoccupazioni sulla privacy: L'utilizzo di URL di certificati rivela al server che ospita l'URL che il client sta tentando di autenticarsi con un particolare servizio. Ciò potrebbe consentire il tracciamento delle attività del client. I client DOVREBBERO considerare queste implicazioni sulla privacy quando utilizzano l'estensione client_certificate_url.

Esposizione delle informazioni del certificato: Se gli URL dei certificati sono accessibili pubblicamente senza autenticazione, ciò potrebbe esporre informazioni del certificato che dovrebbero essere private. I client DOVREBBERO considerare se i loro certificati contengono informazioni sensibili e scegliere meccanismi di hosting appropriati.

Attacchi di replay dell'hash: Se un server memorizza nella cache i certificati in base agli hash, un attaccante potrebbe potenzialmente riutilizzare un vecchio hash se il certificato memorizzato nella cache esiste ancora. Per mitigare:

• I server DOVREBBERO implementare politiche di scadenza della cache appropriate.
• I server DEVONO verificare che i certificati memorizzati nella cache siano ancora validi e non revocati.

11.4. Considerazioni sulla sicurezza per trusted_ca_keys

L'estensione trusted_ca_keys rivela al server quali autorità di certificazione sono affidabili dal client. Ciò potrebbe rivelare informazioni sull'ambiente di fiducia del client, che potrebbero essere utilizzate per il fingerprinting o la profilazione.

Inoltre, se un client fornisce un lungo elenco di CA affidabili, ciò potrebbe:

• Creare un rischio di denial of service causando un'elaborazione lato server eccessiva.
• Rivelare informazioni sui partner commerciali o le relazioni organizzative del client.

I client DOVREBBERO considerare attentamente se utilizzare questa estensione e, in caso affermativo, quali CA includere nell'elenco. I server DOVREBBERO implementare limiti appropriati sul numero di CA che elaboreranno.

11.5. Considerazioni sulla sicurezza per truncated_hmac

L'estensione truncated_hmac riduce la lunghezza del MAC da 160 bit (per SHA-1) a 80 bit. Ciò riduce significativamente la forza di sicurezza del MAC.

Un MAC di 80 bit offre circa 2^80 operazioni di resistenza contro attacchi brute-force, che è considerato marginalmente sicuro secondo gli standard moderni. Man mano che la potenza di calcolo aumenta, questo margine di sicurezza diminuisce.

Si applicano le seguenti considerazioni:

• Le implementazioni NON DOVREBBERO utilizzare truncated_hmac per applicazioni ad alta sicurezza.
• L'estensione truncated_hmac DOVREBBE essere utilizzata SOLO quando i vincoli di larghezza di banda sono significativi e il rischio di sicurezza ridotto è accettabile.
• Anche con MAC troncati, tutte le altre considerazioni sulla sicurezza TLS si applicano ancora.
• Le implementazioni DOVREBBERO considerare l'utilizzo di cipher suite con MAC più corti nativamente (come quelli che utilizzano cifrari AEAD) piuttosto che utilizzare truncated_hmac.

Gli attacchi potenziali contro MAC troncati includono:

Attacchi di collisione: Con un MAC di 80 bit, un attaccante ha una probabilità non trascurabile (circa 2^40 tentativi) di trovare una collisione utilizzando un attacco del compleanno. Tuttavia, sfruttare una collisione MAC in TLS richiederebbe che l'attaccante possa manipolare il testo in chiaro e osservare i MAC, il che è generalmente difficile.

Attacchi di falsificazione: Un attaccante che tenta di falsificare un MAC avrebbe bisogno di circa 2^80 tentativi, che è ancora computazionalmente costoso ma nel regno del possibile per avversari ben finanziati.

Alla luce di queste considerazioni, l'uso di truncated_hmac dovrebbe essere valutato attentamente in base al modello di minaccia dell'applicazione specifica.

11.6. Considerazioni sulla sicurezza per status_request

Le considerazioni sulla sicurezza per l'estensione status_request sono discusse in dettaglio nella Sezione 8.4. I punti chiave includono:

• I server possono servire risposte OCSP obsolete o errate.
• I client devono eseguire una validazione completa delle risposte OCSP ricevute.
• I server compromessi potrebbero omettere informazioni sullo stato per i certificati revocati.
• L'estensione migliora la privacy evitando che i client contattino direttamente i risponditori OCSP.

11.7. Considerazioni generali sulla sicurezza

Negoziazione delle estensioni: Il meccanismo di negoziazione delle estensioni stesso deve essere sicuro. Gli attaccanti non dovrebbero essere in grado di:

• Forzare l'uso o il non uso di particolari estensioni attraverso la soppressione o l'iniezione di messaggi.
• Apprendere informazioni sensibili osservando quali estensioni vengono negoziate.

Il meccanismo di handshake TLS protegge contro la modifica della negoziazione delle estensioni tramite il messaggio Finished, che copre tutti i messaggi di handshake incluse le estensioni.

Incompatibilità delle estensioni: I client e i server devono gestire correttamente situazioni in cui:

• Un'estensione è compresa da una parte ma non dall'altra.
• Sono supportate diverse versioni di un'estensione.
• Vengono richieste estensioni in conflitto.

Le implementazioni DOVREBBERO fallire in modo sicuro quando incontrano estensioni incomprensibili o in conflitto.

Considerazioni su prestazioni e sicurezza: Alcune estensioni possono avere implicazioni sulle prestazioni che influenzano la sicurezza. Ad esempio:

• Dimensioni di frammento più piccole possono aumentare il carico di elaborazione.
• L'ottenimento di certificati da URL può introdurre ritardi.
• L'elaborazione di grandi elenchi di CA affidabili può consumare risorse.

Le implementazioni DOVREBBERO considerare l'equilibrio tra i benefici delle funzionalità e i potenziali rischi di denial of service o degrado delle prestazioni.

Considerazioni sulla privacy: Diverse estensioni rivelano informazioni sul client o sul server:

• server_name rivela quale server il client sta tentando di contattare.
• trusted_ca_keys rivela l'ambiente di fiducia del client.
• client_certificate_url può rivelare le attività del client al server che ospita gli URL.

Le implementazioni DOVREBBERO consentire agli utenti di controllare quali informazioni vengono rivelate attraverso queste estensioni, specialmente negli ambienti in cui la privacy è una preoccupazione.

Estensibilità futura: Man mano che vengono definite nuove estensioni, ciascuna deve essere valutata attentamente per:

• Le implicazioni sulla sicurezza dell'estensione stessa.
• Le interazioni con le estensioni esistenti.
• L'impatto sul modello di sicurezza complessivo di TLS.

I creatori di nuove estensioni DOVREBBERO fornire un'analisi di sicurezza approfondita nelle loro specifiche.