Perdite WebRTC: perché il tuo indirizzo reale può comparire anche dietro un proxy
WebRTC esiste perché i browser possano comunicare direttamente tra loro per chiamate e condivisione dello schermo. Per farlo devono scoprire gli indirizzi su cui sono raggiungibili, e il processo di scoperta è ciò a cui si riferisce una «perdita WebRTC».
I candidati ICE in un paragrafo
Quando una pagina crea un RTCPeerConnection e avvia un'offerta, il browser raccoglie dei candidati: modi in cui un altro peer potrebbe raggiungerlo. Un candidato host è l'indirizzo di un'interfaccia locale. Un candidato server-reflexive (srflx) è l'indirizzo pubblico da cui un server STUN ha visto arrivare la richiesta. Un candidato relay è l'indirizzo di un server TURN. Ogni candidato viene consegnato alla pagina in una riga di testo che contiene l'indirizzo, ed è così che uno script può leggerlo, senza che venga mai effettuata alcuna chiamata.
Dove sta la perdita
Il candidato srflx è quello che conta. Per ottenerlo, il browser invia un piccolo pacchetto UDP a un server STUN, che risponde con l'indirizzo che ha visto. Se il tuo traffico HTTP passa attraverso un proxy ma quello UDP no, il server STUN vede la tua connessione reale, e la pagina ora ha un indirizzo che non coincide con quello visto dal server web. Quel disaccordo è la classica perdita. Una pagina diagnostica può mostrarla confrontando i due.
Nota che cosa succede e che cosa no. Nessun contenuto multimediale viene catturato. Non è coinvolto alcun permesso per microfono o fotocamera. Il pacchetto va a qualunque server STUN la pagina abbia indicato, quindi quel server, come ogni server che contatti, vede il tuo indirizzo.
Che cosa è cambiato nei browser
I candidati host un tempo esponevano indirizzi LAN privati come 192.168.1.23, utili per il fingerprinting di una rete domestica. I browser moderni li sostituiscono con nomi mDNS generati casualmente che terminano in .local, così una pagina vede un nome opaco anziché un indirizzo. Una diagnostica che riporta «mascherato dal browser» descrive questi. Firefox e Brave offrono anche impostazioni che impediscono la raccolta di candidati al di fuori del proxy, e alcune estensioni bloccano del tutto WebRTC.
Configurazioni sicure con i proxy
Funzionano tre approcci, con costi diversi. Disattivare WebRTC previene la perdita e rompe ogni sito che ne ha bisogno. Forzare WebRTC a usare solo il percorso del proxy (la modalità «proxy-safe» in alcuni browser) mantiene funzionanti le chiamate quando il proxy supporta UDP o TURN, altrimenti non produce alcun candidato pubblico. Lasciare che WebRTC si comporti normalmente è corretto solo quando il proxy trasporta tutto il traffico, come di solito fa una VPN a livello di sistema.
Quale sia giusto dipende dal lavoro. Per un profilo isolato del browser che deve apparire in un unico luogo, la regola è semplice: l'indirizzo che WebRTC espone deve essere lo stesso che vede il server web, oppure nessuno. Qualsiasi altra cosa è una contraddizione che un sito può notare senza alcuno strumento speciale.
Leggere il risultato
Una diagnostica mostra i candidati osservati nell'arco di pochi secondi e confronta ogni candidato pubblico con l'indirizzo da cui è stata raggiunta la pagina. «Nessuno esposto» con alcuni candidati mascherati è un risultato normale e sano per un browser che mantiene WebRTC dentro il proxy. Un indirizzo pubblico diverso da quello della pagina è ciò che va corretto.
