Kan jeg deaktivere WebRTC helt?

Ja, i Firefox: about:config → media.peerconnection.enabled → false. Chromium-browsere afslører ikke en skifte uden en udvidelse (uBlock Origin har en indstilling; WebRTC Network Limiter fra Google er en anden). Deaktivering ødelægger ethvert websted, der bruger WebRTC til opkald.

Beskytter en VPN mod WebRTC-lækager?

Afhænger af browseren. Moderne browsere afslører ikke den offentlige IP til JavaScript uden medietilladelse, så et passivt WebRTC-læk gennem en VPN er sjældent i standardindstillingerne. Men hvis siden kalder getUserMedia, og brugeren accepterer, kan de indsamlede kandidater inkludere VPN'ens offentlige IP - det forventes - eller den rigtige IP, hvis IPv6-stakken lækker rundt i VPN'en.

Hvad er en STUN-server, og hvem kører dem?

STUN-servere afspejler bare den kilde-IP og port, de ser - små, statsløse, gratis at køre. Google driver en offentlig STUN-server på stun.l.google.com:19302; Twilio, Mozilla og andre kører deres. Mange apps bruger Googles som standard. STUN-servere ser kun, at der er sket en anmodning; de ser ikke medierne, der flyder efter.

Altid efter spec. DTLS-håndtrykket udleder nøgler til SRTP, som krypterer mediet. Datakanalen er krypteret af DTLS. Du kan ikke deaktivere kryptering. End-to-end-kryptering er en separat egenskab — gruppeopkald gennem en SFU kan kun være E2EE, hvis applikationen eksplicit implementerer det (Zoom, Signal gør det, mange simplere apps gør det ikke).

Hvorfor er browser-til-browser-video så god nu sammenlignet med for ti år siden?

Codec-hardwareacceleration (AV1, VP9, H.264 på GPU), overbelastningskontrol skræddersyet til medier i realtid (Googles overbelastningskontrolalgoritme) og bedre NAT-gennemgang, hvilket gør direkte stier mulige oftere. Som alle er inde i WebRTC.

WebRTC forklaret: Browserprotokollen, der driver videoopkald

WebRTC er protokollen, der lader to browsere tale direkte med hinanden - peer-to-peer, lav latenstid, med lyd, video eller data. Det gjorde browserbaserede videoopkald levedygtige. Det skabte også en helt ny kategori af privatlivslæk, for for at finde hinanden gennem NAT'er skal browsere søge efter deres offentlige IP'er på en måde, der afslører dem til JavaScript.

Hele artiklens krop findes på engelsk nedenfor.

WebRTC (Web Real-Time Communication) er et sæt API'er indbygget i enhver moderne browser, der lader websider etablere direkte peer-to-peer-forbindelser med hinanden eller med native applikationer. Det driver Google Meet, Zoom i browseren, Discords stemmechat, Twitter Spaces i deres tid og utallige mindre tjenester. Uden WebRTC ville realtidsbrowservideo stadig være et Flash-eller-bust-forslag.

Hvad specifikationen indeholder

WebRTC bundter tre hoved-API'er:

getUserMedia — får adgang til kameraet og mikrofon
RTCPeerConnection — administrerer den faktiske peer-forbindelse: codec-forhandling, kryptering, NAT-gennemgang, overbelastningskontrol
RTCDataChannel — sender forbindelsen, eller tekstforbindelsen over binær eller tekst peer-to-peer

Selve forbindelsen bruger ICE (Interactive Connectivity Establishment) til NAT-traversal, DTLS til håndtrykkryptering og SRTP til mediekryptering. Hele forbindelsen er som standard krypteret ende-til-ende; du kan ikke slå det fra.

Sådan finder peers hinanden

Den svære del af peer-to-peer er, at begge peers normalt står bag NAT. WebRTC bruger ICE til at opdage mulige netværksstier:

Browseren spørger en STUN-server "hvordan ser min offentlige IP og port ud?" STUN-serveren svarer med den kildeadresse, den så - som er NAT'ens eksterne kortlægning.
Browseren indsamler alle sine kandidatadresser: lokale IP'er på LAN'et, den STUN-opdagede offentlige IP, eventuelt et TURN-relæ, hvis NAT'en ikke kan gennemløbes, kan pege på listen over NAT'er. via en signaleringskanal (normalt en WebSocket til applikationens server).
Tde prøver at oprette forbindelse på hver kombination, indtil det lykkes.

IP-lækageproblemet

Kandidatindsamlingstrinnet er kilden til WebRTC IP-lækagen. JavaScript kan bede browseren om at begynde at indsamle ICE-kandidater - og browseren vil afsløre de resulterende offentlige og lokale IP'er til siden. En side, der ønsker at spore, kan du kalde new RTCPeerConnection().createDataChannel(...), høste kandidaterne og nu kender din rigtige IP uanset enhver HTTP-lags-obfuscation.

Dette blev opdaget i 2015 og blev hurtigt en standard privatlivsfootgun. WebRTC-lækker er grunden til, at en person på en VPN stadig kan have deres rigtige IP synlig på et websted, der spørger den rigtige vej.

Hvad er der blevet gjort ved det

Browser-leverandører har reageret ved gradvist at begrænse, hvilke kandidater en side kan se:5PLXPLZ5Dec. adfærd i moderne Chrome/Firefox/Safari er kun at afsløre lokale IP'er (dem på LAN'et - normalt 192.168.x eller 10.x) uden eksplicit tilladelse.

mDNS-værtsnavne erstatter den lokale IP for forbindelser - i stedet for at afsløre 192.168.x eller 10.x, bruger den tilfældige browser 142XPLZ.1.locom. værtsnavn.

Hvis en side kalder getUserMedia (f.eks. et rigtigt videoopkald), vil browseren samle fulde kandidater inklusive offentlig IP - på det tidspunkt har du alligevel givet medietilladelse.

Resultatet har været lukket som standard IP-indstillinger i Web. Websteder, der samler kandidater aggressivt, eksisterer stadig, og brugere med gamle browsere eller afslappede indstillinger er stadig sårbare. Vores WebRTC lækageguide dækker verifikation.

`Hvorfor peer-to-peer betyder noget`

For to-personers opkald sender WebRTC medier direkte mellem peers, hvor signalserveren kun bruges til forbindelsesopsætning. Videoen krydser ikke applikationens servere. Dette er dramatisk billigere i drift (ingen båndbreddeomkostninger for medier) og dramatisk lavere latency (ingen ekstra hop). Gruppeopkald har normalt brug for en selektiv videresendelsesenhed (SFU) - en server, der videresender medier - men krypteringen er stadig ende-til-ende, hvis den er konfigureret korrekt. streams) og WebCodecs (råadgang til encoder/dekoderhardware). Sammen låser de op for nye use cases såsom cloud-gaming, videotranskodning med lav latens i browseren og bulk peer-to-peer filoverførsel med bedre overbelastningskontrol end RTCDataChannel.

WebRTC selv er også ved at blive moderniseret — den oprindelige Plan B SDP-semantik er ved at blive udfaset til fordel for Unified Plan, og API-overfladen bliver renere for udviklere.

`Ofte stillede spørgsmål`

Kan jeg deaktivere WebRTC helt?: Ja, i Firefox: about:config → <code>media.peerconnection.enabled</code> → false. Chromium-browsere afslører ikke en skifte uden en udvidelse (uBlock Origin har en indstilling; WebRTC Network Limiter fra Google er en anden). Deaktivering ødelægger ethvert websted, der bruger WebRTC til opkald.
Beskytter en VPN mod WebRTC-lækager?: Afhænger af browseren. Moderne browsere afslører ikke den offentlige IP til JavaScript uden medietilladelse, så et passivt WebRTC-læk gennem en VPN er sjældent i standardindstillingerne. Men hvis siden kalder getUserMedia, og brugeren accepterer, kan de indsamlede kandidater inkludere VPN'ens offentlige IP - det forventes - eller den rigtige IP, hvis IPv6-stakken lækker rundt i VPN'en.
Hvad er en STUN-server, og hvem kører dem?: STUN-servere afspejler bare den kilde-IP og port, de ser - små, statsløse, gratis at køre. Google driver en offentlig STUN-server på stun.l.google.com:19302; Twilio, Mozilla og andre kører deres. Mange apps bruger Googles som standard. STUN-servere ser kun, at der er sket en anmodning; de ser ikke medierne, der flyder efter.
Er WebRTC krypteret?: Altid efter spec. DTLS-håndtrykket udleder nøgler til SRTP, som krypterer mediet. Datakanalen er krypteret af DTLS. Du kan ikke deaktivere kryptering. End-to-end-kryptering er en separat egenskab — gruppeopkald gennem en SFU kan kun være E2EE, hvis applikationen eksplicit implementerer det (Zoom, Signal gør det, mange simplere apps gør det ikke).
Hvorfor er browser-til-browser-video så god nu sammenlignet med for ti år siden?: Codec-hardwareacceleration (AV1, VP9, H.264 på GPU), overbelastningskontrol skræddersyet til medier i realtid (Googles overbelastningskontrolalgoritme) og bedre NAT-gennemgang, hvilket gør direkte stier mulige oftere. Som alle er inde i WebRTC.