Sviluppatori di Firefox sulla conclusione dei test per il supporto DNS su HTTPS (DoH, DNS over HTTPS) e l'intenzione di attivare questa tecnologia per impostazione predefinita per gli utenti negli Stati Uniti a fine settembre. L'attivazione avverrà gradualmente, inizialmente per una piccola percentuale di utenti, aumentando progressivamente fino al 100% in assenza di problemi. Dopo aver raggiunto gli Stati Uniti, si valuterà la possibilità di attivare DoH anche in altri paesi.
I test condotti nel corso dell'anno hanno dimostrato l'affidabilità e le buone prestazioni del servizio, e hanno anche permesso di identificare alcune situazioni in cui DoH può causare problemi, sviluppando soluzioni per evitarli (ad esempio, sono stati analizzati l'ottimizzazione del traffico nelle reti di distribuzione dei contenuti, il controllo parentale e le zone DNS interne aziendali).
L'importanza della crittografia del traffico DNS è considerata un fattore fondamentale per la protezione degli utenti; per questo motivo, è stato deciso di abilitare DoH per impostazione predefinita, inizialmente solo per gli utenti negli Stati Uniti. Dopo l'attivazione di DoH, verrà mostrato un avviso all'utente che consentirà, se lo desidera, di rinunciare all'accesso ai server DNS DoH centralizzati e tornare al tradizionale schema di invio di richieste non crittografate ai server DNS del provider (a differenza dell'infrastruttura distribuita dei resolver DNS, in DoH è utilizzato un legame a un determinato servizio DoH, che può essere considerato come un punto unico di guasto).
Con l'attivazione di DoH, potrebbero verificarsi interferenze nei sistemi di controllo genitori e nelle reti aziendali che utilizzano una struttura di nomi DNS accessibile solo all'interno della rete per la traduzione degli indirizzi intranet e degli host aziendali. Per risolvere i problemi con questi sistemi, è stato aggiunto un sistema di controlli che disattiva automaticamente DoH. I controlli vengono eseguiti ad ogni avvio del browser o quando viene rilevato un cambiamento della sottorete.
È previsto un ritorno automatico all'utilizzo del risolutore di sistema in caso di fallimenti nel risolvere tramite DoH (ad esempio, in caso di problemi di connettività con il provider DoH o malfunzionamenti nella sua infrastruttura). Il senso di tali controlli è discutibile, poiché nulla impedisce agli aggressori, che controllano il funzionamento del risolutore o possono interferire nel traffico, di simulare un tale comportamento per disattivare la crittografia del traffico DNS. Il problema è stato risolto aggiungendo nelle impostazioni l'opzione "DoH sempre attivo" (non attivata per impostazione predefinita), che, se impostata, non applica la disattivazione automatica, rappresentando così un compromesso ragionevole.
Per identificare i resolver aziendali, vengono effettuati controlli su domini di primo livello (TLD) non comuni e il resolver di sistema restituisce indirizzi intranet. Per determinare l'attivazione del controllo parentale, si tenta di risolvere il nome exampleadultsite.com e se il risultato non corrisponde all'IP effettivo, si considera che sia attiva la blocco dei contenuti per adulti a livello DNS. Vengono inoltre controllati come segnali gli indirizzi IP di Google e YouTube per verificare la sostituzione con restrict.youtube.com, forcesafesearch.google.com e restrictmoderate.youtube.com. Inoltre Mozilla implementare un host di verifica unificato , che possono utilizzare i provider di servizi Internet e i servizi di controllo parentale come etichetta per disabilitare DoH (se l'host non è riconosciuto, Firefox disabilita DoH).
L'utilizzo di un servizio DoH centralizzato può anche comportare problemi nell'ottimizzazione del traffico nelle reti di distribuzione dei contenuti, che eseguono il bilanciamento del traffico utilizzando DNS (il server DNS della rete CDN genera una risposta considerando l'indirizzo del resolver e fornisce l'host più vicino per il recupero del contenuto). L'invio di una richiesta DNS dal resolver più vicino all'utente in tali CDN porta al ritorno dell'indirizzo dell'host più vicino all'utente, ma l'invio di una richiesta DNS da un resolver centralizzato fornirà l'indirizzo dell'host più vicino al server DNS-over-HTTPS. Test pratici hanno dimostrato che l'applicazione di DNS-over-HTTP con l'utilizzo di CDN raramente comportava ritardi all'inizio della trasmissione dei contenuti (per connessioni veloci, i ritardi non superavano i 10 millisecondi, mentre su canali di comunicazione più lenti si osservava persino un'accelerazione delle prestazioni). Per trasmettere al resolver CDN informazioni sulla posizione del cliente, è stata anche considerata l'applicazione dell'estensione EDNS Client Subnet.
Ricordiamo che DoH può risultare utile per escludere perdite di informazioni sui nomi host richiesti attraverso i server DNS dei provider, per combattere gli attacchi MITM e la sostituzione del traffico DNS, per contrastare le restrizioni a livello DNS o per organizzare l'operatività in caso di impossibilità a contattare direttamente i server DNS (ad esempio, quando si utilizza un proxy). In una situazione normale, le richieste DNS vengono inviate direttamente ai server DNS specificati nella configurazione di sistema, mentre nel caso del DoH la richiesta per determinare l'indirizzo IP dell'host è incapsulata nel traffico HTTPS e inviata a un server HTTP, dove il resolver gestisce le richieste tramite Web API. 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.
Per attivare DoH in about:config, è necessario modificare il valore della variabile network.trr.mode, supportata a partire da Firefox 60. Il valore 0 disattiva completamente DoH; 1 utilizza DNS o DoH, a seconda di quale sia più veloce; 2 utilizza DoH come predefinito, con DNS come opzione di riserva; 3 utilizza solo DoH; 4 è la modalità mirror in cui DoH e DNS sono attivi parallelamente. Di default viene utilizzato il server DNS di CloudFlare, ma può essere cambiato tramite il parametro network.trr.uri, per esempio, è possibile impostare "https://dns.google.com/experimental" o "https://9.9.9.9/dns-query".
Fonte: opennet.ru
