Mozilla ha annunciato l'attivazione del supporto per il meccanismo ECH (Encrypted Client Hello) per gli utenti della versione stabile di Firefox, che continua a sviluppare la tecnologia ESNI (Encrypted Server Name Indication) e mira a crittografare le informazioni sui parametri delle sessioni TLS, come il nome di dominio richiesto. Inizialmente, il codice per il funzionamento di ECH è stato aggiunto nella versione 85 di Firefox, ma era disattivato per impostazione predefinita. In Chrome, il supporto per ECH è stato gradualmente attivato a partire dalla versione 115.
Poiché oltre alla connessione a server la fuga di informazioni sui domini richiesti avviene tramite DNS, per una protezione completa oltre a ECH è necessario utilizzare la tecnologia DNS over HTTPS o DNS over TLS per crittografare il traffico DNS. Firefox non utilizzerà ECH senza l'attivazione di DNS over HTTPS nelle impostazioni. È possibile verificare il supporto per ECH nel browser su questa pagina.
Uno dei fattori che ha portato all'attivazione predefinita del supporto ECH in Firefox è stata l'attivazione, qualche giorno fa, del supporto ECH da parte di Cloudflare nella sua rete di distribuzione dei contenuti. Dal punto di vista pratico, poiché i dati sui host richiesti sono nascosti dall'analisi quando viene utilizzato ECH, ora è necessaria la blocco di tutta la rete Cloudflare, la blocco di tutte le richieste con ECH, o l'organizzazione della cattura di HTTPS tramite certificati radice falsificati sul sistema utente per filtrare e bloccare siti indesiderati che utilizzano Cloudflare CDN.
Inizialmente, per gestire più siti HTTPS su un singolo indirizzo IP, veniva utilizzata l'estensione TLS SNI, in cui il nome dell'host richiesto veniva indicato nel messaggio ClientHello inviato prima della creazione del canale di comunicazione crittografato. Questa caratteristica consentiva, nelle prime fasi di elaborazione della connessione, di distribuire le richieste tra host virtuali e consentiva anche ai fornitori di servizi Internet di filtrare selettivamente il traffico HTTPS e analizzare quali siti l'utente apriva, il che non garantiva la completa riservatezza durante l'uso di HTTPS.
Per risolvere questo problema ed eliminare la fuga di informazioni sul sito richiesto, in seguito è stata proposta l'estensione ESNI, che implementa la crittografia dei dati con il nome dell'host. Durante il processo di implementazione di ESNI, è emerso che il meccanismo proposto non copriva tutte le possibili fonti di fuga di dati sull'host e il suo uso non era sufficiente per garantire la completa riservatezza delle sessioni HTTPS. In particolare, al riavvio di una sessione precedentemente stabilita, il nome di dominio continuava a essere visibile tra i parametri dell'estensione TLS PSK (Pre-Shared Key). Inoltre, i tentativi di implementazione di ESNI hanno rivelato problemi di compatibilità e scalabilità che ostacolavano la diffusione generalizzata di ESNI.
Tenendo conto dei difetti riscontrati in ESNI, è stato sviluppato un nuovo meccanismo universale ECH, che consente la crittografia dei parametri di qualsiasi estensione TLS. Tecnicamente, la principale differenza tra ECH e ESNI è che, invece di crittografare campi separati, viene crittografato l'intero messaggio ClientHello. ECH prevede la suddivisione del ClientHello in due messaggi distinti: un messaggio ClientHelloInner crittografato (SNI Inner) e un messaggio ClientHelloOuter non crittografato (SNI Outer). Nel SNI Outer non crittografato vengono trasmessi dati che non compromettono la riservatezza, come la versione TLS e l'elenco dei cipher utilizzati, nonché il nome generico del dominio, che non si sovrappone al nome effettivo del dominio richiesto. Ad esempio, per tutti i clienti Cloudflare, nel SNI Outer non crittografato viene indicato l'host generico "cloudflare-ech.com", mentre il nome effettivo dell'host richiesto viene trasmesso nel SNI Inner crittografato e non è accessibile per l'analisi.
ECH utilizza anche un'altra modalità di distribuzione della chiave per la crittografia: le informazioni sulla chiave pubblica vengono trasmesse nei record DNS HTTPSSVC, e non in un record di tipo TXT. Per ottenere e crittografare la chiave viene utilizzata una crittografia end-to-end autenticata basata sul meccanismo HPKE (Hybrid Public Key Encryption). ECH supporta anche la trasmissione sicura della chiave dal server, che può essere utilizzata in caso di rotazione delle chiavi su server e per risolvere problemi relativi all'ottenimento di chiavi obsolete dalla cache DNS.
Fonte: opennet.ru
