Mantienilo crittografato, mantienilo al sicuro: lavorare con ESNI, DoH e DoT

Gli ultimi sviluppi nella protezione della privacy su Internet includono l'indicazione del nome del server TLS crittografato (ESNI) e il DNS crittografato sotto forma di DNS su HTTPS (DoH), entrambi considerati altamente controversi dai raccoglitori di dati.

Quindi ecco una rapida occhiata alle ragioni per cui esistono, i dettagli su cosa sono e la tecnologia dietro il loro funzionamento.

Il DNS deve funzionare correttamente

Le connessioni di rete privata virtuale (VPN) split-tunnel, il protocollo WPAD (Web Proxy Auto-Discovery), il DNS multicast a configurazione zero (mDNS), le blacklist in tempo reale (RBL) e molte altre tecnologie ampiamente distribuite si interrompono quando il DNS non funziona t funzionare correttamente.

Rompere Internet per profitto e fama

Già nel 2003, gli utenti di Internet hanno appreso dell'importanza del DNS su scala globale quando l'azienda che allora gestiva il dominio di primo livello (TLD) .com ha scelto di interrompere l'emissione di risposte NXDOMAIN . Hanno invece impersonato qualsiasi dominio inesistente nel tentativo di pubblicare più annunci, vendere più domini e, in definitiva, generare più entrate. L'imprevisto effetto a catena ha portato a un dibattito pubblico e a un rapporto schiacciante del Security and Stability Advisory Committee (SSAC) dell'ICANN. Questo progetto è stato effettivamente chiuso, ma da un punto di vista tecnico la vulnerabilità è rimasta.

Più tardi, nel 2008, un altro tentativo di manipolare il DNS a scopo di lucro è stato dichiarato pubblicamente quando alcuni dei più grandi ISP hanno finito per introdurre varie vie per attacchi di scripting tra siti contro qualsiasi sito Web. A causa della natura delle vulnerabilità, possono essere sfruttati anche siti web ospitati su una rete privata e inaccessibili da Internet.

Il problema riscontrato non riguarda i protocolli Internet di base, ma è invece un problema aggravato dalla monetizzazione inappropriata di alcune funzionalità DNS.

Paul Vixie, Internet Systems Consortium (ISC)

Sebbene sia vero che i protocolli stessi non sono realmente la causa del problema, è anche vero che questi protocolli non impediscono ai malintenzionati di abusare del sistema. Quindi, da un punto di vista tecnico, la vulnerabilità persisteva.

Rompere Internet per sorveglianza e censura

Nel 2016 è stato osservato che gli ISP in Iran stavano manipolando il DNS. Questa volta, invece di iniettare pubblicità, stavano bloccando l'accesso ai server di posta elettronica di 139 dei primi 10.000 domini su Internet. Non è chiaro se questa sia una politica intenzionale di negazione del servizio contro questi domini specifici, simile alla censura di fama mondiale in Cina, o forse solo un esempio di una cattiva implementazione tecnica di qualsiasi sistema stia intercettando le query DNS.

Non sapere perché il DNS viene intercettato è importante: anche se mettiamo da parte le questioni morali e legali sulla sorveglianza generale e la censura, la tecnologia utilizzata per farlo è, per sua stessa natura, non conforme agli standard e potrebbe benissimo interferire con il tuo uso normale, quotidiano, ragionevole e legale di Internet.

Tuttavia, da un punto di vista tecnico, la vulnerabilità persisteva.

Rompere Internet per scopi nefasti

Naturalmente, non sono solo gli enti commerciali e i governi che stanno cercando di intercettare il traffico Internet per i propri mezzi. Esistono molti esempi di criminali che tentano di dirottare le connessioni, di solito allo scopo di rubare i dati degli utenti o indurre gli utenti a rivelare importanti credenziali di accesso. Soprattutto, l'avvelenamento della cache DNS è stato utilizzato per indirizzare gli utenti a siti di phishing, distribuire ransomware, distribuire botnet, negare il servizio a siti Web specifici e molto altro.

TLS perde chi si connette a chi

Transport Layer Security (TLS) è la tecnologia alla base di HTTPS, la versione sicura di HTTP su cui tutti facciamo affidamento ogni giorno. La creazione di una connessione TLS richiede una serie di passaggi, durante i quali il server dimostra la propria identità presentando un certificato e vengono scambiate nuove chiavi di crittografia.

Fare in modo che il server utilizzi un certificato per dimostrare la propria identità è un passaggio molto importante, poiché una parte del certificato è una chiave di crittografia pubblica asimmetrica.

Quando il client invia un messaggio utilizzando questa chiave, solo il server che è in possesso della chiave privata associata può leggere il messaggio. Di conseguenza, chiunque intercetti o ascolti la connessione viene bloccato e non è in grado di leggere il contenuto.

Tuttavia, lo scambio iniziale viene ancora eseguito in chiaro senza crittografia, il che significa che un osservatore conoscerà sempre l'identità del server.

Fronte di dominio

Alcuni strumenti di tipo anti-censura hanno aggirato questa perdita in TLS per un periodo di tempo utilizzando una tecnica nota come fronting di dominio. Ciò sfrutta il fatto che una volta stabilita una connessione HTTPS, la maggior parte dei grandi provider di hosting non verifica se il nome host presentato in ciascuna richiesta HTTP corrisponde a quello utilizzato nell'handshake TLS. In termini di strumenti per la privacy, questa è stata vista come una funzionalità utile che consente la comunicazione segreta con un sito nascosto. Per i provider di hosting e i raccoglitori di dati, questo è stato visto come un abuso del modo in cui le specifiche sono state implementate.

Questa è di per sé una vulnerabilità e, in quanto tale, è stata risolta da diversi importanti provider di hosting, tra cui AWS.

Risolvere il problema modificando lo standard: SNI crittografato (ESNI)

L'idea alla base di ESNI è impedire che TLS perda dati crittografando tutti i messaggi, incluso il messaggio Client Hello iniziale. Ciò lascia qualsiasi osservatore completamente all'oscuro del certificato del server presentato dal server.

Per fare ciò, il client necessita di una chiave di crittografia prima di effettuare la connessione. Pertanto, ESNI richiede che un set specifico di chiavi di crittografia ESNI venga inserito in un record SRV in DNS.

I dettagli esatti di questo sono ancora in evoluzione, tuttavia, poiché le specifiche devono ancora essere finalizzate. Nonostante ciò, un'implementazione di ESNI è già stata messa in produzione da Mozilla Firefox e Cloudflare.

Protezione e crittografia DNS

Affinché le chiavi ESNI vengano consegnate senza essere intercettate, è importante proteggersi dalla manomissione del DNS.

Fin dal 1993, la comunità di Internet ha cercato di proteggere il DNS. L'IETF osserva che i primi incontri per la risoluzione dei problemi hanno discusso:

1. Protezione contro la divulgazione di dati DNS a soggetti non autorizzati
2. Garantire l'integrità dei dati
3. Autenticazione dell'origine dei dati

Questi incontri hanno portato allo standard DNSSEC (Domain Name System Security Extensions) nel 1997. Lo standard ha scelto di affrontare due su tre di questi problemi, poiché il team di progettazione ha preso la decisione esplicita di escludere esplicitamente tutte le minacce di divulgazione dei dati dall'ambito.

In quanto tale, DNSSEC significa che gli utenti possono fidarsi del fatto che le risposte alle loro query DNS sono quelle che i proprietari di dominio intendono che siano. Nel contesto di ESNI, ciò significa che sappiamo che la chiave che stiamo ricevendo non è stata manomessa e, per fortuna, molte vulnerabilità sopra menzionate scompaiono quando DNSSEC è in uso. Tuttavia, non garantisce la privacy ed è quindi ancora vulnerabile ai problemi introdotti dai sistemi di sorveglianza e censura.

Sfortunatamente, poiché è completamente compatibile con le versioni precedenti con "DNS non sicuro" e abbastanza difficile da implementare correttamente, l'adozione di DNSSEC è molto bassa. Molti proprietari di domini si stanno arrendendo a metà del tentativo di configurarlo, come evidenziato da numerose configurazioni non valide e semiimpostate viste in natura.

DNS su HTTPS (DoH)

Affinché le chiavi ESNI vengano consegnate senza che gli osservatori sappiano quale sito stanno tentando di visitare gli utenti, è importante proteggersi dalle intercettazioni DNS. In quanto tale, è abbastanza logico e comprensibile dire che il DNS crittografato (come con DoH) è una buona cosa. Tuttavia, allo stato attuale, il DNS non è crittografato.

Ci sono mosse da Mozilla, Google, APNIC, Cloudflare, Microsoft e altri per cambiare questo.

L'esperienza utente crittografata ideale

Un utente che desidera sfruttare le tecnologie di cui sopra potrebbe avere un elenco piuttosto lungo di requisiti quando si tratta dei dettagli pratici dell'esperienza utente per lavorare con la crittografia. Probabilmente, vorrebbero evitare cose del calibro di:

• Essere costretti a utilizzare un provider di servizi DNS specifico (non importa quanto sia buono) o per la scelta di essere invisibile o difficile da trovare
• Ogni app su un dispositivo gestisce il DNS in modo diverso (ad esempio, Firefox può trovare cose che Safari non può)
• Tutte le app su un dispositivo devono creare la propria implementazione DNS sicura al proprio interno
• Dover configurare manualmente il DNS più volte
• Dover optare per privacy e sicurezza
• Le app ricadono in operazioni non sicure senza il consenso dell'utente

Gli utenti attenti alla privacy vorrebbero invece:

• Privacy da sorveglianza ingiustificata da parte di chiunque
• Protezione dalla pubblicità mirata a cui non hanno acconsentito
• Protezione del proprio contenuto pubblicato (ad es. su un sito Web personale) da modifiche o manipolazioni durante il percorso verso altri spettatori
• Garanzia che gli spettatori dei propri contenuti pubblicati non si mettano nei guai semplicemente per accedervi
• Per continuare ad avere la possibilità di controllare il DNS sulle proprie reti (perché a volte, il DNS split-horizon è utile per mantenere le risorse interne nell'ambito degli utenti interni)
• La possibilità di attivare, o almeno disattivare, il filtraggio a livello DNS (ad es. Quad9, CleanBrowsing e OpenDNS Family Shield)
• Configurazione semplice e senza problemi (ad es. DHCP)
• Per richiedere il consenso all'utilizzo del DNS senza crittografia
• Protezione non solo per il traffico del browser, ma per tutti i tipi di traffico, ad esempio e-mail, Slack, VoIP, SSH, VPN, ecc.

Sforzi di crittografia attuali

Quali opzioni ci sono per gli utenti con gli obiettivi di cui sopra?

La soluzione di Mozilla è un inizio, ma tutt'altro che ideale. Stanno solo proteggendo Firefox; l'impostazione predefinita è ignorare le impostazioni del tuo sistema operativo a favore della scelta del provider (Cloudflare) senza dirlo, e torna silenziosamente a essere insicuro (in caso di blocco del DNS crittografato, ecc.)

La soluzione di Google è un approccio migliore. Stanno proteggendo Android 9+, che si applica a tutte le app. (Non sono sicuro dei loro piani per Chrome OS, ma sospetto che sia in lavorazione.) Stanno anche proteggendo Chrome su tutte le piattaforme, ma attivano la sicurezza solo quando la piattaforma host è configurata per utilizzare un provider che supporta la sicurezza. Questo è buono in termini di scelta dell'utente, ma non è l'ideale perché torna silenziosamente a essere insicuro.

Anche tutti gli altri principali browser stanno implementando il supporto.

Nella situazione ideale per gli utenti, la più ampia comunità di sviluppatori di software e sistemi operativi:

1. Interrompere l'implementazione di nuove funzionalità di sicurezza DNS a livello di applicazione
2. Inizia a implementarli a livello di sistema operativo
3. Rispetta la configurazione a livello di sistema operativo o ottieni il consenso dell'utente

Implementando il DNS crittografato a livello di sistema operativo, potremmo continuare a seguire lo stesso modello distribuito che abbiamo attualmente per i risolutori DNS. L'esecuzione del proprio server DNS sulla propria rete ed essere in grado di rendere sicuro quel risolutore ha senso continuare a essere un'opzione, come dovrebbe utilizzare un provider centralizzato.

Linux e BSD hanno già questa funzionalità con una varietà di opzioni disponibili. Sfortunatamente, nessuna distribuzione ne abilita nessuna per impostazione predefinita, per quanto ne so. Dai un'occhiata a nss-tls se vuoi qualcosa che si collegherà semplicemente a glibc.

Anche l'implementazione DNS-over-TLS di Google in Android 9+ lo fa già. Funziona testando il server DNS per il supporto della crittografia. Se ce l'ha, lo userà. In caso contrario, come con Chrome, continua in modo non sicuro, senza richiedere il consenso.

Vale la pena notare che la maggior parte delle reti è configurata per utilizzare server DNS che non supportano la crittografia, quindi la soluzione integrata in Android non cambia ancora nulla per la maggior parte degli utenti. Forse sarebbe meglio offrire di ricorrere a un DNS crittografato centralizzato nei casi in cui il decentralizzato non supporta la crittografia.

Per i dispositivi Apple e Microsoft, il supporto per il DNS crittografato deve ancora arrivare ufficialmente al momento della stesura di questo documento. Con Microsoft che ha annunciato a novembre 2019 le sue intenzioni di supportare il DNS crittografato, si spera che Apple lo segua presto.

Soluzioni alternative DNS crittografate

Esistono alcune soluzioni alternative sotto forma di proxy che possono essere eseguiti localmente. Con questi, il computer di un utente comunica a se stesso DNS non crittografato, che quindi comunica DNS crittografato a qualsiasi provider sia configurato per l'uso. Questa non è una soluzione ideale, ma come soluzioni alternative, è decente.

L'ispirazione per scrivere questo articolo è il proxy DNSCrypt, che è molto stabile, ha molti campanelli e fischietti ed è multipiattaforma. Supporta il vecchio protocollo DNSCrypt, nonché i più recenti protocolli DNS over TLS (DoT) e DNS over HTTPS (DoH).

Per gli utenti Windows, c'è un programma di installazione e una GUI chiamati Simple DNSCrypt, che è completo di funzionalità e molto facile da usare.

Lo consiglio, ma tieni presente che il mondo probabilmente non è ancora pronto per te e potresti aver bisogno di disabilitarlo di tanto in tanto (ad esempio, quando devi utilizzare un captive portal nel tuo bar preferito o in una LAN partito).

Altre opzioni

Inoltre, c'è il server DNS Technitium, che supporta DNS crittografato, è multipiattaforma (Windows, MacOS, Linux su ARM/Raspberry Pi) e presenta un'interfaccia web liscia. È sotto "altro" perché è più uno strumento completo che una soluzione specifica per questo problema. (Probabilmente sarebbe una buona scelta se desideri eseguire il tuo server DNS Raspberry Pi a casa. Sarei interessato a sentire il feedback delle persone che lo provano nei commenti qui sotto.)

Per i tuoi dispositivi Android o iOS (iPhone, iPad, ecc.), c'è anche l'app 1.1.1.1, che forzerà tutte le tue query DNS sul servizio Cloudflare Encrypted DNS. Ho sentito che ci sono anche app più flessibili, come Intra, ma non ho ancora speso il tempo per testarle.

Naturalmente, puoi anche abilitare il DNS crittografato sia in Firefox che in Chrome: tieni solo a mente tutte le avvertenze discusse sopra.

Affidabilità DNS: lavoro numero uno

Ci sono molte polemiche con la tecnologia per la privacy di Internet. Tuttavia, quando si tratta di implementare misure di sicurezza e privacy, la tecnologia in questione non riguarda principalmente il mantenimento dei segreti. Si tratta di garantire affidabilità e garantire che la tecnologia continui a funzionare correttamente nonostante il comportamento degli altri. Tuttavia, dobbiamo essere consapevoli del fatto che, proprio come la tecnologia senza tutele della privacy è pessima, le salvaguardie mal implementate possono solo peggiorare la situazione.