Chrome 78 inizierà a sperimentare l'abilitazione di DNS-over-HTTPS

Seguito da Mozilla Google segnalati sull’intenzione di condurre un esperimento per testare l’implementazione del “DNS over HTTPS” (DoH, DNS over HTTPS) in fase di sviluppo per il browser Chrome. La versione di Chrome 78 prevista per il 22 ottobre avrà alcune categorie di utenti per impostazione predefinita tradotto utilizzare DoH. L'esperimento per abilitare DoH sarà limitato agli utenti le cui attuali impostazioni di sistema elencano determinati provider DNS riconosciuti come conformi a DoH.

Provider DNS autorizzati inclusi servizi 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 , 185.222.222.222) e DNS.SB (185.184.222.222, XNUMX). Se uno dei server DNS sopra indicati è specificato nelle impostazioni DNS dell'utente, DoH in Chrome verrà attivato per impostazione predefinita. Per chi utilizza i server DNS forniti dall'ISP locale, tutto rimarrà invariato e il risolutore di sistema continuerà ad essere utilizzato per le query DNS.

Si tratta di una differenza importante rispetto all'implementazione DoH di Firefox, in cui DoH è abilitato in modo incrementale per impostazione predefinita comincerà già alla fine di settembre si segnala la mancanza di vincolo ad un unico servizio DoH. Se in Firefox per impostazione predefinita usato Server DNS CloudFlare, Chrome aggiornerà solo il metodo di lavoro con DNS a un servizio equivalente, senza modificare il provider DNS. Ad esempio, se l'utente ha specificato DNS 8.8.8.8 nelle impostazioni di sistema, Chrome lo farà attivato Servizio DoH di Google ("https://dns.google.com/dns-query"), se il DNS è 1.1.1.1, allora servizio DoH di Cloudflare ("https://cloudflare-dns.com/dns-query") E eccetera

Se lo desidera, l'utente potrà abilitare o disabilitare DoH utilizzando l'impostazione "chrome://flags/#dns-over-https". Sono supportate tre modalità operative "sicuro", "automatico" e "spento". Nella modalità "sicura", gli host vengono determinati solo in base ai valori sicuri precedentemente memorizzati nella cache (ottenuti tramite una connessione sicura) e alle richieste tramite DoH, non viene applicato il fallback al DNS normale. Nella modalità "automatica", se DoH e la cache sicura non sono disponibili, i dati possono essere recuperati dalla cache non sicura e accessibili tramite il DNS tradizionale. Nella modalità "off" viene prima controllata la cache condivisa e se non sono presenti dati, la richiesta viene inviata tramite il DNS del sistema. La modalità viene impostata tramite personalizzazione kDnsOverHttpsMode e il modello di mappatura del server tramite kDnsOverHttpsTemplates.

L'esperimento per abilitare DoH verrà effettuato su tutte le piattaforme supportate in Chrome, ad eccezione di Linux e iOS a causa della non banalità dell'analisi delle impostazioni del risolutore e della limitazione dell'accesso alle impostazioni del sistema DNS. Se, dopo aver abilitato DoH, si verificano errori nell'invio delle richieste al server DoH (ad esempio, a causa del suo blocco, di un errore o di un guasto della connettività di rete), il browser restituirà automaticamente le impostazioni del sistema DNS.

Lo scopo dell'esperimento è testare finalmente l'implementazione della DoH e studiare l'impatto dell'applicazione della DoH sulle prestazioni. Va notato che l'effettivo supporto DoH era aggiunto al codebase di Chrome a febbraio, ma per configurare e abilitare DoH necessario avviare Chrome con un flag speciale e una serie di opzioni non ovvie.

Ricordiamo che il DoH può essere utile per prevenire fughe di informazioni sui nomi host richiesti attraverso i server DNS dei provider, contrastare gli attacchi MITM e lo spoofing del traffico DNS (ad esempio quando ci si connette a Wi-Fi pubblici), contrastare il blocco a livello DNS (DoH non può sostituire la VPN nell'ambito dell'elusione del blocco implementato a livello DPI) o per organizzare il lavoro nel caso in cui sia impossibile accedere direttamente ai server DNS (ad esempio, quando si lavora tramite proxy). Mentre in una situazione normale le richieste DNS vengono inviate direttamente ai server DNS definiti nella configurazione del sistema, nel caso di DoH, la richiesta di determinare l'indirizzo IP dell'host viene incapsulata nel traffico HTTPS e inviata al server HTTP, su cui si trova il risolutore elabora le richieste tramite l'API Web. L'attuale standard DNSSEC utilizza la crittografia solo per autenticare client e server, ma non protegge il traffico dalle intercettazioni e non garantisce la riservatezza delle richieste.

Fonte: opennet.ru

Aggiungi un commento