A WebRTC del tuo proxy non importa nulla

Perché succede

WebRTC esiste perché i browser possano parlarsi direttamente — videochiamate, voce, dati peer-to-peer — senza far passare tutto da un server. Le connessioni dirette sono l'intero scopo, e per stabilirne una il browser deve scoprire a quali indirizzi è raggiungibile.

Lo fa chiedendolo a un server STUN. Il browser invia un pacchetto UDP a un endpoint STUN pubblico, e il server risponde con l'indirizzo sorgente che ha osservato. Quello è il tuo IP pubblico, riflesso indietro e consegnato a JavaScript come candidato ICE.

Il dettaglio cruciale: tutto questo avviene su UDP, fuori dal percorso HTTP. Un proxy HTTP o SOCKS configurato nel browser gestisce il traffico HTTP. Il pacchetto STUN non lo usa. Le tue pagine si caricano attraverso il proxy, la tua scoperta WebRTC no, e da nessuna parte viene segnalato un problema.

È questo a rendere questa modalità di guasto diversa dalle altre. Un proxy rotto produce errori. Un leak WebRTC produce silenzio.

Cosa vede davvero un sito

L'intero attacco è abbastanza corto da leggersi tutto d'un fiato:

const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});
pc.onicecandidate = e => { if (e.candidate) console.log(e.candidate.candidate); };
pc.createDataChannel('');
pc.createOffer().then(o => pc.setLocalDescription(o));

Ogni riga di candidato contiene un indirizzo e un tipo. Tre tipi contano:

Se l'indirizzo srflx è diverso da quello da cui arrivano le tue richieste HTTP, hai consegnato al sito una contraddizione che non ha dovuto nemmeno cercare: la pagina crede che tu sia a Francoforte e WebRTC dice che sei a Milano.

mDNS risolve la metà più piccola

Chrome distribuisce l'offuscamento mDNS degli indirizzi locali dalla versione 76. Invece di 192.168.1.42, i candidati host compaiono come UUID casuali che finiscono in .local. È una cosa davvero buona ed è attiva per impostazione predefinita.

È anche spesso fraintesa. mDNS riguarda solo i candidati host — il tuo indirizzo LAN. Non fa nulla per i candidati srflx, che sono quelli che portano il tuo IP pubblico. Le guide che ti dicono di attivare chrome://flags/#enable-webrtc-hide-local-ips-with-mdns e dichiarare risolto il problema stanno descrivendo una soluzione per la metà meno importante.

Anche qui c'è un segnale di secondo ordine. Il nome host offuscato .local è stabile per tutta la sessione di navigazione, e il numero di candidati host riflette quante interfacce di rete ha la macchina. Un profilo che dichiara sei interfacce sembra una macchina con diversi adattatori VPN — non l'aspetto di un normale portatile.

Quattro modi di gestirlo

I browser antidetect offrono in genere una qualche versione di questi quattro. Non sono equivalenti, e il migliore dipende da cosa stai facendo.

Disattivato del tutto

Nessun RTCPeerConnection, nessun candidato, nessun leak. Pulito, ma rilevabile: WebRTC è standard in ogni browser da un decennio, e un Chrome che ne è privo è insolito. Va bene per account che non toccano mai chiamate o streaming. Sbagliato per qualsiasi cosa che li usi — alcuni siti oggi usano la presenza di WebRTC come prova di vitalità.

UDP disattivato

L'API esiste e risponde, ma non esce alcun UDP, quindi non viene prodotto alcun candidato srflx. Meno vistoso della rimozione completa, e chiude davvero il leak. Rompe anche il funzionamento reale di WebRTC, cosa che può contare o no.

Reale

Lascia passare tutto senza toccarlo. È corretto in una sola situazione: quando il tuo proxy gestisce anche l'UDP. Un proxy SOCKS5 con associazione UDP, o una VPN a livello di sistema, instrada il pacchetto STUN attraverso la stessa uscita del tuo traffico HTTP, e l'indirizzo riflesso è quello del proxy. In quella configurazione, WebRTC reale è l'opzione più autentica a disposizione. Verificalo invece di darlo per scontato.

Alterato

Sostituisci l'indirizzo pubblico scoperto con l'uscita del proxy prima che arrivi a JavaScript. WebRTC continua a funzionare, i candidati ci sono nella quantità consueta e concordano con il percorso HTTP. È la configurazione più convincente quando è fatta a livello di engine — la sostituzione deve avvenire dove i candidati vengono generati, non in uno script di contenuto, altrimenti i due non concordano e sei tornato al punto di partenza.

Testarlo come si deve

Quasi tutti i "test di leak WebRTC" riportano soltanto se è comparso un indirizzo pubblico. Non è quella la domanda. La domanda è se corrisponde al tuo proxy.

La procedura affidabile richiede due minuti:

1. Prendi nota dell'indirizzo di uscita che il proxy dovrebbe darti.
2. Carica browserleaks.com/webrtc nel profilo e leggi la riga dell'IP pubblico.
3. Confronta. Uguale va bene. Diverso è un leak, anche se l'indirizzo diverso non è quello di casa tua — un indirizzo da datacenter che compare accanto a un percorso HTTP residenziale è già di per sé una contraddizione.
4. Ripeti con il proxy del profilo disattivato. Se il valore non cambia, WebRTC non sta passando affatto dal proxy e la corrispondenza di prima era fortuna.

È quel quarto passo che la gente salta, ed è quello che smaschera una configurazione sbagliata.

Dove si colloca rispetto a tutto il resto

WebRTC merita la sua fama, ma vale la pena tenerlo nelle giuste proporzioni. È un segnale, ed è uno dei più facili da chiudere in modo definitivo: configuralo una volta per profilo, verificalo una volta e resta a posto.

Quello che non è, è un sostituto di tutto il resto. Un profilo con una gestione WebRTC perfetta e un fingerprint incoerente verrà beccato dall'incoerenza. Un profilo dietro un proxy da datacenter verrà beccato dall'ASN, che WebRTC perda o no.

Il motivo per sistemarlo per primo non è che sia il segnale più importante. È che è l'unico che fallisce in silenzio, e i guasti silenziosi sono quelli che scopri da un'email di sospensione.