Mozilla ha annunciato l'inclusione del supporto per gli utenti del ramo stabile di Firefox per il meccanismo ECH (Encrypted Client Hello), che continua lo sviluppo della tecnologia ESNI (Encrypted Server Name Indication) ed è progettato per crittografare le informazioni sui parametri delle sessioni TLS , ad esempio il nome di dominio richiesto. Il codice per lavorare con ECH è stato originariamente aggiunto alla versione Firefox 85, ma è stato disabilitato per impostazione predefinita. Chrome ha iniziato gradualmente a includere il supporto ECH a partire dal rilascio di Chrome 115.
Poiché oltre a connettersi con server Le informazioni sul dominio richieste vengono divulgate tramite DNS. Per una protezione completa, oltre a ECH, è necessario utilizzare DNS su HTTPS o DNS su TLS per crittografare il traffico DNS. Firefox non utilizzerà ECH senza abilitare DNS su HTTPS nelle impostazioni. Puoi verificare il supporto ECH nel tuo browser su questa pagina.
Uno dei fattori che hanno abilitato il supporto ECH per impostazione predefinita in Firefox è stata l'inclusione del supporto ECH da parte di Cloudflare nella sua rete di distribuzione dei contenuti alcuni giorni fa. Dal punto di vista pratico, poiché i dati sugli host richiesti quando si utilizza ECH sono nascosti all'analisi, filtrare e bloccare i siti indesiderati utilizzando Cloudflare CDN richiederà ora il blocco dell'intera rete Cloudflare, il blocco di tutte le richieste da ECH o l'organizzazione dell'intercettazione HTTPS utilizzando falsi certificati root sul sistema dell'utente.
Inizialmente, per organizzare il lavoro su un indirizzo IP di più siti HTTPS, è stata utilizzata l'estensione TLS SNI, in cui il nome dell'host richiesto era indicato nel messaggio ClientHello trasmesso prima di stabilire un canale di comunicazione crittografato. Questa funzionalità ha consentito di distribuire le richieste tra host virtuali in una fase iniziale dell'elaborazione della connessione, ma ha anche consentito da parte dell'ISP di filtrare selettivamente il traffico HTTPS e analizzare quali siti apre l'utente, il che non ha consentito di ottenere la completa riservatezza durante l'utilizzo HTTPS.
Per risolvere questo problema ed evitare la fuga di informazioni sul sito richiesto, è stata successivamente proposta un'estensione ESNI che implementa la crittografia dei dati con il nome host. Durante l'implementazione dell'ESNI, è emerso che il meccanismo proposto non copre tutte le possibili fonti di fuga di dati dall'host e il suo utilizzo non è sufficiente a garantire la completa riservatezza delle sessioni HTTPS. In particolare, alla ripresa di una sessione precedentemente stabilita, il nome a dominio in chiaro ha continuato ad essere specificato tra i parametri dell'estensione TLS PSK (Pre-Shared Key). Inoltre, gli sforzi per implementare ESNI hanno identificato problemi di compatibilità e di scalabilità che hanno impedito un’adozione diffusa di ESNI.
Tenendo conto delle carenze individuate di ESNI, è stato sviluppato un nuovo meccanismo ECH universale che consente la crittografia dei parametri di qualsiasi estensione TLS. Tecnicamente, la differenza principale tra ECH ed ESNI è che invece dei singoli campi, l'intero messaggio ClientHello viene crittografato contemporaneamente. ECH prevede la suddivisione di ClientHello in due messaggi separati: il messaggio ClientHelloInner crittografato (SNI Inner) e il messaggio ClientHelloOuter sottostante non crittografato (SNI Outer). Un SNI Outer non crittografato trasporta dati non legati alla privacy come la versione TLS e un elenco di codici utilizzati, nonché un nome di dominio comune che non si sovrappone al nome effettivo del dominio richiesto. Ad esempio, per tutti i client Cloudflare, lo SNI Outer non crittografato specifica l'host comune "cloudflare-ech.com", ma il nome effettivo dell'host richiesto viene trasmesso nello SNI Inner crittografato e non è disponibile per l'analisi.
ECH utilizza anche un diverso schema di distribuzione delle chiavi di crittografia: le informazioni sulla chiave pubblica vengono trasmesse in record DNS HTTPSSVC anziché in record TXT. Per ottenere e crittografare la chiave, viene utilizzata la crittografia end-to-end autenticata basata sul meccanismo HPKE (Hybrid Public Key Encryption). ECH supporta anche la ritrasmissione sicura delle chiavi dal server, che può essere utilizzata in caso di rotazione delle chiavi. server e per risolvere i problemi relativi al recupero delle chiavi obsolete dalla cache DNS.
Fonte: opennet.ru
