Kan ik WebRTC volledig uitschakelen?

Ja, in Firefox: about:config → media.peerconnection.enabled → false. Chromium-browsers hebben geen schakelaar zonder extensie (uBlock Origin heeft een instelling; WebRTC Network Limiter van Google is een andere). Als u dit uitschakelt, wordt elke site verbroken die WebRTC gebruikt om te bellen.

Beschermt een VPN tegen WebRTC-lekken?

Afhankelijk van de browser. Moderne browsers onthullen het publieke IP-adres niet aan JavaScript zonder toestemming van de media, dus een passief WebRTC-lek via een VPN komt zelden voor bij standaardinstellingen. Maar als de pagina getUserMedia aanroept en de gebruiker accepteert, kunnen de verzamelde kandidaten het openbare IP-adres van de VPN bevatten – dat wordt verwacht – of het echte IP-adres als de IPv6-stack rond de VPN lekt.

Wat is een STUN-server en wie beheert deze?

STUN-servers weerspiegelen alleen het bron-IP en de poort die ze zien: klein, staatloos, gratis te gebruiken. Google beheert een openbare STUN-server op stun.l.google.com:19302; Twilio, Mozilla en anderen beheren die van hen. Veel apps gebruiken standaard die van Google. STUN-servers zien alleen dat er een verzoek heeft plaatsgevonden; ze zien de media die erna komen niet.

Altijd, volgens specificatie. De DTLS-handshake leidt sleutels af voor SRTP, die de media versleutelt. Het datakanaal is gecodeerd door DTLS. U kunt de codering niet uitschakelen. End-to-end-codering is een aparte eigenschap: groepsoproepen via een SFU kunnen alleen E2EE zijn als de applicatie dit expliciet implementeert (Zoom en Signal doen dat; veel eenvoudigere apps niet).

Waarom is browser-naar-browser video nu zo goed vergeleken met tien jaar geleden?

Codec-hardwareversnelling (AV1, VP9, H.264 op GPU), congestiecontrole op maat voor realtime media (het congestiecontrole-algoritme van Google) en betere NAT-traversal waardoor directe paden vaker mogelijk zijn. Deze bevinden zich allemaal in WebRTC.

WebRTC uitgelegd: het browserprotocol dat videogesprekken mogelijk maakt

WebRTC is het protocol waarmee twee browsers rechtstreeks met elkaar kunnen praten: peer-to-peer, lage latentie, met audio, video of gegevens. Het maakte browsergebaseerd videobellen levensvatbaar. Het creëerde ook een geheel nieuwe categorie van privacylekken, omdat browsers, om elkaar via NAT's te vinden, naar hun openbare IP's moeten zoeken op een manier die deze aan JavaScript onthult.

De volledige artikeltekst vindt u hieronder in het Engels.

WebRTC (Web Real-Time Communication) is een set API's die in elke moderne browser is ingebouwd en waarmee webpagina's directe peer-to-peer-verbindingen met elkaar of met native applicaties tot stand kunnen brengen. Het ondersteunt Google Meet, Zoom in de browser, Discord's voicechat, Twitter Spaces tegenwoordig en talloze kleinere services. Zonder WebRTC zou realtime browservideo nog steeds een Flash-or-bust-voorstel zijn.

Wat de specificatie bevat

WebRTC bundelt drie hoofd-API's:

getUserMedia — geeft toegang tot de camera en microfoon
RTCPeerConnection — beheert de daadwerkelijke peer-verbinding: codec-onderhandeling, encryptie, NAT-traversal, congestiecontrole
RTCDataChannel — verzendt willekeurige binaire of tekstgegevens via de verbinding, peer-to-peer

De verbinding zelf maakt gebruik van ICE (Interactive Connectivity Establishment) voor NAT-traversal, DTLS voor handshake-encryptie en SRTP voor media-encryptie. De hele verbinding is standaard end-to-end gecodeerd; je kunt het niet uitschakelen.

Hoe peers elkaar vinden

Het moeilijkste deel van peer-to-peer is dat beide peers meestal achter NAT staan. WebRTC gebruikt ICE om mogelijke netwerkpaden te ontdekken:

De browser vraagt een STUN-server "hoe zien mijn openbare IP en poort eruit?" De STUN-server antwoordt met het bronadres dat hij heeft gezien - wat de externe toewijzing van de NAT is.
De browser verzamelt al zijn kandidaat-adressen: lokale IP's op het LAN, het door STUN ontdekte openbare IP-adres, optioneel een TURN-relais als de NAT niet kan worden gepasseerd.
De peers wisselen kandidatenlijsten uit via een signaleringskanaal (meestal een WebSocket met de server van de applicatie).
Ze proberen verbinding te maken met elke combinatie totdat er één slaagt.

Het IP-lekprobleem

De stap voor het verzamelen van kandidaten is de bron van het WebRTC IP-lek. JavaScript kan de browser vragen om ICE-kandidaten te verzamelen – en de browser zal de resulterende openbare en lokale IP’s aan de pagina onthullen. Een pagina die u wil volgen, kunt u new RTCPeerConnection().createDataChannel(...) noemen, de kandidaten verzamelen en nu uw echte IP-adres kennen, ongeacht eventuele verduistering van de HTTP-laag.

Dit werd ontdekt in 2015 en werd al snel een standaard privacy-voetpistool. WebRTC-lekken zijn de reden waarom een persoon op een VPN nog steeds zijn echte IP zichtbaar kan hebben voor een website die de juiste weg vraagt.

Wat eraan is gedaan

Browserleveranciers hebben gereageerd door geleidelijk te beperken wat kandidaten een pagina kan zien:

Standaardgedrag in de moderne tijd Chrome/Firefox/Safari mag alleen lokale IP's onthullen (die op het LAN - meestal 192.168.x of 10.x) zonder expliciete toestemming.
mDNS-hostnamen vervangen het lokale IP-adres voor verbindingen - in plaats van 192.168.1.42 te onthullen, gebruikt de browser een gerandomiseerde .local hostname.
Als een pagina getUserMedia aanroept (bijvoorbeeld een echt videogesprek), zal de browser alle kandidaten verzamelen, inclusief openbare IP - op dat moment heb je toch media-toestemming verleend.

Het resultaat: passieve WebRTC IP-lekken zijn grotendeels gesloten in de standaardinstellingen. Er bestaan nog steeds sites die op agressieve wijze kandidaten verzamelen, en gebruikers met oude browsers of ontspannen instellingen zijn nog steeds kwetsbaar. Onze WebRTC-lekkengids behandelt verificatie.

Waarom peer-to-peer belangrijk is

Voor tweepersoonsgesprekken verzendt WebRTC media rechtstreeks tussen peers, waarbij de signaleringsserver alleen wordt gebruikt voor het instellen van de verbinding. De video passeert de servers van de applicatie niet. Dit is aanzienlijk goedkoper in gebruik (geen bandbreedtekosten voor media) en een aanzienlijk lagere latentie (geen extra hops). Voor groepsgesprekken is meestal een Selective Forwarding Unit (SFU) nodig – een server die media doorstuurt – maar de codering is nog steeds end-to-end als deze correct is geconfigureerd.

Waar WebRTC naartoe gaat

De volgende grote stap is WebTransport (een low-level QUIC-gebaseerde API voor niet-real-time bidirectionele streams) en WebCodecs (ruwe toegang tot encoder-/decoderhardware). Samen ontgrendelen ze nieuwe gebruiksscenario's zoals cloudgaming, videotranscodering met lage latentie in de browser en bulk peer-to-peer bestandsoverdracht met betere congestiecontrole dan de RTCDataChannel.

WebRTC zelf wordt ook gemoderniseerd – de oorspronkelijke Plan B SDP-semantiek wordt geleidelijk afgeschaft ten gunste van het Unified Plan, en het API-oppervlak wordt schoner voor ontwikkelaars.

Veelgestelde vragen

Kan ik WebRTC volledig uitschakelen?: Ja, in Firefox: about:config → <code>media.peerconnection.enabled</code> → false. Chromium-browsers hebben geen schakelaar zonder extensie (uBlock Origin heeft een instelling; WebRTC Network Limiter van Google is een andere). Als u dit uitschakelt, wordt elke site verbroken die WebRTC gebruikt om te bellen.
Beschermt een VPN tegen WebRTC-lekken?: Afhankelijk van de browser. Moderne browsers onthullen het publieke IP-adres niet aan JavaScript zonder toestemming van de media, dus een passief WebRTC-lek via een VPN komt zelden voor bij standaardinstellingen. Maar als de pagina getUserMedia aanroept en de gebruiker accepteert, kunnen de verzamelde kandidaten het openbare IP-adres van de VPN bevatten – dat wordt verwacht – of het echte IP-adres als de IPv6-stack rond de VPN lekt.
Wat is een STUN-server en wie beheert deze?: STUN-servers weerspiegelen alleen het bron-IP en de poort die ze zien: klein, staatloos, gratis te gebruiken. Google beheert een openbare STUN-server op stun.l.google.com:19302; Twilio, Mozilla en anderen beheren die van hen. Veel apps gebruiken standaard die van Google. STUN-servers zien alleen dat er een verzoek heeft plaatsgevonden; ze zien de media die erna komen niet.
Is WebRTC gecodeerd?: Altijd, volgens specificatie. De DTLS-handshake leidt sleutels af voor SRTP, die de media versleutelt. Het datakanaal is gecodeerd door DTLS. U kunt de codering niet uitschakelen. End-to-end-codering is een aparte eigenschap: groepsoproepen via een SFU kunnen alleen E2EE zijn als de applicatie dit expliciet implementeert (Zoom en Signal doen dat; veel eenvoudigere apps niet).
Waarom is browser-naar-browser video nu zo goed vergeleken met tien jaar geleden?: Codec-hardwareversnelling (AV1, VP9, H.264 op GPU), congestiecontrole op maat voor realtime media (het congestiecontrole-algoritme van Google) en betere NAT-traversal waardoor directe paden vaker mogelijk zijn. Deze bevinden zich allemaal in WebRTC.