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 una macchina che Lei non controlla, e porta con sé il nome del sito che sta per aprire. 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.

La cosa importante è notare cosa trapela. Una fuga DNS non rivela cosa ha inviato o letto. Rivela dove stava andando, che 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 fianco a fianco. Una fuga DNS dice alla rete i nomi dei posti che visita. Una fuga WebRTC dice a un sito web il numero che identifica la Sua connessione. Se si trova su un dispositivo o una rete controllati da qualcun altro, quella coppia è tutta la partita.

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 voleva.

• 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 si guadagna il posto, 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, quindi il Suo browser contatta soltanto TrickyBird. La risoluzione del sito che vuole davvero avviene dalla nostra parte, non sul Suo dispositivo. In parole semplici, il nome host della destinazione resta fuori dalle query DNS che il Suo browser invia alla rete intorno a Lei. Quindi, se si sta chiedendo se un proxy web nasconde il Suo IP e tiene le Sue destinazioni fuori dal resolver locale, è questo il lavoro che questo schema fa. È la stessa assenza di fughe di dominio che tiene il nome della destinazione fuori dalla barra degli indirizzi e dalla pagina (veda quali siti al momento si visualizzano in modo pulito 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.

C’è un limite onesto da dichiarare con chiarezza. 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. È un logging minimo, di breve durata e verificabile, e il punto è che può controllarlo invece di crederci sulla parola. È una postura molto diversa da una promessa assoluta che Lei non ha modo di verificare. Veda come si confrontano 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.

Tratti quindi WebRTC come qualcosa che disattiva Lei stesso, non come qualcosa di cui si occupa il proxy. 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.

Su mobile il quadro cambia con la 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 iOS abbia fughe via WebRTC, può averne, solo in modo meno libero di 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 risoluzioni 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 deve fidarsi di una frase di marketing, e non dovrebbe doverlo fare. Un test di fuga richiede circa un minuto. Apra una pagina di test di fughe DNS e WebRTC, un verificatore neutrale come browserleaks.com o ipleak.net, e Le mostrerà quali resolver raggiungono le Sue risoluzioni 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. Mostra che l’indirizzo del sito che apre non compare mai nella barra degli indirizzi, nel codice sorgente della pagina né negli header Referer e Origin che il Suo browser invia. È 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 questo, 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 che vale la pena applicare a qualunque proxy web gratuito, il nostro compreso.

Continui a leggere se vuole le fondamenta di questa guida.

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