Segue la compagnia Google sull'intenzione di condurre un esperimento per testare l'implementazione di "DNS over HTTPS" (DoH, DNS su HTTPS) in fase di sviluppo per il browser Chrome. Nel rilascio di Chrome 78, previsto per il 22 ottobre, alcune categorie di utenti verranno per default all'uso di DoH. Solo gli utenti le cui attuali impostazioni di sistema specificano alcuni fornitori DNS ritenuti compatibili con DoH parteciperanno all'esperimento di attivazione di DoH.
Nell'elenco dei fornitori DNS abilitati ci sono Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1), OpenDNS (208.67.222.222, 208.67.220.220), Quad9 (9.9.9.9, 149.112.112.112), Cleanbrowsing (185.228.168.168, 185.228.169.168) e DNS.SB (185.222.222.222, 185.184.222.222). Se nelle impostazioni DNS dell'utente sarà specificato uno dei server DNS sopra menzionati, DoH in Chrome sarà attivato per default. Per coloro che utilizzano i server DNS forniti dal fornitore di servizi internet locale, tutto rimarrà invariato e per le query DNS continuerà a essere utilizzato il risolutore di sistema.
Una differenza importante rispetto all'implementazione di DoH in Firefox, in cui l'attivazione graduale di DoH per default già alla fine di settembre, è l'assenza di un legame con un servizio DoH. Se in Firefox per impostazione predefinita il server DNS di CloudFlare, in Chrome verrà semplicemente aggiornato il metodo di lavoro con DNS a un servizio equivalente, senza cambiare fornitore DNS. Ad esempio, se un utente ha impostato 8.8.8.8 nelle impostazioni di sistema, in Chrome ci sarà il servizio DoH di Google («https://dns.google.com/dns-query»), se il DNS è 1.1.1.1, allora il servizio DoH di Cloudflare («https://cloudflare-dns.com/dns-query») e
Se lo desidera, l'utente potrà abilitare o disabilitare DoH tramite l'impostazione «chrome://flags/#dns-over-https». Sono supportati tre modalità di funzionamento: «secure», «automatic» e «off». In modalità «secure», gli host sono determinati solo sulla base dei valori sicuri precedentemente memorizzati nella cache (ottenuti tramite connessione sicura) e delle richieste tramite DoH, il ripristino a DNS tradizionale non viene applicato. In modalità «automatic», se DoH e la cache sicura non sono disponibili, è consentito ottenere dati dalla cache non sicura e accedere tramite DNS tradizionale. In modalità «off», si verifica inizialmente la cache generale e se i dati non sono disponibili, la richiesta viene inviata tramite DNS di sistema. La modalità è impostata tramite kDnsOverHttpsMode, e modello di corrispondenza dei server tramite kDnsOverHttpsTemplates.
L'esperimento per abilitare DoH sarà condotto su tutte le piattaforme supportate da Chrome, ad eccezione di Linux e iOS a causa della complessità nell'analisi delle impostazioni del resolver e delle limitazioni di accesso alle impostazioni DNS di sistema. Se dopo l'attivazione di DoH si verificano problemi nell'invio delle richieste al server DoH (ad esempio, a causa del suo blocco, di problemi di connettività o guasti), il browser ripristinerà automaticamente le impostazioni DNS di sistema.
L'obiettivo dell'esperimento è la verifica finale dell'implementazione di DoH e l'analisi dell'impatto dell'uso di DoH sulle prestazioni. Si noti che il supporto di DoH è stato effettivamente integrato nel codice sorgente di Chrome già a febbraio, ma per configurare e abilitare DoH avviare Chrome con un flag speciale e un insieme non evidente di opzioni.
Ricordiamo che il DoH può risultare utile per evitare perdite di dati sui nomi host richiesti attraverso i server DNS dei provider, per contrastare gli attacchi MITM e la manipolazione del traffico DNS (ad esempio, quando ci si connette a Wi-Fi pubblici), per affrontare i blocchi a livello di DNS (il DoH non può sostituire una VPN per eludere i blocchi implementati a livello di DPI) o per garantire il funzionamento in caso di impossibilità di connettersi direttamente ai server DNS (ad esempio, quando si lavora tramite un proxy). Se normalmente le richieste DNS vengono inviate direttamente a determinati server DNS configurati nel sistema, nel caso del DoH la richiesta di risoluzione dell'indirizzo IP dell'host viene incapsulata nel traffico HTTPS e inviata a un server HTTP, dove il resolver gestisce le richieste tramite un'API Web. Lo standard esistente DNSSEC utilizza la crittografia solo per l'autenticazione del cliente e del server, ma non protegge il traffico dall'intercettazione e non garantisce la riservatezza delle richieste.
Fonte: opennet.ru
