Ugrás a tartalomra

WebRTC-szivárgás

WebRTC-szivárgásteszt: mit árul el egy böngészős hívás az IP-címedről

Témakör: Biztonságos a VoIP? Mit véd a böngészős hívás, és mit fed fel rólad

Szerző: · Frissítve: · Olvasási idő: 11 perc

Add hozzá a callfrombrowser.org oldalt előnyben részesített forrásként a Google keresőben

Röviden

A WebRTC-szivárgásteszt kilistázza az összes IP-címet, amelyet a böngésződ WebRTC-n keresztül átad egy weboldalnak, így észreveheted azt, amelyet el akartál rejteni, jellemzően az internetszolgáltatód címét bekapcsolt VPN mellett [1]. Telefonszámra indított böngészős hívásnál az IP-címedet a hívásszolgáltatás látja, nem a hívott fél, akinél egy hívóazonosító jelenik meg [2]. A teszt az egyik adatvédelmi és biztonsági ellenőrzés, amelyet böngészős telefonálás előtt javaslok.

A legfontosabb tények

Mi az a WebRTC-szivárgás?

Egy WebRTC-hívás előtt a böngésző összegyűjti a lehetséges hálózati útvonalakat, az úgynevezett ICE-jelölteket, és átadja őket a weboldalnak, hogy továbbítsa a másik félnek. Mindegyikben szerepel egy IP-cím, vagy egy elrejtett helyi cím helyett egy véletlenszerű .local név. Egy átlagos weboldal csak azt a nyilvános címet látja, ahonnan a kérésed érkezett; WebRTC-n keresztül egy oldal ennél többet is megtudhat [1]. Szivárgásnak számít a listában minden olyan cím, amelyet nem akartál megosztani.

A hívás további útját a WebRTC-ről, a SIP-ről és a telefonhálózatról szóló cikkemben mutatom be; a szivárgás szempontjából csak a jelöltlista számít. Az MDN megjegyzi, hogy az ebben szereplő címek mindig láthatók az oldal számára [6].

A WebRTC-szivárgásteszt által listázott címek, és mit árulnak el
JelölttípusMilyen címet mutatAdatvédelmi kockázat
hostAz eszközöd címe a helyi hálózaton, vagy egy .local végződésű véletlenszerű név, ha a böngésző elrejti [7][3]Kisebb, mint egy nyilvános címé, de az IETF szerint a privát IPv4-címek meglehetősen jelentős felületet adnak az ujjlenyomat-alapú azonosításhoz [1]
srflx (server reflexive)Az a nyilvános cím, amelyet a routered vagy a VPN-ed mutat egy STUN-szervernek [7]Magas, ha bekapcsolt VPN mellett az internetszolgáltatód címe jelenik meg [1]
relayEgy TURN-szerver címe, amely továbbítja a médiaforgalmat [7]Alacsony: a másik fél a továbbító szerver címét látja, nem a tiédet [6]; a szerver üzemeltetője viszont lát téged

Az IETF a VPN-es esetet tartja a legsúlyosabbnak, mert vannak, akik azért használnak VPN-t, hogy névtelenek maradjanak [1]. A másik két eset a privát címed, illetve egy olyan proxy, amelyet a WebRTC ellenőrzései megkerülnek, és így kiderül a valódi nyilvános címed [1].

Felfedi egy böngészős hívás az IP-címedet?

A hívásszolgáltatás előtt igen: minden weboldal látja a nyilvános címedet [1], a hívás pedig ehhez még egy médiakapcsolatot is nyit a szolgáltatás szervereihez. A vezetékes vagy mobilszámon hívott fél előtt nem: a hívás a szolgáltató átjárójánál elhagyja az internetet [8], a telefonhálózat pedig hívószámot továbbít, nem IP-címet [2]. Az alkalmazások közötti hívások viszont közvetlenül is összeköthetik a két eszközt.

Ki látja az IP-címedet a hívás típusa szerint (a hivatalos súgóoldalak alapján, 2026. november 1.)
A hívás típusaA szolgáltatásA hívott fél
Böngészőből telefonszámra (Google Voice, TwinPhone, Yolla)Igen: ő kezeli a médiakapcsolatotNem: hívóazonosítót lát [2]
Ingyenes webes tárcsázók (Call2Friends, Globfone)Igen: a Call2Friends IP-címenként korlátozza az ingyenes hívásokat, a Globfone adatvédelmi szabályzata pedig az IP-címeket is felsorolja az általa kezelt technikai adatok és naplók között [9][10]Nem: hívóazonosítót lát
Messenger, kétszereplős hívásIgenIgen: a Meta szerint az IP-címedet megkapja a másik eszköz [4]
WhatsAppIgenLáthatja, kivéve ha be van kapcsolva a Protect IP address in calls beállítás; a csoportos hívások mindig továbbító szerveren mennek át [5]
TelegramIgenLáthatja: a Telegram 2017-es bejelentése szerint a hívások, amikor csak lehet, közvetlenül (peer-to-peer) futnak [11]

Valódi telefonszámok hívásánál az a kérdés, mit tud meg és mit őriz meg rólad a szolgáltatás; hogy a hívott fél mit lát helyette, azt a böngészős hívásnál megjelenő számról szóló cikkemben írom le.

Így futtass WebRTC-szivárgástesztet

Egy szivárgásteszt-oldal ugyanazt teszi, amit egy tárcsázó a hívás előtt: WebRTC-kapcsolatot nyit, megkérdezi egy STUN-szervertől, milyen nyilvános címet lát, majd minden jelöltet kiír a sima HTTP-n látott cím mellé. Futtasd le minden böngészőben, amelyből telefonálsz, először kikapcsolt, majd bekapcsolt VPN-nel.

  1. Kikapcsolt VPN: nyiss meg egy szivárgásteszt-oldalt, például a BrowserLeaks WebRTC Leak Test oldalát. A fent látható „Your Remote IP” és a „Your WebRTC IP” alatti „Public IP Address” értékének egyeznie kell.
  2. Bekapcsolt VPN: töltsd újra az oldalt. A „Your Remote IP” mezőben most a VPN címének kell megjelennie.
  3. Ha a WebRTC-szakasz továbbra is az internetszolgáltatód címét mutatja, a WebRTC megkerüli az alagutat [1].
  4. A .local végződésű helyi bejegyzés azt jelenti, hogy a cím rejtve van [3]; a 192.168. vagy a 10. kezdetű nyers cím nincs elrejtve.
  5. Ha az oldal mikrofonellenőrzést is kínál, engedélyezd, és teszteld újra: a tárcsázónak szüksége van a mikrofonra, és ez az engedély további címeket tehet elérhetővé [1]. Utána vond vissza az engedélyt a webhelybeállításokban [12].

Mi változott a Chrome-ban, miután engedélyeztem a mikrofont

Egy helyi tesztoldalt töltöttem be Chrome 156-ban, Macen (), STUN-szerver nélkül, így egyetlen cím sem jutott el külső szerverre. Mikrofonengedély nélkül az oldal egyetlen host jelöltet látott, egy .local végződésű véletlenszerű karaktersorral elnevezve [3]. Engedélyezett mikrofonnal megkapta a valódi helyi IPv4-címemet.

Ez megfelel a szabványnak, amely a teljes címlistát csak hozzájárulással engedi, például mikrofonengedéllyel [1]; a WebKit, a Safari motorja 2017-ben ugyanezt a szabályt írta le [13]. Egy engedélyezett tárcsázó tehát láthatja a helyi címedet: ez kisebb kockázat, mint a nyilvános címed kiszivárgása [1].

Böngészőbeállítások, amelyek korlátozzák a WebRTC-szivárgást

A Brave a felhasználóknak dokumentál egy WebRTC IP-beállítást. A Google a Chrome vezérlőit bővítmények és rendszergazdák számára írja le, a Microsoft pedig az Edge-ét rendszergazdai házirendként. A Firefox alapból elrejti a helyi címeket, és az about:config oldalon kikapcsolási lehetőséget is ad. Egy szabály mindenhol érvényes: a WebRTC kikapcsolása a böngészős tárcsázókat is leállítja, mert a hívást a WebRTC viszi [14].

WebRTC-címvezérlők böngészőnként (gyártói dokumentáció, 2026. november 1.)
BöngészőVezérlőMit változtatHatás a böngészős hívásokra
BraveWebRTC IP handling policy az adatvédelmi beállításokban, a Brave wikije szerint (utoljára 2018-ban szerkesztve) [15]Az alapértelmezett Default Public Interface Only egyetlen helyi címet sem tesz láthatóvá [15]A médiaforgalom továbbító szerverre válthat [1]
ChromeA bővítmények beállíthatnak WebRTC IP handling policyt [16]; a rendszergazdák a WebRtcIPHandling házirendet állíthatják be [17]Az értéktől függően leáll a privát címek használata, vagy a médiaforgalom csak proxyn keresztül megy [17]A csak proxyt engedő értékek TCP-re terelhetik a hangot, ami az IETF szerint rontja a minőséget [1]
EdgeWebRtcLocalhostIpHandling rendszergazdai házirend [18]Két értéke megszünteti a helyi IP-cím láthatóságát [18]Ugyanaz, mint a Chrome-ban
FirefoxA helyi címek alapból rejtve [19]; media.peerconnection.enabled az about:config oldalon [20]Ha ezt a beállítást false értékre állítod, a WebRTC kikapcsolA böngészős tárcsázók leállnak
SafariBeépített szabályA mikrofon- vagy kamerahozzáférés nélküli oldalak nem kapnak host címeket, ahogy a WebKit 2017-ben leírta [13]Nincs

Mit változtat a VPN a böngészős hívásokon?

Az a VPN, amely minden forgalmat, a WebRTC-t is beleértve, az alagútján küld át, a hívásszolgáltatásnak a te címed helyett a VPN címét mutatja. Osztott alagutas VPN mellett a WebRTC az internetszolgáltatód címét is megtalálhatja [1], ezért kell a szivárgástesztet bekapcsolt VPN-nel is lefuttatni. A VPN-nek a telefonálásra is vannak mellékhatásai.

Hogyan tartsd titokban az IP-címedet hívás közben?

A megoldást a hívás típusához igazítsd. Telefonszámok hívásakor a hívott fél nem kapja meg az IP-címedet, ezért olyan szolgáltatást válassz, amelyre nyugodtan rábízod, és ellenőrizd a VPN-edet. Alkalmazások közötti hívásnál a másik eszköz közvetlenül is kapcsolódhat a tiédhez, ezért használd az alkalmazás továbbítási (relay) beállítását, ha van ilyen.

  1. Böngészős hívások: futtasd le a szivárgástesztet bekapcsolt VPN-nel; a Brave-ben válaszd a Default Public Interface Only beállítást [15].
  2. Mikrofon: az egyszer használt tárcsázóknál az „Allow this time” (engedélyezés csak most) lehetőséggel add meg [12]; a Chrome-os ellenőrzésemben az ilyen engedéllyel rendelkező oldal látta a helyi címet.
  3. WhatsApp: kapcsold be a Protect IP address in calls beállítást. A súgóoldal Androidra, iOS-re és Macre vonatkozik, a webes verzióra nem, és figyelmeztet, hogy a továbbított hívások minősége kissé romolhat [5].

Gyakori kérdések

Mi az a WebRTC-szivárgásteszt?

A WebRTC-szivárgásteszt egy weboldal, amely lefuttatja a böngészős hívások kapcsolatfelépítését, és kilistázza az összes IP-címet, amelyet a böngésződ felkínál, a sima HTTP-n látott cím mellett. Ha bekapcsolt VPN mellett az internetszolgáltatód címe szerepel a listában, a WebRTC megkerüli az alagutat [1]; a véletlenszerű .local név azt jelenti, hogy a helyi címed rejtve van [3].

Látja a böngészőből hívott fél az IP-címemet?

Nem, vezetékes vagy mobilszám hívásakor nem. A szolgáltató az átjárójánál alakítja a böngésződ hangját telefonhívássá [23], a telefonhálózat pedig hívószámot továbbít, nem IP-címet [2]. Az alkalmazások közötti hívások mások: a Messenger szerint a kétszereplős hívások megosztják az IP-címedet a másik fél eszközével [4].

Megállítja a VPN a WebRTC-szivárgást?

Az a VPN igen, amely minden forgalmat, a WebRTC-t is beleértve, az alagútján visz át. Az osztott alagutas VPN nem feltétlenül, mert a WebRTC a VPN címe mellett az internetszolgáltatód nyilvános címét is felderítheti [1]. Ezt csak egy szivárgásteszt mutatja meg, csatlakoztatott VPN-nel, minden használt böngészőben, frissítések után megismételve.

Veszélyes, ha kiszivárog a helyi IP-cím?

Kevésbé, mint egy nyilvános cím kiszivárgása. Egy privát cím, például a 192.168.1.20, nem árulja el, hol vagy, de az IETF szerint a privát IPv4-címek meglehetősen jelentős felületet adnak az ujjlenyomat-alapú azonosításhoz, amellyel egy eszközön összekapcsolhatók a normál és a privát böngészési munkamenetek [1]. A Firefox alapból elrejti a helyi címeket [19], a Safari a mikrofon- vagy kamerahozzáférés nélküli oldalak elől rejti el őket [13], és az ellenőrzésemben a Chrome is így tett.

Megállítja az inkognitó mód vagy a privát böngészés a WebRTC-szivárgást?

Nem. Az IETF megjegyzi, hogy a WebRTC-n keresztül felfedett privát cím azonosítóként működhet, amelyből egy webhely megtudhatja, hogy egy normál és egy privát ablak ugyanazon az eszközön fut [1], így a privát mód önmagában nem rejti el. Használd a fenti böngészőbeállításokat, majd privát ablakban is futtass szivárgástesztet.

Működnek a WebRTC-szivárgás elleni bővítmények?

Részben. Chrome-ban egy bővítmény beállíthatja a böngésző WebRTC IP handling policy értékét, amelyet a Google a médiateljesítmény és a láthatóvá tett helyi címinformációk közötti kompromisszumként ír le [16]. Az értéktől függően ez elrejti a helyi címeket, vagy proxyra kényszeríti a médiaforgalmat, ami TCP-re terelheti a hangot, és ronthatja a minőséget [1]. Telepítés után futtass szivárgástesztet, hogy megerősítsd a változást.

Hogyan kapcsolhatom ki a WebRTC-t a Firefoxban?

Írd be a címsorba, hogy about:config, keress rá a media.peerconnection.enabled beállításra, és állítsd false értékre. A Mozilla forráskódja ezt a beállítást az RTCPeerConnection kapcsolójaként írja le, és a kikapcsolása az oldalak mikrofon-API-hoz való hozzáférését is megszünteti [20]. Ezután egyetlen böngészős tárcsázó sem működik, ezért a legtöbb telefonálónak jobb a Firefox alapbeállítása, amely már így is elrejti a helyi címeket [19].

Hogyan állíthatom meg a WebRTC-szivárgást Chrome-ban?

Bővítménnyel vagy házirenddel, mert a Google a Chrome WebRTC-címkezelési beállításait erre a kettőre dokumentálja. Egy bővítmény beállíthatja a WebRTC IP-kezelési szabályát [16], a rendszergazdák pedig a WebRtcIPHandling házirendet, amelynek default_public_interface_only értéke megakadályozza, hogy a WebRTC privát címeket használjon [17]. A Chrome-os ellenőrzésemben egy mikrofonengedély nélküli oldal már eleve csak egy véletlenszerű .local nevet látott [3]. VPN mögött a valódi megoldás egy olyan alagút, amely az összes forgalmat viszi [1]. Ami a WebRTC-t teljesen letiltja, az a böngészős hívásokat is leállítja [14].

Láthatja egy weboldal az IP-címemet a WebRTC-n keresztül engedélykérés nélkül?

A nyilvános címedet igen, de azt a weboldalak egyébként is látják: a Safari például a mikrofonhozzáférés nélküli oldalaknak csak olyan címeket ad, amelyeket egy weboldal amúgy is begyűjthetne [13]. A buktató a böngészőben beállított proxy. Ha a közvetlen internet-hozzáférés engedélyezett, a WebRTC STUN-ellenőrzései megkerülhetik a proxyt, és felfedhetik a valódi nyilvános címedet [1]. A helyi címek jobban védettek: a szabvány a teljes listát hozzájáruláshoz, például mikrofonengedélyhez köti [1], és a Chrome-os ellenőrzésemben egy ilyen engedély nélküli oldal csak egy véletlenszerű .local nevet látott [3].

Kérdezz egy MI-asszisztenst erről a kutatásról

Mindegyik gomb új lapon nyitja meg az asszisztenst, és megkéri, hogy foglalja össze ezt az oldalt, forrásként linkelve rá.

Források

  1. RFC 8828: WebRTC IP Address Handling Requirements · IETF (RFC Editor) · ellenőrizve: 2026. november 1.
  2. 47 CFR 64.1601 -- Delivery requirements and privacy restrictions | eCFR · US Code of Federal Regulations (eCFR) · ellenőrizve: 2026. november 1.
  3. Using Multicast DNS to protect privacy when exposing ICE candidates (draft-ietf-mmusic-mdns-ice-candidates) · IETF (Internet-Draft, work in progress) · ellenőrizve: 2026. november 1.
  4. Voice call someone or a group on Messenger - Messenger Help Center (Computer) · ellenőrizve: 2026. november 1.
  5. How to protect your IP address on WhatsApp calls | WhatsApp Help Center · WhatsApp · ellenőrizve: 2026. november 1.
  6. RTCIceCandidate: address property - Web APIs | MDN · MDN Web Docs (Mozilla) · ellenőrizve: 2026. november 1.
  7. RTCIceCandidate: type property - Web APIs | MDN · MDN Web Docs (Mozilla) · ellenőrizve: 2026. november 1.
  8. Make calls | Sonetel help · ellenőrizve: 2026. november 1.
  9. Free call | Call2Friends - Online call · ellenőrizve: 2026. november 1.
  10. Privacy Policy | Globfone · ellenőrizve: 2026. november 1.
  11. Voice Calls: Secure, Crystal-Clear, AI-Powered | Telegram Blog (30 March 2017) · Telegram · ellenőrizve: 2026. november 1.
  12. Use your camera and microphone in Chrome - Computer - Google Chrome Help · Google · ellenőrizve: 2026. november 1.
  13. A Closer Look Into WebRTC | WebKit (3 July 2017) · WebKit (Apple) · ellenőrizve: 2026. november 1.
  14. WebRTC API - Web APIs | MDN · MDN Web Docs (Mozilla) · ellenőrizve: 2026. november 1.
  15. WebRTC Custom Settings · brave/brave-browser Wiki · Brave Software (official GitHub wiki) · ellenőrizve: 2026. november 1.
  16. chrome.privacy | API | Chrome for Developers · Google (Chrome for Developers) · ellenőrizve: 2026. november 1.
  17. Chrome Enterprise policy list: WebRtcIPHandling (WebRTC IP handling) · Google (Chrome Enterprise) · ellenőrizve: 2026. november 1.
  18. Microsoft Edge Browser Policy Documentation WebRtcLocalhostIpHandling | Microsoft Learn · Microsoft · ellenőrizve: 2026. november 1.
  19. Firefox source: modules/libpref/init/all.js (mozilla-firefox/firefox) · Mozilla (official Firefox source repository) · ellenőrizve: 2026. november 1.
  20. Firefox source: modules/libpref/init/StaticPrefList.yaml (mozilla-firefox/firefox) · Mozilla (official Firefox source repository) · ellenőrizve: 2026. november 1.
  21. Terms of Use – TextNow · ellenőrizve: 2026. november 1.
  22. Privacy Policy – Privacy & Terms – Google · Google · ellenőrizve: 2026. november 1.
  23. Call From Your Browser Without a SIM Card - TwinPhone · ellenőrizve: 2026. november 1.