Cos’è una fuga di dati DNS o WebRTC?

Pensi al DNS come alla rubrica di internet. Ogni volta che digita un indirizzo web, il Suo dispositivo non può usare il nome da solo. Deve trasformare quel nome in un numero, un indirizzo IP, e per farlo chiede a un resolver DNS. Sulla maggior parte delle reti il resolver appartiene a chi gestisce la rete. A casa è il Suo provider, al lavoro è il reparto IT.

Così la piccola richiesta che dice «dov’è example.com?» viaggia verso un server che Lei non controlla, e porta con sé il nome del sito che sta per aprire. Si ha una fuga DNS quando quella risoluzione sfugge alla protezione che pensava La coprisse. Magari usa qualcosa che cifra il traffico in sé, ma se la risoluzione del nome host esce comunque verso il resolver della rete, la rete scopre lo stesso il nome di ogni sito che raggiunge.

Quello che conta è che cosa trapela. Una fuga DNS non rivela cosa ha inviato o letto. Rivela dove stava andando, ed è proprio questa, per molte persone, la parte sensibile.

WebRTC è un insieme di funzioni integrate in ogni browser moderno perché videochiamate, chat vocali e alcune condivisioni dirette di file funzionino senza un’app separata. Per collegare 2 persone tra loro, WebRTC deve prima capire a quali indirizzi ciascun lato è raggiungibile. Raccoglie indirizzi candidati, compreso l’indirizzo di rete locale del Suo dispositivo e, con l’aiuto di un server chiamato server STUN, il Suo IP pubblico.

Il punto è che questa raccolta di indirizzi può partire direttamente dal JavaScript di una pagina, e può muoversi lungo un percorso proprio invece di quello usato dal resto dei Suoi strumenti. Così una pagina può chiedere in silenzio al browser «qual è il vero IP di questo visitatore?» e ricevere una risposta, anche quando la connessione principale sembra blindata.

Questa è una fuga WebRTC. Può consegnare a una pagina web il Suo vero indirizzo IP tramite una funzione che non ha mai scelto di attivare, ed è esattamente per questo che ha sorpreso chi dava per scontato che un solo strumento bastasse.

Le metta a confronto. Una fuga DNS dice alla rete i nomi dei siti che visita. Una fuga WebRTC dice a un sito web il numero che identifica la Sua connessione. Se usa un dispositivo o una rete controllati da qualcun altro, quei dati, messi insieme, sono tutto ciò che conta.

Il motivo per cui ricorre a un proxy o a uno strumento per la privacy è proprio tenere per sé uno di quei 2 dati. Una fuga in uno dei 2 canali vanifica lo sforzo senza alcun segnale. Niente sembra rotto. La pagina si carica lo stesso. Ha semplicemente consegnato più di quanto volesse.

• Fuga DNS: trapela il nome del sito, lo vede la rete (il Suo provider o il resolver locale), e la scopre con un test di fuga DNS.
• Fuga WebRTC: trapela il Suo vero indirizzo IP, lo vede la pagina web che sta visitando, e la scopre con un test di fuga WebRTC.

È qui che un proxy web che riscrive i contenuti dimostra la sua utilità, ed è qui che conviene essere precisi su cosa fa e cosa non fa.

Quando apre un sito tramite TrickyBird, in realtà sta caricando l’indirizzo di TrickyBird. L’indirizzo di destinazione è codificato dentro il percorso, e il nome del sito lo risolviamo noi, sui nostri server: la query che il Suo dispositivo invia riguarda il nostro indirizzo. Quindi, se si sta chiedendo che cosa fa per Lei un proxy web a questo punto, è questo: nasconde il Suo IP al sito che apre e ne risolve il nome sui nostri server. È la stessa assenza di fughe di dominio: ovunque l’indirizzo della destinazione debba passare, passa codificato, non scritto per esteso (veda quali siti al momento si visualizzano correttamente su /status). Non c’è alcun download e nessuna app, ed è ciò che conta quando il blocco è su un dispositivo che non Le lascia installare nulla.

Un limite, però, va detto chiaramente. Il gateway stesso deve comunque risolvere la destinazione e collegarsi a essa per recuperarla, quindi quel tratto non è nascosto. Ne conserviamo un log volutamente ridotto: un indirizzo IP abbreviato a un /24 o /48, così indica un quartiere e non una singola casa, più il nome host di destinazione e qualche dato di base sulla risposta, per al massimo 48 ore. Tutti i dettagli su conservazione e cancellazione sono su /security. È una registrazione minima, di breve durata e verificabile, e il punto è che può controllarla invece di crederci sulla parola. È un approccio molto diverso da una promessa assoluta che Lei non ha modo di verificare. Veda il confronto tra le politiche.

No, e su questo conviene essere chiari. TrickyBird riscrive le pagine che serve, ma non intercetta WebRTC. WebRTC funziona come un sottosistema del browser a sé, sul proprio percorso di rete, quindi una pagina che apre attraverso il proxy può ancora raggiungere direttamente un server STUN e recuperare il Suo vero IP, anche mentre il resto di quella pagina si carica attraverso TrickyBird.

WebRTC, quindi, lo deve disattivare Lei: il proxy non se ne occupa. Lo disattivi nel Suo browser con i passaggi qui sotto, poi esegua un test di fuga WebRTC proprio sul dispositivo e sulla rete che Le interessano, per confermare che il Suo vero IP non compare più. Conviene verificarlo di persona invece di fidarsi di qualsiasi affermazione, questa compresa.

Non deve affidarsi a un singolo strumento. WebRTC si può ridurre anche a livello di browser, e vale la pena sapere come. In Firefox può aprire about:config e impostare media.peerconnection.enabled su false, il che spegne la funzione. Chrome non offre un interruttore nativo, quindi di solito si ricorre a un’estensione ben recensita che blocca WebRTC, anche se su un dispositivo gestito potrebbe non poterne aggiungere una.

Sui dispositivi mobili il quadro cambia a seconda della piattaforma. Safari su iOS è più restrittivo su ciò che WebRTC consegna a una pagina, mentre Chrome su Android si comporta più o meno come su desktop. Quindi, se si chiede se su iOS ci siano fughe via WebRTC, possono esserci, solo in misura più limitata che su un browser desktop.

Anche il DNS ha una sua opzione a livello di browser che merita una menzione. DNS over HTTPS, o DoH, manda le Sue richieste DNS a un resolver su un canale cifrato invece che a quello predefinito della rete, ed è da lì che molti partono quando leggono per la prima volta di fughe DNS. Nessuna di queste sostituisce i test. Sono leve da provare, e poi verificare.

Non è tenuto a credere sulla parola a una frase di marketing, e non dovrebbe nemmeno essercene bisogno. Un test di fuga richiede circa un minuto. Apra una pagina di test di fughe DNS e WebRTC, un servizio di verifica neutrale come browserleaks.com o ipleak.net: Le mostrerà a quali resolver arrivano le Sue richieste DNS e quale IP pubblico una pagina può vedere di Lei, WebRTC incluso.

Lo faccia una volta sulla rete che Le interessa davvero. Se il resolver elencato è quello del Suo provider o della rete locale, il Suo DNS ha una fuga. Se l’IP pubblico mostrato è il Suo indirizzo, è WebRTC o la connessione a esporlo. Attivi il Suo strumento ed esegua di nuovo lo stesso controllo per vedere se i numeri cambiano.

La pagina /proof di TrickyBird verifica un’altra cosa, ed è bene non confonderle. Le fa vedere dove finisce davvero l’indirizzo del sito che apre: nella barra degli indirizzi e negli header Referer e Origin che il Suo browser invia sta codificato dentro il nostro indirizzo, non scritto per esteso, e nel codice sorgente della pagina compare nell’unico punto che la pagina Le indica. È un controllo sulle fughe di dominio, non un test DNS o WebRTC, e non mostra alcun IP né Le dice se WebRTC sta esponendo il Suo. Per quella verifica usi una delle pagine di test di fuga qui sopra e disattivi WebRTC nel Suo browser. Uno strumento che vale la pena usare è quello che regge quando qualcuno apre gli strumenti per sviluppatori e va a guardare. È lo stesso metro da applicare a qualunque proxy web gratuito, il nostro compreso.

Per le basi da cui parte questa guida, continui con queste letture.

• Che cos’è un proxy web?
• Proxy web o VPN
• Usare un proxy è legale?
• Sbloccare un sito
• La nostra politica su log e sicurezza