L'azienda Mozilla ha annunciato l'aggiunta del supporto per il meccanismo ECH (Encrypted Client Hello) nella versione stabile di Firefox, continuando lo sviluppo della tecnologia ESNI (Encrypted Server Name Indication) e destinata a crittografare le informazioni sui parametri delle sessioni TLS, come il nome di dominio richiesto. Il codice per il funzionamento di ECH è stato inizialmente 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, è necessaria l'applicazione della 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 per l'attivazione per impostazione predefinita del supporto ECH in Firefox è stata l'introduzione, qualche giorno fa, da parte di Cloudflare, del supporto ECH nella propria rete di distribuzione dei contenuti. Dal punto di vista pratico, poiché i dati sui host richiesti con ECH sono nascosti dall'analisi, per filtrare e bloccare i siti non graditi che utilizzano la CDN di Cloudflare sarà ora necessario bloccare l'intera rete Cloudflare, bloccare tutte le richieste con ECH o organizzare l'intercettazione di HTTPS tramite certificati root falsi sul sistema dell'utente.
Inizialmente, per gestire più siti HTTPS su un unico indirizzo IP, veniva utilizzata l'estensione SNI del TLS, in cui il nome dell'host richiesto veniva specificato nel messaggio ClientHello, inviato prima dell'instaurazione del canale di comunicazione crittografato. Questa particolare funzionalità consentiva, nelle fasi iniziali dell'elaborazione della connessione, di distribuire le richieste tra host virtuali, ma permetteva anche ai provider Internet di filtrare selettivamente il traffico HTTPS e analizzare quali siti stesse visitando l'utente, impedendo così di raggiungere una completa riservatezza nell'uso di HTTPS.
Per affrontare questo problema ed evitare la fuoriuscita di informazioni sul sito richiesto, è stata successivamente proposta l'estensione ESNI, che implementa la crittografia dei dati con il nome dell'host. Durante l'implementazione di ESNI, è emerso che il meccanismo proposto non copriva tutte le possibili fonti di fuoriuscita di dati sull'host e che la sua applicazione non era sufficiente a garantire la completa riservatezza delle sessioni HTTPS. In particolare, durante il riepilogo di una sessione già stabilita, il nome di dominio continuava ad essere indicato in chiaro 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 universale di ESNI.
Tenendo conto dei difetti rilevati, è stato sviluppato un nuovo meccanismo universale ECH, che consente la crittografia dei parametri di qualsiasi estensione TLS. Dal punto di vista tecnico, la principale differenza tra ECH ed ESNI è che, invece di crittografare singoli campi, crittografa l'intero messaggio ClientHello. ECH prevede la suddivisione di ClientHello in due messaggi distinti: un messaggio crittografato ClientHelloInner (SNI Inner) e un messaggio di base non crittografato ClientHelloOuter (SNI Outer). Nel non crittografato SNI Outer vengono trasmessi dati non riservati, come la versione di TLS e l'elenco dei cipher utilizzati, insieme al nome di dominio generale, che non si sovrappone con il nome effettivo del dominio richiesto. Ad esempio, per tutti i clienti di Cloudflare, nell'SNI Outer non crittografato viene indicato l'host generale "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 uno schema diverso per la distribuzione della chiave per la crittografia: le informazioni sulla chiave pubblica vengono trasmesse nei record DNS HTTPSSVC, anziché nei record di tipo TXT. Per ottenere e crittografare la chiave viene applicata la 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. server e per affrontare i problemi nel ricevere chiavi obsolete dalla cache DNS.
Fonte: opennet.ru
