Voinko poistaa WebRTC:n kokonaan käytöstä?

Kyllä, Firefoxissa: about:config → media.peerconnection.enabled → false. Chromium-selaimet eivät näytä kytkintä ilman laajennusta (uBlock Originilla on asetus; Googlen WebRTC Network Limiter on toinen). Poistaminen käytöstä katkaisee sivustot, jotka käyttävät WebRTC:tä soittamiseen.

Suojaako VPN WebRTC-vuodoilta?

Riippuu selaimesta. Nykyaikaiset selaimet eivät paljasta julkista IP-osoitetta JavaScriptille ilman median lupaa, joten passiivinen WebRTC-vuoto VPN:n kautta on oletusasetuksissa harvinaista. Mutta jos sivu kutsuu getUserMediaa ja käyttäjä hyväksyy, kerätyt ehdokkaat voivat sisältää VPN:n julkisen IP-osoitteen – se on odotettavissa – tai todellisen IP-osoitteen, jos IPv6-pino vuotaa VPN:n ympäriltä.

Mikä on STUN-palvelin ja kuka niitä pyörittää?

STUN-palvelimet heijastavat vain näkemäänsä lähde-IP-osoitetta ja porttia – pieniä, tilattomia, vapaasti käytettäviä. Googlella on julkinen STUN-palvelin osoitteessa stun.l.google.com:19302; Twilio, Mozilla ja muut ylläpitävät omaansa. Monet sovellukset käyttävät Googlen oletuksena. STUN-palvelimet näkevät vain pyynnön tapahtuneen; he eivät näe mediaa, joka virtaa jälkeen.

Aina, spesifikaatioiden mukaan. DTLS-kättely johtaa avaimet SRTP:lle, joka salaa median. Datakanava on salattu DTLS:llä. Et voi poistaa salausta käytöstä. Päästä päähän -salaus on erillinen ominaisuus – ryhmäpuhelut SFU:n kautta voivat olla E2EE-muotoisia vain, jos sovellus toteuttaa sen nimenomaisesti (Zoom, Signal tekee; monet yksinkertaisemmat sovellukset eivät).

Miksi selaimen välinen video on niin hyvä nyt verrattuna vuosikymmen sitten?

Koodekin laitteistokiihdytys (AV1, VP9, H.264 grafiikkasuorittimessa), reaaliaikaiseen mediaan räätälöity ruuhkanhallinta (Googlen ruuhkanhallintaalgoritmi) ja parempi NAT-läpikulku mahdollistaa suorien polkujen useammin. Kaikki ne ovat WebRTC:n sisällä.

WebRTC selittää: Selainprotokolla, joka mahdollistaa videopuhelut

WebRTC on protokolla, jonka avulla kaksi selainta keskustelevat toistensa kanssa suoraan – peer to peer, alhainen latenssi, äänen, videon tai datan kanssa. Se teki selainpohjaisista videopuheluista elinkelpoisia. Se loi myös täysin uuden tietosuojavuotojen luokan, koska löytääkseen toisensa NAT:ien kautta, selaimet joutuvat etsimään julkisia IP-osoitteitaan tavalla, joka paljastaa ne JavaScriptille.

Artikkelin koko runko on englanniksi alla.

WebRTC (Web Real-Time Communication) on joukko API-liittymiä, jotka on sisäänrakennettu jokaiseen nykyaikaiseen selaimeen, jonka avulla verkkosivut voivat muodostaa suoria vertaisyhteyksiä keskenään tai alkuperäisten sovellusten kanssa. Se tarjoaa Google Meetin, selaimen zoomauksen, Discordin äänichatin, Twitter Spaces -palvelun ja lukemattomia pienempiä palveluita. Ilman WebRTC:tä reaaliaikainen selainvideo olisi edelleen Flash-or-Bust-ehdotus.

Mitä tekninen tieto sisältää

WebRTC yhdistää kolme pääsovellusliittymää:

getUserMedia — käyttää kameraa ja mikrofoni
RTCPeerConnection — hallitsee todellista vertaisyhteyttä: koodekkineuvottelut, salaus, NAT-läpikulku, ruuhkanhallinta
RTCDataChannel — lähettää mielivaltaisen binaarisen yhteyden tai tekstidataa peer-to-peer

Yhteys itse käyttää ICE:tä (Interactive Connectivity Establishment) NAT-läpikulkuun, DTLS:ää kättelyn salaukseen ja SRTP:tä median salaukseen. Koko yhteys on oletusarvoisesti salattu päästä päähän; et voi sammuttaa sitä.

Kuinka vertaiset löytävät toisensa

Peer-to-peer-verkon vaikein osa on, että molemmat vertaiskäyttäjät ovat yleensä NAT:n takana. WebRTC käyttää ICE:tä mahdollisten verkkopolkujen löytämiseen:

Selain kysyy STUN-palvelimelta "miltä julkisen IP-osoitteeni ja porttini näyttävät?" STUN-palvelin vastaa näkemäänsä lähdeosoitteella – joka on NAT:n ulkoinen kartoitus.
Selain kerää kaikki ehdokasosoitteensa: paikalliset IP-osoitteet lähiverkossa, STUNin löytämä julkinen IP-osoite, valinnaisesti TURN-välitys, jos NAT-osoitetta ei voida läpikäydä kanavan kautta. (yleensä WebSocket sovelluksen palvelimelle).
He yrittävät muodostaa yhteyden jokaisella yhdistelmällä, kunnes yksi onnistuu.

IP-vuotoongelma

Ehdokaskeräysvaihe on WebRTC-IP-vuodon lähde. JavaScript voi pyytää selainta aloittamaan ICE-ehdokkaiden keräämisen – ja selain paljastaa tuloksena olevat julkiset ja paikalliset IP-osoitteet sivulle. Sivu, joka haluaa seurata voit soittaa new RTCPeerConnection().createDataChannel(...), kerätä ehdokkaat ja tietää nyt todellisen IP-osoitteesi riippumatta HTTP-kerroksen hämärtymisestä.

Tämä löydettiin vuonna 2015, ja siitä tuli nopeasti standardijalka-ase. WebRTC-vuotojen vuoksi VPN-verkon käyttäjä voi silti nähdä oikean IP-osoitteensa verkkosivustolle, joka kysyy oikeaa tietä.

Mitä asialle on tehty

Selaintoimittajat ovat reagoineet rajoittamalla asteittain sitä, mitä ehdokkaita sivu voi nähdä:XPLZfa5PLZXXXX Chrome/Firefox/Safari paljastaa vain paikalliset IP-osoitteet (lähiverkon IP-osoitteet – yleensä 192.168.x tai 10.x) ilman nimenomaista lupaa.

mDNS-isäntänimet korvaavat yhteyksien paikallisen IP-osoitteen – 192.192.168.1.1,XPLZ68.1-selaimen1,XPL2-käytön1. isäntänimi.

IJos sivu kutsuu getUserMedia:tä (esim. todellinen videopuhelu), selain kerää täydet ehdokkaat, mukaan lukien julkisen IP-osoitteen – siinä vaiheessa olet joka tapauksessa myöntänyt medialle luvan.

Tulos: Passiiviset WebRTC-IP-vuotot ovat useimmiten suljettuina oletusasetuksissa. Ehdokkaita aggressiivisesti kerääviä sivustoja on edelleen olemassa, ja käyttäjät, joilla on vanhat selaimet tai rennommat asetukset, ovat edelleen haavoittuvia. WebRTC-vuotooppaamme kattaa todentamisen.

`Miksi vertaisyhteydellä on väliä`

Kahden hengen puheluissa WebRTC lähettää mediaa suoraan vertaisten välillä, ja signalointipalvelinta käytetään vain yhteyden muodostamiseen. Video ei kulje sovelluksen palvelimien läpi. Tämä on dramaattisesti halvempaa käyttää (ei kaistanleveyskustannuksia medialle) ja dramaattisesti alhaisempi latenssi (ei ylimääräisiä hyppyjä). Ryhmäpuhelut tarvitsevat tavallisesti Selective Forwarding Unit (SFU) -palvelimen, joka välittää mediaa, mutta salaus on silti päästä päähän, jos se on määritetty oikein.

`Missä WebRTC on menossa`

Seuraava tärkeä askel on WebTransportX-alain-bidirect-API-pohjainen Q80X- streamit) ja WebCodecs (raaka pääsy kooderi-/dekooderilaitteistoon). Yhdessä ne avaavat uusia käyttötapoja, kuten pilvipelaamista, matalan viiveen videon transkoodausta selaimessa ja massasiirtoa vertaistiedostojen välillä paremmalla ruuhkanhallinnalla kuin RTCDataChannel.

Itse WebRTC:tä myös modernisoidaan – alkuperäinen Plan B SDP:n semantiikka poistetaan käytöstä Unified Planin hyväksi, ja API-pinta on tulossa puhtaammaksi kehittäjille.

`Usein kysytyt kysymykset`

Voinko poistaa WebRTC:n kokonaan käytöstä?: Kyllä, Firefoxissa: about:config → <code>media.peerconnection.enabled</code> → false. Chromium-selaimet eivät näytä kytkintä ilman laajennusta (uBlock Originilla on asetus; Googlen WebRTC Network Limiter on toinen). Poistaminen käytöstä katkaisee sivustot, jotka käyttävät WebRTC:tä soittamiseen.
Suojaako VPN WebRTC-vuodoilta?: Riippuu selaimesta. Nykyaikaiset selaimet eivät paljasta julkista IP-osoitetta JavaScriptille ilman median lupaa, joten passiivinen WebRTC-vuoto VPN:n kautta on oletusasetuksissa harvinaista. Mutta jos sivu kutsuu getUserMediaa ja käyttäjä hyväksyy, kerätyt ehdokkaat voivat sisältää VPN:n julkisen IP-osoitteen – se on odotettavissa – tai todellisen IP-osoitteen, jos IPv6-pino vuotaa VPN:n ympäriltä.
Mikä on STUN-palvelin ja kuka niitä pyörittää?: STUN-palvelimet heijastavat vain näkemäänsä lähde-IP-osoitetta ja porttia – pieniä, tilattomia, vapaasti käytettäviä. Googlella on julkinen STUN-palvelin osoitteessa stun.l.google.com:19302; Twilio, Mozilla ja muut ylläpitävät omaansa. Monet sovellukset käyttävät Googlen oletuksena. STUN-palvelimet näkevät vain pyynnön tapahtuneen; he eivät näe mediaa, joka virtaa jälkeen.
Onko WebRTC salattu?: Aina, spesifikaatioiden mukaan. DTLS-kättely johtaa avaimet SRTP:lle, joka salaa median. Datakanava on salattu DTLS:llä. Et voi poistaa salausta käytöstä. Päästä päähän -salaus on erillinen ominaisuus – ryhmäpuhelut SFU:n kautta voivat olla E2EE-muotoisia vain, jos sovellus toteuttaa sen nimenomaisesti (Zoom, Signal tekee; monet yksinkertaisemmat sovellukset eivät).
Miksi selaimen välinen video on niin hyvä nyt verrattuna vuosikymmen sitten?: Koodekin laitteistokiihdytys (AV1, VP9, H.264 grafiikkasuorittimessa), reaaliaikaiseen mediaan räätälöity ruuhkanhallinta (Googlen ruuhkanhallintaalgoritmi) ja parempi NAT-läpikulku mahdollistaa suorien polkujen useammin. Kaikki ne ovat WebRTC:n sisällä.