Oggi annunciamo il supporto per un nuovo standard DNS proposto — progettato congiuntamente da tecnici di Cloudflare, Apple e Fastly — che separa gli indirizzi IP dalle query, in modo che nessuna singola entità possa visualizzare entrambi contemporaneamente. L'aspetto ancora più interessante è che abbiamo reso disponibile il codice sorgente, per cui chiunque può provare ODoH o eseguire il proprio servizio ODoH!
Il Domain Name System (DNS) è l'elemento alla base di un Internet a misura d'uomo. Esso mappa i nomi di dominio utilizzabili, come cloudflare.com, con gli indirizzi IP e altre informazioni necessarie per connettersi a quel dominio. È possibile leggere una breve introduzione sull'importanza del DNS e i problemi correlati in un precedente post del blog. In questa sede è sufficiente sapere che, nella progettazione iniziale e nell'utilizzo ancora dominante del DSN, le query vengono inviate in chiaro. Ciò significa che chiunque si trovi sul percorso di rete tra il dispositivo e il resolver DNS può vedere sia la query che contiene il nome host (o il sito Web) desiderato, sia l'indirizzo IP che identifica il dispositivo.
Per salvaguardare il DNS da curiosi e soggetti terzi, la IETF ha standardizzato la crittografia DNS con DNS over HTTPS (DoH) e DNS over TLS (DoT). Entrambi i protocolli impediscono l'intercettazione, il reindirizzamento o la modifica delle query tra il client e il resolver. Il supporto client per DoT e DoH è in aumento, essendo stato implementato nelle recenti versioni di Firefox, iOS e altri. Malgrado ciò, fino a quando non vi sarà una distribuzione più ampia tra i provider di servizi Internet, Cloudflare rimane uno dei pochi provider a offrire un servizio DoH/DoT pubblico. Questo aspetto solleva due problematiche principali. La prima è che la centralizzazione del DNS introduce singoli punti di vulnerabilità (anche se, con datacenter in oltre 100 Paesi, Cloudflare è progettato per essere sempre raggiungibile). L'altro timore è che il resolver possa comunque collegare tutte le query agli indirizzi IP del client.
Cloudflare si impegna a garantire la privacy degli utenti finali. Gli utenti del nostro servizio di resolver DNS pubblico sono protetti da una solida informativa sulla privacy sottoposta a revisione. Tuttavia, per alcuni, affidarsi a Cloudflare con informazioni di query sensibili rappresenta un ostacolo alla sua adozione, anche con un'informativa sulla privacy così stringente. E se, invece di fare affidamento su informative sulla privacy e audit, potessimo dare agli utenti la possibilità di rimuovere quella barra con garanzie tecniche?
Da oggi, Cloudflare e i suoi partner lanciano il supporto per un protocollo che fa esattamente questo: Oblivious DNS over HTTPS o, in breve, "ODoH".
Partner di ODoH:
Siamo entusiasti di lanciare ODoH insieme a diversi partner leader nel lancio ugualmente impegnati per la privacy.
Un componente chiave di ODoH è un proxy disgiunto dal resolver di destinazione. E oggi lanceremo ODoH con diversi partner leader nei proxy, tra cui: PCCW, SURF ed Equinix.
"ODoH è un nuovo concetto rivoluzionario progettato per mantenere la privacy degli utenti al centro di tutto. La nostra partnership ODoH con Cloudflare ci consegna un buon posizionamento nell'universo della privacy e dell'"Infrastruttura di Internet". Oltre a migliorare la sicurezza e le prestazioni della rete globale PCCW sottostante, a cui è possibile accedere on-demand tramite Console Connect, le prestazioni dei proxy sulla nostra rete vengono ora migliorate dai resolver 1.1.1.1 di Cloudflare. Questo modello per la prima volta scorpora completamente il proxy client dai resolver. Questa partnership rafforza la nostra attuale attenzione sulla privacy, a misura che il mondo passa a un modello più remoto e la privacy diventa una caratteristica ancora più fondamentale." -- Michael Glynn, Vice President, Digital Automated Innovation, PCCW Global
"Stiamo collaborando con Cloudflare per implementare una migliore privacy degli utenti tramite ODoH. Il passaggio a ODoH rappresenta un autentico cambiamento di paradigma, in cui la privacy degli utenti o l'indirizzo IP non vengono esposti ad alcun provider, con il risultato di una vera privacy. Con il lancio di OdoH-pilot, ci stiamo unendo alla potenza della rete Cloudflare per affrontare le sfide di tutti gli utenti del mondo. Il passaggio a ODoH non rappresenta solo un cambiamento di paradigma, ma sottolinea anche come la privacy sia più importante che mai per ogni utente, soprattutto nel 2020. È in sintonia con il nostro obiettivo principale e su ciò che pensiamo della privacy." — Joost van Dijk, Technical Product Manager, SURF
Come funziona Oblivious DNS over HTTPS (ODoH)?
ODoH funziona aggiungendo un livello di crittografia a chiave pubblica e un proxy di rete tra i client e i server DoH, come 1.1.1.1. La combinazione di questi due elementi aggiuntivi garantisce che solo l'utente abbia accesso ai messaggi DNS e al proprio indirizzo IP contemporaneamente.
Ci sono tre attori nel percorso ODoH. Osservando la figura sopra, iniziamo dal target. Il target decodifica le query crittografate dal client, tramite un proxy. Allo stesso modo, il target crittografa le risposte e le restituisce al proxy. Lo standard dice che il target può essere, o meno, il resolver (lo approfondiremo in un secondo momento). Il proxy fa ciò che dovrebbe fare un proxy, ovvero inoltra i messaggi tra il client e il target. Il client si comporta come in DNS e DoH, ma la differenza è che crittografa le query per il target e decodifica le risposte del target. Qualsiasi client che scelga di farlo può specificare un proxy e un target di scelta.
Combinati, l'aggiunta di crittografia e proxy offrono le seguenti garanzie:
- Il target vede solo la query e l'indirizzo IP del proxy.
- Il proxy non ha visibilità sui messaggi DNS, né ha la possibilità di identificare, leggere o modificare la query inviata dal client o la risposta restituita dal target.
- Solo il target designato può leggere il contenuto della query e generare una risposta.
Queste tre garanzie migliorano la privacy del client mantenendo al contempo sicurezza e integrità delle query DNS. Tuttavia, ciascuna di queste garanzie si basa su una proprietà fondamentale — che il proxy e i server del target non colludano. Fino a quando non vi è collusione, un aggressore può avere la meglio solo se sia il proxy che il target sono compromessi.
Un aspetto di questo sistema che vale la pena evidenziare è che il target è separato dal resolver ricorsivo a monte che esegue la risoluzione DNS. In pratica, per le prestazioni, ci aspettiamo che il target sia lo stesso. Di fatto, 1.1.1.1 è ora sia un resolver ricorsivo che un target! Non vi è alcun motivo per cui un target debba esistere separatamente da un resolver. Se sono separati, allora il target è libero di scegliere i resolver, e si limita ad agire come punto di riferimento. L'unico vero requisito da tenere a mente è che il proxy e il target non colludano mai.
Inoltre, cosa importante, i client hanno pieno controllo nella selezione del proxy e del target. Senza necessità di programmi come TRR, i client, oltre alla sicurezza, possono avere privacy per le loro query. Poiché il target conosce solo il proxy, il target e qualsiasi resolver upstream sono ignari dell'esistenza di qualsiasi indirizzo IP del client. È importante sottolineare che questo conferisce ai client un maggiore controllo sulle loro query e sui modi in cui potrebbero essere impiegate. Ad esempio, i client sarebbero in grado di selezionare e modificare i propri proxy e target in qualsiasi momento e per qualsiasi motivo!
Flusso di messaggi ODoH
In ODoH, la "O" sta per "Oblivious" (inconsapevole), e questa proprietà deriva dal livello di crittografia degli stessi messaggi DNS. Questa crittografia aggiunta è "end-to-end"' tra client e target, e indipendente dalla crittografia a livello di connessione fornita da TLS/HTTPS. Ci si potrebbe chiedere perché questa crittografia aggiuntiva sia necessaria, data la presenza di un proxy. Si deve al fatto che per supportare la funzionalità proxy sono necessarie due connessioni TLS separate. In particolare, il proxy termina una connessione TLS dal client e avvia un'altra connessione TLS verso il target. Tra queste due connessioni, i contesti dei messaggi DNS verrebbero altrimenti visualizzati in chiaro! Per questo motivo, ODoH crittografa anche i messaggi tra il client e il target, di modo che il proxy non abbia accesso ai contenuti del messaggio.
L'intera procedura inizia con i client che crittografano la loro query per il target con HPKE. I client ottengono la chiave pubblica del target tramite DNS, dove viene raggruppata in un record di risorse HTTPS e protetta da DNSSEC. Quando il TTL per questa chiave scade, i client richiedono una nuova copia della chiave in base alle esigenze (proprio come farebbero per un record A/AAAA alla scadenza del TTL del record). L'utilizzo della chiave pubblica del target convalidata da DNSSEC garantisce che solo il target designato possa decodificare la query e crittografare un responso (risposta).
I client trasmettono queste query crittografate a un proxy tramite una connessione HTTPS. Al momento della ricezione, il proxy inoltra la query al target designato. Il target decodifica quindi la query, produce una risposta inviando la query a un resolver ricorsivo come 1.1.1.1, e crittografa quindi la risposta al client. La query crittografata proveniente dal client contiene materiale di codifica incapsulato da cui i target derivano la chiave simmetrica di di crittografia della risposta.
Questa risposta viene quindi inviata al proxy e, successivamente, inoltrata al client. Tutte le comunicazioni sono autenticate e riservate, in quanto questi messaggi DNS sono crittografati end-to-end, nonostante vengano trasmessi su due connessioni HTTPS separate (client-proxy e proxy-target). Il messaggio che altrimenti appare al proxy come testo in chiaro è in realtà un'alterazione crittografata.
E le prestazioni? È necessario negoziarle per ottenere privacy?
Abbiamo fatto molte misurazioni per scoprirlo, e ne faremo altre a misura che ODoH viene distribuito in maniera più capillare. Il nostro set iniziale di configurazioni di misurazione si estende su città negli Stati Uniti, in Canada e in Brasile. È importante sottolineare che le nostre misurazioni includono non solo 1.1.1.1, ma anche 8.8.8.8 e 9.9.9.9. Il set completo di misurazioni, finora, è documentato per l'accesso aperto.
In queste misurazioni era importante isolare il costo dei proxy e della crittografia aggiuntiva dal costo della configurazione della connessione TLS e TCP. Questo perché i costi di TLS e TCP sono comunque sostenuti da DoH. Quindi, nella nostra configurazione, abbiamo "caricato" le misurazioni stabilendo le connessioni una volta, e riutilizzando tale connessione per tutte le misurazioni. Lo abbiamo fatto sia per DoH che per ODoH, dato che la stessa strategia poteva essere impiegata in entrambi i casi.
La prima cosa che possiamo dire con certezza è che la crittografia aggiuntiva è marginale. Lo sappiamo perché abbiamo selezionato in modo casuale 10.000 domini dal dataset Tranco e abbiamo misurato sia la crittografia del record A con una chiave pubblica diversa, che la sua decodifica. Il costo aggiuntivo tra una query/risposta DoH con proxy e la sua controparte ODoH è costantemente inferiore a 1 ms al 99° percentile.
La pipeline di richiesta-risposta ODoH, tuttavia, è molto più di una semplice crittografia. Un modo molto utile per esaminare le misurazioni è osservare il grafico di distribuzione cumulativo — se si ha familiarità con questi tipi di grafici, passare al paragrafo successivo. Contrariamente alla maggior parte dei grafici in cui iniziamo lungo l'asse x, con le distribuzioni cumulative si inizia spesso dall'asse y.
Il seguente grafico mostra le distribuzioni cumulative per i tempi di query/risposta in DoH, ODoH e DoH, quando vengono trasmesse sulla rete Tor. La linea orizzontale tratteggiata che inizia a sinistra da 0.5 è il segno del 50%. Lungo questa linea orizzontale, per qualsiasi curva tracciata, la parte della curva sotto la linea tratteggiata è pari al 50% dei punti dati. Ora si osservi l'asse x, che è una misura del tempo. Le linee che appaiono a sinistra sono più veloci delle linee a destra. Un ultimo dettaglio importante è che l'asse x è tracciato su una scala logaritmica. Che cosa significa? Si noti che la distanza tra i marcatori contrassegnati (10x) è uguale nelle distribuzioni cumulative, ma la "x" è un esponente, e rappresenta ordini di grandezza. Quindi, mentre la differenza di tempo tra i primi due marcatori è di 9 ms, la differenza tra il terzo e il quarto marcatore è di 900 ms.
In questo grafico, la curva centrale rappresenta le misurazioni di ODoH. Abbiamo anche misurato le prestazioni delle alternative che preservano la privacy, ad esempio le query DoH trasmesse sulla rete Tor, come rappresentate dalla curva destra nel grafico. (Ulteriori alternative per la tutela della privacy vengono indicate nel report tecnico di libero accesso). Rispetto ad altre varianti DNS orientate alla privacy, ODoH riduce il tempo di query di almeno la metà. Questo punto è importante perché privacy e prestazioni raramente vanno di pari passo, per cui assistere a un miglioramento di questo tipo è promettente!
Il grafico qui sopra ci dice inoltre che il 50% delle volte le query ODoH vengono risolte in meno di 228 ms. Si confronti ora la linea centrale con la linea sinistra che rappresenta la "linea retta" (o normale) DoH senza alcuna modifica. Quel profilo sinistro dice che il 50% delle volte le query DoH vengono risolte in meno di 146 ms. Guardando al di sotto del segno del 50%, le curve ci dicono anche che la metà delle volte quella differenza non è mai superiore a 100 ms. Dall'altro lato, l'osservazione delle curve sopra il segno del 50% ci dice che la metà delle query ODoH sono competitive rispetto a DoH.
Queste curve nascondono anche molte informazioni, per cui è importante approfondire ulteriormente le misurazioni. Il seguente grafico presenta tre diverse curve di distribuzione cumulativa che descrivono le prestazioni ODoH qualora selezioniamo proxy e target in base alla loro latenza. Questo è anche un esempio delle informazioni che le misurazioni possono rivelare, alcune delle quali sono controintuitive. Ad esempio, guardando al di sopra di 0.5, queste curve dicono che la metà dei tempi di query/risposta ODoH sono praticamente indistinguibili, indipendentemente dalla scelta del proxy e del target. Ora si sposti l'attenzione al di sotto di 0.5 e si confrontino le due curve continue con la curva tratteggiata che rappresenta la media complessiva. Quest'area suggerisce che la selezione del proxy e del target a latenza più bassa offre un miglioramento minimo rispetto alla media, ma, soprattutto, dimostra che la selezione del proxy a latenza più bassa comporta un peggioramento delle prestazioni!
Restano delle domande aperte, naturalmente. Questa prima serie di misurazioni è stata eseguita in gran parte in Nord America. Le prestazioni cambiano a livello globale? In che modo questo influisce sulle prestazioni del client, nella pratica? Stiamo lavorando per scoprirlo e questo rilascio ci aiuterà a farlo.
Interessante! Posso fare esperimenti con ODoH? Esiste un servizio ODoH open?
Sì e sì! Abbiamo aperto le nostre implementazioni interoperabili ODoH in Rust, odoh-rs, e Go, odoh-go, e abbiamo integrato il target sul resolver DNS di Cloudflare. Proprio così, 1.1.1.1 è pronto per ricevere query tramite ODoH.
Abbiamo anche aperto client di prova in Rust, odoh-client-rs , e Go, odoh-client-go, per provare le query ODoH. È inoltre possibile verificare la configurazione HPKE utilizzata da ODoH per la crittografia dei messaggi su 1.1.1.1, interrogando direttamente il servizio:
$ dig -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com
; <<>> DiG 9.10.6 <<>> -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19923
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;odoh.cloudflare-dns.com. IN TYPE65
;; ANSWER SECTION:
odoh.cloudflare-dns.com. 300 IN TYPE65 \# 108 00010000010003026832000400086810F8F96810F9F9000600202606 470000000000000000006810F8F92606470000000000000000006810 F9F98001002E002CFF0200280020000100010020ED82DBE32CCDE189 BC6C643A80B5FAFF82548D21601C613408BACAAE6467B30A
odoh.cloudflare-dns.com. 300 IN RRSIG TYPE65 13 3 300 20201119163629 20201117143629 34505 odoh.cloudflare-dns.com. yny5+ApxPSO6Q4aegv09ZnBmPiXxDEnX5Xv21TAchxbxt1VhqlHpb5Oc 8yQPNGXb0fb+NyibmHlvTXjphYjcPA==
;; Query time: 21 msec
;; SERVER: 173.245.58.100#53(173.245.58.100)
;; WHEN: Wed Nov 18 07:36:29 PST 2020
;; MSG SIZE rcvd: 291
Ci impegniamo a portarlo avanti nella IETF e stiamo già assistendo a un interesse da parte dei fornitori di client. Eric Rescorla, CTO di Firefox, ha dichiarato:
"Oblivious DoH è un'aggiunta importante all'ecosistema DNS sicuro. Siamo entusiasti di vedere che inizia a decollare e non vediamo l'ora di provarlo su Firefox."
Ci auguriamo che altri operatori si uniscano a noi lungo il cammino e che offrano supporto per il protocollo, eseguendo proxy o target, e speriamo che il supporto del client aumenti con l'aumentare dell'infrastruttura disponibile.
Il protocollo ODoH è un approccio pratico per migliorare la privacy degli utenti e mira a migliorare l'adozione complessiva di protocolli DNS crittografati senza compromettere le prestazioni e l'esperienza utente su Internet.
Riconoscimenti
Marek Vavruša e Anbang Wen sono stati determinanti per far sì che il resolver 1.1.1.1 supportasse ODoH. Chris Wood e Peter Wu hanno contribuito a preparare e testare le librerie ODoH.