Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 116 reacties
Submitter: zvbhvb

Via het webrtc-protocol laten Chrome en Firefox de ip-adressen van vpn-gebruikers uitlekken aan websites. Dat kan op de achtergrond gebeuren. Andere browsers dan Firefox en Chrome hebben geen last van het privacyprobleem.

Wie een vpn-verbinding gebruikt om zijn identiteit te verbergen komt bedrogen uit als hij Chrome of Firefox gebruikt. De webrtc-ondersteuning van beide browsers heeft tot gevolg dat websites toch de identiteit van de gebruiker kunnen uitlezen met behulp van javascript, waarschuwt onderzoeker Daniel Roesler, die een proof-of-concept maakte.

Webrtc is een standaard die gebruikers via video en audio laat communiceren of bestanden laat versturen zonder dat plug-ins vereist zijn. Om dat mogelijk te maken, kan het soms nodig zijn om iemands echte ip-adres te achterhalen. Chrome en Firefox bieden die functionaliteit, maar die kan dus worden misbruikt om iemand die een vpn-verbinding toepast te identificeren. Daarvoor hoeft een website enkel javascript-code te gebruiken.

Zowel de desktopversies van Chrome en Firefox als de Android-versie van Chrome zijn vatbaar; de Android-versie van Firefox lijkt niet kwetsbaar te zijn. De potentiële privacy-inbreuk kan alleen worden tegengegaan door webrtc uit te schakelen. In Firefox kan dat via about:config; Chrome-gebruikers kunnen de functionaliteit enkel uitschakelen met een extensie. De Chrome-versie van Android biedt echter geen ondersteuning voor extensies. Tor, dat samen met Firefox wordt geleverd, is niet vatbaar.

De loophole is overigens alleen te misbruiken als de vpn-verbinding lokaal draait; anders kan de browser het 'echte' ip-adres immers niet te weten komen. Draait de vpn-verbinding vanaf de router, dan is het ip-adres van de gebruiker bij de provider niet te achterhalen.

VPN-verbinding

Moderatie-faq Wijzig weergave

Reacties (116)

Dit werkt overigens alleen maar als je de VPN op je eigen PC hebt draaien.

Is je router ook de VPN client (in mijn geval PFSense) dan zie ik alleen het VPN adres.
Dit werkt overigens alleen maar als je de VPN op je eigen PC hebt draaien.

Is je router ook de VPN client (in mijn geval PFSense) dan zie ik alleen het VPN adres.
Goede toevoeging. Ik ga het aanvullen.
Thanks. Bij torrentfreak zegt de baas van TorGuard het volgende:

"Perhaps the best way to be protected from WebRTC and similar vulnerabilities is to run the VPN tunnel directly on the router. This allows the user to be connected to a VPN directly via Wi-Fi, leaving no possibility of a rogue script bypassing a software VPN tunnel and finding one’s real IP,” Van der Pelt says.
Na het lezen van het artikel op Torrentfreak, meteen gechecked, was niks te zien, daarna noscript uitgezet (toestemming gegeven) toen zag ik mijn VPN IP adres en mijn lokale LAN ip adres 192.168.enz... maar niet mijn ISP gegeven IP adres..... dus zolang je van je router alleen een inten LAN adres krijgt, is je externe IP adres ook niet te zien.... oh Firefox 35.0.1

Bij mijn VPN verbinding (gebruik OpenVPN) gaat ook AL het verkeer (HTTP FTP POP IMAP Torrent, enz... alles) over de VPN. Best wel lastig af en toe, krijg ik op Ebay soms alles in bijv. zweedse kronen (of bijv. canadese dollars) als ik nog niet ben ingelogd. Zelfde voor google earth / maps.. begin ik in Botswana. _/-\o_ .!!
Ik kreeg precies hetzelfde, met Tunnelbear. Maar ik wist niet zeker of ik het probleem wel volledig begreep (is het slecht als "ze" de interne adressen van je router kunnen aflezen?), dus ik heb WebRTC maar uitgezet in FF 35, want wat moet ik daarmee? Kan het altijd nog in Chrome doen indien gewenst: die browser gebruik ik sowieso als iets niet in FF werkt door Noscript of wat dan ook en ik te lui ben of niet in staat ben om het in Firefox op te lossen (tijdelijk dan wel permanent). Of zijn Tunnelbear en sommige andere VPN-diensten hiervoor immuun?

[Reactie gewijzigd door Cerberus_tm op 2 februari 2015 20:19]

Wat ik denk als ik alle reacties zo lees, is dat dit probleem zich alleen voordoet als de VPN verbinding niet als exclusieve verbinding naar buiten wordt gezien door Firefox. Zal wel met de configuratie van de OpenVPN client te maken hebben omdat AL mijn verkeer in geval van een opgebouwde VPN verbinding over deze tunnel gaat. Het is zelfs zo dat als mijn OpenVPN client draait maar de verbinding blijft hangen op bijv. "resolve" of "wait", firefox niet eens verbinding kan maken met het internet (ook al werkt mijn LAN verbinding naar mijn router en modem gewoon en kan ik wel mijn NAS en mijn router bereiken via het LAN).
Mijn torrent client heeft ook zo'n functie dat als het IP adres van de adapter (in dit geval een virtuele TAP) niet bereikbaar is, er geen andere verbinding wordt opgezet via de niet virtuele "Eth0" adapter terwijl de verbinding naar de ISP gewoon up is......

Mijn gok is dus dat het door de configuratie van de OpenVPN client komt dat dit lek bij mij niet optreedt.

Maar ik ben ook niet alwetend :+
Hmmm dat kan. Het hangt zeker ook af van het besturingssysteem hoe het met VPN's en verbindingen omgaat. Ik dacht eigenlijk dat een VPN altijd alle contact met het Internet beheerste en er helemaal niets mogelijk was buiten de VPN om, als deze actief was; maar dit WebRCT-gebeuren deed mij denken dat er toch mogelijkheden waren. Nu suggereer jij dat er met sommige VPN-cliŽnten of -configuraties wel verkeer buiten de VPN mogelijk is maar met andere niet. Ik hoop eigenlijk dat dit het geval is en mijn en jouw cliŽnten altijd al 100% veilig waren...

Welk torrentprogramma gebruik je eigenlijk, en is zoiets gemakkelijk in te stellen?

[Reactie gewijzigd door Cerberus_tm op 3 februari 2015 00:01]

Welk verkeer wel of niet via het VPN gaat wordt bepaald door je VPN configuratie. Dit kan door de admin worden ingesteld bij bijv. een bedrijfs-VPN of door je zelf.

De term hiervoor is Split Tunneling en is gebaseerd op bepaalde regels. Zo wordt op ons bedrijfsnetwerk alleen verkeer naar de interne IP-range via VPN getunneld en gaat de rest via je gewone verbinding. Dit is vooral gedaan zodat de internetverbinding van het bedrijf niet onnodig belast wordt, maar het is ook handig dat de VPN-gebruiker nog wel bij zijn eigen interne netwerkbronnen kan terwijl hij/zij verbonden is met VPN.
A okee, en hoe kun je dan zien hoe je configuratie is? Of kan dat niet als je een cliŽnt van een bepaalde VPN-aanbieder gebruikt, zoals Tunnelbear?
Ik ben er geen expert in. Bij ons Cisco IPSEC VPN wordt dit in het verbindingsprofiel (dat je krijgt aangeleverd door je admin) gezet d.m.v. TunnelingMode=0. De server kan afdwingen dat je alleen met de 'juiste' instelling verbinding mag maken. Je kunt in de client-log ook zien wat de instelling is. Meer info van Cisco.

Ik meen dat alle soorten VPN's Split-Tunneling ondersteunen, maar of je client die instelling openbaar maakt weet ik niet. Ik zou verwachten dat het in de logs staat. Je zult het sowieso kunnen vragen aan je aanbieder.
Mijn VPN provider geeft ook een download van een config file voor OpenVPN specifiek voor hun verbinding dus. (daar staat o.a. de host naam en IP adres in waarnaartoe jouw computer de tunnel moet opzetten). In die config file staat natuurlijk ook dat alle verkeer over die verbinding moet gaan

En ik zeg "natuurlijk" want mijn VPN provider is puur een anonimiserings provider, niets meer en niets minder. (geen proxy of torrent proxy, maar een echte VPN verbinding met hun IP adres naar de buitenwereld) Dan wil je ook AL je verkeer over de VPN behalve intern netwerk verkeer. Werkt netjes, geen logs bij de provider, account met een anoniem email adres aangemaakt terwijl ik een andere VPN connectie had over TOR :Y) Email sinds dien niet meer gebruikt....
A okee, maar het is dus het programma Open VPN dat, op basis van die configuratie, kan afdwingen dat je besturingssysteem met geen enkel ander extern IP-adres contact maakt dan dat van je VPN-dienst? Kan Open VPN dat wel echt 100% garanderen?
Vuze (Azureus) 4.3.0.6

Gereedschappen -> configuratie -> verbindingen -> geavanceerde netwerk instellingen -> dan de derde regel op dit tabblad koppel aan IP adres, hier het IP adres van je VPN (virtuele adapter) invullen...
Klaar is klara... zodra je IP verandert heb je geen upload/download meer...wel zo veilig indien je niet wil dat anderen weten wat je upload / download. O-)
Als antwoordt op je laatste vraag, Ja ik denk het wel, ik heb zelf die keuze mogelijkheid niet (waarschijnlijk andere versie)......oeps... moest ff naar beneden scrollen, die staat inderdaad bij mij aangevinkt... :+
Je IP van je VPN tunnel kan je ook op dezelfde pagina vinden (bij mijn OpenVPN config), ik zal ff een copietje maken.....

(Mijn Vuze is in "gebroken" Nederlands :+ )
De volgende interfaces zijn beschikbaar:
lo (MS TCP Loopback interface)
lo[0] 127.0.0.1
lo[1] 0:0:0:0:0:0:0:1
lo[2] fe80:0:0:0:0:0:0:1%1
tun2 (Automatic Tunneling Pseudo-Interface)
tun2[0] fe80:0:0:0:0:5efe:2ef6:##censored ;)
tun2[1] fe80:0:0:0:0:5efe:c0a8:##censored ;)
eth1 (Broadcom NetLink (TM) Gigabit Ethernet)
eth1[0] 192.168.##censored ;)
eth1[1] fe80:0:0:0:21d:7dff:fe13:##censored ;)
tun1 (6to4 Pseudo-Interface)
tun0 (Teredo Tunneling Pseudo-Interface)
tun0[0] fe80:0:0:0:0:ffff:ffff:##censored ;)
eth0 (TAP-Windows Adapter V9 - Pakketplanner-minipoort)
eth0[0] 46.246.##censored ;)
eth0[1] 2a00:1a28:##censored ;)
eth0[2] fe80:0:0:0:2ff:6cff:fe##censored ;)

Je IP adres van je VPN is dus die van eth0[0] en die van je PC naar je router (intern adres dus) die van eth1[0].
Edit:
die van je eth0[0] copieer je dus naar dat invul vakje IP koppelen.

Uiteraard werkt bovenstaande alleen als je eerst je VPN tunnel opzet en daarna pas Vuze start. ;)

[Reactie gewijzigd door BenGenaaid op 4 februari 2015 11:19]

A okee, dank! Dat is helder. Maar hebben veel VPN's trouwens geen wisselende adressen? De jouwe niet?
Jazeker, dan moet je dus zodra je IP verandert, (merk je vanzelf, je downloads en uploads stoppen) dit ook in Vuze aanpassen.

Ik gebruik een OpenVPN die ophangt zodra het IP wil wisselen, dan blijft ie op resolve hangen, moet soms wel tot een 15 minuten lang proberen de verbinding dan weer op te krijgen... maar 10Mbit up en 65Mbit down en dat gratis.......mag niet klagen.. :P .

Als mijn verbinding eenmaal up is en hij werkt, dan blijft hij up zolang er data verkeer is, soms wordt ie er dan na een paar dagen bijv. door een DMCA van een of andere grapjas uit VS eraf gegooid en begint het spelletje opnieuw om verbinding te krijgen..

Heb op deze manier in de afgelopen 90 dagen 2,5 Tbytes geupload. (Alles legale data O-) )
Aha, ik begrijp het. Welke VPN-dienst gebruik jij dan, of is dat Open VPN (dacht dat dat alleen software was, geen dienst met servers en zo?)?
Nee mijn VPN dienst ondersteunt OpenVPN.

https://openvpn.net/
http://nl.wikipedia.org/wiki/OpenVPN

Mijn dienst is gratis (tot nu toe), als er erg veel nieuwe klanten bij komen verandert dat, m.a.w. het is niet in mijn belang nu reclame voor hun te maken......gebruik een zoek machine en wie weet vindt je hem ;)
Dat is interessant. Het lijkt er dus op dat de bug in essentie is dat Chrome en Firefox altijd het IP van je fysieke adapter geven bij gebruik van de getroffen API's ipv het werkelijk actieve IP.

Overigens zou je met de privacy functie van IPv6 (RFC 4941 = default aan op Windows) dan ook veilig zijn neem ik aan, aangezien die standaard semi-random addressen voorschoteld. Mits je uiteraard op een IPv6 netwerk zit natuurlijk. (Alhoewel je bent dan enkel veilig tegen tracken, en niet tegen zaken als lokatie achterhalen...)

Ondersteunen Android en iOS eigenlijk RFC 4941? Windows en Windows Phone in ieder geval wel.
Daarom, schaaf een goedkope router aan die werkt met OpenWRT firmware. Zoek een goede build die ondersteunning bied voor TOR en gaan met die banaan. de DIR-835 van Linksys/Cisco is mijn favoriete router voor OpenWRT en Adam K zijn builds zijn mijn favoriet. --> https://forum.openwrt.org/viewtopic.php?id=49841

Je keuken, huis, tuin router bied opeens meer mogelijkheden dan een professionele bedrijfsrouter.

(Maar ik gebruik zelf geen TOR, dus voor TOR zijn er betere builds)

[Reactie gewijzigd door Kain_niaK op 2 februari 2015 18:25]

Kun je OpenWRT ook als package op zeg Debian draaien?
Heb nu een Banana Pi R1 Routerboard en zoek nog iets handigs om m als router in te richten.
Geen idee, maar dan kun je vast wel op internet ergens vinden.
[...]


Goede toevoeging. Ik ga het aanvullen.
BBC gebruikt deze truc tegenwordig om te voorkomen dat mensen hun iplayer app in o.a. Nederland kunnen gebruiken via een vpn app.
Echt waar, die schobbejakken, gelukkig dat we onze privacy nu kunnen beschermen. Of is WebRTC vereist om de Iplayer te laten werken?
Eigenlijk is iplayer gebruiken zonder UK nationaliteit ook niet echt legaal. De programmering wordt betaald met Brits belastings geld. Dit is dus heel anders dan regio unblocking bij Netflix waar je gewoon voor de content betaald
Tsja, aan de andere kan ik de BBC toch gewoon FTA van de satelliet plukken.
Precies FTA CeeBeeBees vinden mijn kinderen super. En wij kijken tuin en huis programma's en dr who. We zouden best een euro of 4 tot 6 per maand voor BBC-gemist willen betalen als ze chromecast en Android 5 ondersteunen :) - uiteraard onder voorwaarde dat ik dat aan BBC en content makers betaal en niet aan proxy diensten.

[Reactie gewijzigd door djwice op 3 februari 2015 11:39]

Ik zou er ook wel geld voor over hebben om iplayer te kunnen gebruiken. De Engelsen zelf betalen overigens best veel "kijk en luistergeld"
Is wel degelijk niet legaal, je bekijkt de content zonder hiervoor rechten te betalen, is te vergelijken met zwart kijken.
Britten betalen hierdoor wel meer.
Dat jij als enkeling naar iplayer kijkt gaan ze inderdaad niet merken, maar deze praktijken gebeuren zoveel dat dit serieus wat extra load op de servers legt (wat ook geld kost).
Als je het niet via Iplayer bekijkt kan de BBC je nadien nog een DVD verkopen, en het is niet omdat er geen legale manier is om naar een serie te kijken, dat je dit illegaal mag doen.
Al dit gezegd zijnde, ik kijk zelf ook Iplayer, maar ik ga niet klagen als de BBC dit probeert de blokkeren, ik weet dat wat ik doe niet echt koosjer is
In Firefox kan je WebRTC uitzetten door media.peerconnection.enabled op False te zetten. Natuurlijk gaat dit wel ten koste van alle WebRTC functionaliteiten.

In Chrome ben je blijkbaar aangewezen op een extensie:
https://chrome.google.com...hfanlpblblcadhfbkdm?hl=en

[Reactie gewijzigd door Dragon op 2 februari 2015 17:03]

Maar wat is het gemis daaraan? Waar wordt WebRTC (voor) gebruikt? Merk je dat je het mist of kun je prima zonder?
WebRTC kan gebruikt worden om vanuit de browser directe p2p video/voice conferenties op te zetten ( zie bvb : https://talky.io/ ) - aangezien afaik nog niet alle major browsers ondersteuning bieden is dit zover ik weet nog niet erg vaak in het wild te vinden.
Bijvoorbeeld ja. Het is eigenlijk een interface over de TCP/IP stack heen, die het mogelijk maakt om arbitraire TCP (en UDP?) verbindingen op te zetten, ťn inkomende verbindingen te accepteren door poorten open te kunnen zetten.

Dat laatste moet je router dan wel ondersteunen, als je achter NAT/VPN zit.
Veel videoconferentie fabricanten (cisco, polycom, ricoh, ...) hebben een service om 3'den uit te nodigen die geen professionele conferentie hardware in de buurt hebben. Meestal bieden die ook ondersteuning voor WebRTC zodat er geen extra plug-in moet geÔnstalleerd worden waarvoor ze eventueel eerst bij hun IT afdeling moeten langsgaan. Handig als je tijdens een conference call snel even iemand via zijn laptop of smartphone kan uitnodigen om een paar vragen te stellen.
Dat gebeurt toch vrij veel, de meeste vpn's zijn zo opgezet.

Is dit ook de reden dat bv RTLGemist en Uitzendinggemist niet meer werken via Hola! (een Firefox VPN plugin)?

[Reactie gewijzigd door Dreamvoid op 2 februari 2015 17:40]

Dat de meeste VPN's zo opgezet zijn, is logisch; de meeste VPN's zijn er om gebruik te maken van zakelijke faciliteiten; niet om jezelf te anonimiseren.

Wil je het echt veilig? Zet 10 PFsense bakkies in serie; die allen andere VPN's draaien.

Dan tunnel je je tunnel door een andere tunnel en dat een paar lagen diep.
Enkel de eerste VPN provider kent dan je externe IP adres; alle opvolgende kennen alleen IP adressen van de VPN provider eronder.

Als het je gaat om je IP verbergen; dan is dit volgens mij een van de beste manieren.
Dat is dus een soort harde ui, de hardware versie van TOR. Heel handig, alleen wel beetje duur en gedoe om op te zetten.
Inderdaad, in principe kan je ook gewoon Whonix gebruiken en dan op de host een VPN en op de Whonix workstation een andere VPN. Dan heb je VPN - TOR -VPN, zit je ook redelijk safe en iets minder gedoe en stukken goedkoper.

[Reactie gewijzigd door Skull88 op 2 februari 2015 22:18]

A ja, een virtuele machine helpt inderdaad ook. Maar je kunt alleen niet garanderen dat de virtuele machine waterdicht is en niets oppikt buiten de VPN op de host om, niet 100%. Met hardware kun je dat beter garanderen, lijkt mij, omdat er veel minder interactie mogelijk is tussen router en computer dan tussen host en VM.
Emm. Nietes.

Kost niks, alleen een paar virtuele machines op Oracle Virtualbox of VMWare Workstation.

Enig wat je nodig hebt zijn 2 netwerkkaarten. Meer niet, de rest doe je virtueel. PFSense is gratis verder.

Het leukste is nog wel dat je zonder probleem gebruik kunt maken van onbetrouwbare gratis VPN providers; want die drie gelaagde tunnels die dan door ze heen lopen; daar kunnen ze toch niks mee ;-)
Mwoah; een virus die je BSD-based pfsense bakkie binnenkomt zie ik niet zo snel gebeuren ;-)

Maarem; eigenlijk heel simpel

WAN - PFSense 1 (VPN) - Virtueel netwerk 1 - PFSense 2 (VPN) - Virtueel netwerk 2 - Client.
Hmm ik ben bang dat ik dat niet helemaal begrijp, ik begrijp niet wat voor soort opstelling je maakt...
Ik kan bevestigen dat het werkt zoals Pruttelpot het meldt.

Ik heb ook een vpnclient op mijn router draaien en mijn gewone externe ip is niet zichtbaar wel het VPN adres.
Dus iedereen die niet via VPN surft heeft sowieso een potentiŽle privacy-inbreuk? Als je VPN gebruikt om anoniem te blijven dan zul je daar vast een goede reden voor hebben. Dan mag je je ook best een beetje verdiepen in welke browser je gebruikt.
quote: Swank Teeter
Als je VPN gebruikt om anoniem te blijven dan zul je daar vast een goede reden voor hebben.
Aan welke goede reden(en) denk jij zoal? Ik denk met name aan privacy. Meer hoeft er namelijk niet achter te zitten. Iedere individu heeft er gewoon recht op (vind ik)...
Op internet bevind je je in publiek domein. Het is niet standaard dat je via een VPN op internet bent aangesloten. Daarnaast zegt een ip-adres niet zo veel. Alleen welke provider je hebt en in welke regio of plaats je je bevindt. Je PC geeft bovendien een eigen fingerprint af die voor iedere website die je bezoekt zichtbaar is. Je zult heel wat meer maatregelen moeten nemen om echt zeker te zijn van privacy. http://en.wikipedia.org/wiki/Device_fingerprint
Dan moet je het wel weten dat Firefox en Chrome hier last van hebben. Kan nog lastig worden dan op een *nix bak. Los daarvan: ik kan me voorstellen dat journalisten e.d. een VPN nodig hebben, maar om van hen te verwachten dat ze snappen hoe een browser werkt, gaat nogal ver IMHO.
Nee, iedereen die wťl via VPN surft heeft een potentieel privacy-issue. Als je niet via VPN surft, is je IP-adres geen geheim.
Dus iedereen die niet via VPN surft heeft sowieso een potentiŽle privacy-inbreuk? Als je VPN gebruikt om anoniem te blijven dan zul je daar vast een goede reden voor hebben. Dan mag je je ook best een beetje verdiepen in welke browser je gebruikt.
Tja, puur in de basis wel.
Maar ik schaar mezelf tot de relatief aardig ingelichte kringen, maar zit niet dagelijks op github of andere deep-tech site's

Ik weet dat VPN veiliger zou moeten zijn, dan zonder, maar heb jij van elke protocol 100% inzicht ?
Ik had geen idee dat dit Łberhaupt bestond, en waar het voor diende - tot ik het hier tegenkwam.
Ergens moet je tegen de informatie aanlopen, geen persoon heeft oneindige kennis natuurlijk..

Het belangrijkste is dat je HIER van leert, en het toepast in je volgende stappen.
Hier dus via no script en de genoemde extensie geblokkeerd .. op naar het volgende potentiŽle gevaar ...
Daarvoor moet het probleem wel eerst gevonden worden en openbaar worden gemaakt en je moet er dan ook nog tegenaan lopen. Ik weet echt niet elke functie in elke browser en waar het eventueel fout kan gaan en dan beschouw ik mijzelf toch meer tech savvy als de gemiddelde persoon. Je kan niet verwachten dat jan met de pet dit allemaal weet, meeste mensen gebruiken een VPN om hun privacy veilig te stellen, dit zijn niet allemaal experts in computerbeveiliging.

Hoop sowieso dat de meerderheid tegenwoordig niet meer zonder VPN op internet gaat. Weet namelijk niet wat overheden en bedrijven nog meer moeten gaan doen om mensen zover te krijgen dat ze toch een basisbeveiliging als een VPN gebruiken.
VPN was in eerste instantie bedoeld om veilig remote op een bedrijfsnetwerk te kunnen inloggen. Dan is er geen noodzaak om het ip-adres te verhullen. Dat het nu gebruikt wordt om overheden te ontwijken of regionale beperkingen te ontduiken is een andere zaak. Voor webrtc is het juist een goed zaak dat je direct kunt peeren ipv het via een vpn te laten lopen. Dat zal de reden zijn dat het kan.
Met WebRTC Block voor chrome kan je dit gewoon blokkeren, mooi concept tho :)
En wat blokkeert het nog meer ?

WebRTC zal toch ergens wel nuttig voor zijn lijkt mij ?
WebRTC is staat voor Web Real-Time Communication en is een goede manier om connecties op te zetten voor bijvoorbeeld chat, video of audio. De latency bij dit protocol ligt relatief laag, wat belangrijk is voor directe communicatie. Google Hangouts maakt er bijvoorbeeld ook gebruik van. Skype niet, want die werkt niet in de browser en gebruikt een eigen (proprietary) systeem.

Een andere live video "standaard" als HLS (HTTP Live Streaming) schaalt veel beter, maar heeft een veel hogere latency en is ťťnrichtingsverkeer. Een latency van 10 seconden is heel normaal, maar ook enkele minuten komen voor. Bij het live weergeven van een event (bijv. Apple keynote) is dit niet zo'n issue, maar voor directe communicatie absoluut acceptabel.

WebRTC blokkeren zal je in de praktijk niet merken, tenzij je van dit soort diensten gebruik maakt. Wil je wat voorbeelden zijn van WebRTC kijk dan eens op https://www.webrtc-experiment.com.
Het is een beetje de vloek van Javascript (en flash/java/etc): als het mogelijk is om vanaf afstand code op je systeem te laden dan is het mogelijk om daar misbruik van te maken.
Tsja, maar het alternatief is scripts draaien op de bron (=de webserver) en dat hebben websites liever niet, kost teveel centen (server cpu).
Uhhh.. Ooit van PHP/ASP gehoord? Dat is serverside
Ik snap het ook wel, ook voor de gebruiker zijn er veel voordelen, maar het nadeel blijft bestaan. Overigens zou je ongeveer hetzelfde kunnen zeggen over "normale" software, dat is vaak een blackbox die zichzelf onopvallend via internet update en je moet er maar op vertrouwen dat alle leveranciers nu en in de toekomst te vertrouwen zijn.
Daarom draait Javascript natuurlijk ook in een sandbox omgeving en die kan niet bij lokale resources (bijv. geen access tot filesysteem behalve via handmatige file browser). Het enige dat het natuurlijk wel kan is netwerk requesten uitvoeren en daar moet een bericht terug, dus je moet de afzender wel weten. Daar maakt dit een misbruik van.
PrivateInternetAccess VPN lijkt niet kwetsbaar hiervoor:

Zonder VPN:
Your local IP addresses:
10.0.1.187

Your public IP addresses:
5.XXX.XXX.XXX

Met VPN:
Your local IP addresses:
10.0.1.187
10.184.1.6
Your public IP addresses:
179.XXX.XXX.XXX

Meting gedaan op Firefox 35 onder Arch Linux

[Reactie gewijzigd door Tweetyfrk op 2 februari 2015 17:24]

Helaas, op windows wel degelijk.
Na inschakelen van de about:config optie op FF, en block webRTC in chrome is het ook 'zuiver'
Op Linux idd niet kwetsbaar. Linux Mint 17.1 hier en kan mijn echt IP-adres ook niet zien.
Ik heb het idee dat de Linux versie het probleem niet heeft. Heb namelijk dezelfde test gedaan met Ubuntu + Firefox en Chromium en geen van beiden gaf mijn echte IP.

Zowel voor AirVPN, NordVPN als Riseup werd mijn echte IP niet getoond.

Edit:

Is blijkbaar idd een Windows probleem:
"The vulnerability is limited to supporting browsers such as Firefox and Chrome, and appears to affect Windows users only."

http://torrentfreak.com/h...real-ip-addresses-150130/

Freebsd lijkt ook het lek te hebben, maar Linux gebruikers zijn blijkbaar safe. :)

[Reactie gewijzigd door Skull88 op 2 februari 2015 22:38]

Hoe kan een browser uberhaubt een publiek IP weten?
Door een externe server te benaderen (STUN) die geeft het externe IP adres terug. De vraag is of dit ook werkt als je al je verkeer door een VPN tunnelt, want dan lijkt mij je externe IP adres onzichtbaar.
Ik vraag mij af of dit ook met Tor zou gebeuren of dat dit toch wel safe is.
Bij tor wordt ook sterk aangeraden javascript uit te zetten.
Bijna geen enkele website (die ik bezoek) werkt zonder javascript. Javascript uit = heflt van het internet is nu nuteloos want het werkt niet meer.

Javascript uitzetten is een oplossing zoals ga met de fiets ipv met de auto zo spaar je benzine uit.
Het is ook dan geen oplossing maar een noodzaak omdat javascript de mogelijkheid geeft aan websites om handelingen uit te voeren nadat hij geladen is die altijd een probleem kunnen zijn voor de privacy, bv keyboard en mousetracking binnen de site die je na een aantal bezoekjes herkent door karakteristieke eigenschappen.
En niet te vergeten de mogelijkheid om na het laden van de website nog meerdere malen verbinding te maken met een server (ajax).
Lol webpaginas zijn van origine nogeens niet bedoeld als interactieve applicaties maar als informatie bronnen, tekst en afbeeldingen.

Dus voor iedereen die informatie bronnen checked via een vpn is javascript helemaal geen behoefte.
Vertel dat de meeste populaire websites en meest gebruikte websites. Zelfs google werkt niet altijd goed met javascript uit. Gmail checken op gmail.com? Vergeet het maar zonder javascript.
Nou is het hele idee van privacy (door een VPN) natuurlijk bijna compleet weg als je wel Google blijft gebruiken...
Werkt prima zonder javascript, check zelf maar.
Man, deze reactie kun je niet een schrijven MET JAVASCRIPT UIT.

Probeer JIJ maar. Ik heb het net geprobeerd op Tweakers en de helft van de site werk niet meer.
Toch zijn op Tor veel Market Places die gewoon werken zonder Javascript en daar gaat het uiteindelijk om, net om die paar sites die je gebruikt niet om het halve internet.
Precies, mijn punt is dat je TOR niet gebruikt voor normaal internet. TOR gebruik je wanneer je je grote zorgen maakt over je privacy. In sommige gevallen volledig terecht (bijvoorbeeld als politicus of journalist).

In dat geval is het goed om twee systemen te hebben. Eentje voor alles waar het je niks uitmaakt of er iemand mee leest en daar kun je gewoon je dagelijks sites op bezoeken. Maar nooit reageren natuurlijk.

Een ander systeem via TOR (Tailes of Qube OS is je beste optie) voor alles waarvan privacy schending een grote probleem zou kunnen vormen in je leven.

Dan snap ik het wel. Maar TOR gebruiken om naar Tweakers te surfen of op Youtube video mee te kijken. Wie doet dat? Niemand denk ik toch ... misschien een paar idioten.
Tor waarschuwt juist met nadruk voor de potentiŽle de-anomisering van allerlei addons en plugins die je IP kunnen prijsgeven. Daarom wordt geadviseerd een schone, vanilla Tor browser te gebruiken.
http://thehackernews.com/...e-easily-unmasked_18.html tor is ook niet waterdicht is al gebleken is wel veel kennis voor nodig!
Niks is waterdicht. Zelfs mijn waterdicht horloge liegt.
ICE/STUN/TURN zijn ontwikkeld om een optimaal media pad te realiseren, ook als firewalls in de weg staan. Uitgangspunt is dat clients aan elkaar vertellen op welke IP adressen/poorten ze benaderbaar zijn. Dat weten ze vooraf namelijk niet van elkaar. Een client levert daarbij alle lokale IP adressen aan, via een STUN server wordt het publieke IP adres achterhaald (als je achter NAT zit) en via een TURN server wordt een relay adres aangeleverd (als directe connectivitiet niet mogelijk is).
Die set aan adres/poort combinaties wordt naar de andere kant gestuurd (en van de andere kant ontvang je zo'n set). Dan worden er connectivity tests gedaan en het meest optimale pad wat werkt wordt gebruikt. Als peer-to-peer mogelijk is zal dat in principe worden verkozen. Vandaar dat je dus de lokale adressen ook nodig hebt.
Allemaal standaard functionaliteit van de protocol suite.
Dit werkt volgens eigen test niet als je ergens een OpenVPN afneemt, zal wel zo zijn als je enkel VPN inschakelt via web-pagina en dus niet echt op je hele PC.
Hier over PIA zowel lekkend via TCP als UDP, de eigen client is een openvpn frontend
Vreemd dit.

Zonder VPN:
Your local IP addresses:
192.168.1.192

Your public IP addresses:
80.57.XXX.XXX (mijn echte lokale IP)


Met VPN:
Your local IP addresses:
192.168.1.192
10.163.XXX.XXX (adres in Duitsland)

Your public IP addresses:
178.162.205.1 (ander adres in Duitsland)


Draai VPN (openVPN) op macbook via Viscosity
Die 10.163 is een 'lokaal' adres op jouw NIC. Die kreeg je van je VPN-boer. Daaraan valt niets af te lezen qua privacy.

Maar inderdaad, als ik vanaf mijn computer een VPN-verbinding opzet en al het verkeer daarover laat lopen, dan "weet" mijn computer (en de browser) niet eens wat mijn externe (van de ISP gekregen) IP-adres is. Deze test bevestigt dat voor mij ook:

Met VPN:
Your local IP addresses:

192.168.xx.xx (lokaal LAN)
10.xx.xx.xx (VPN tunnel, lokaal)

Your public IP addresses:

xx.xx.xx.xx (IP van een van de servers van mijn VPN-boer)

Mijn externe IP-adres wat ik van mijn ISP krijg kan hij niet zien.

Wanneer ben je dan eigenlijk wel kwetsbaar voor dit lek? Als je zonder router werkt wellicht, maar zo'n beetje iedereen heeft toch wel een router thuis? Of ligt het aan de VPN-implementatie?
Even getest maar mijn echte IP was niet zichtbaar in zowel Firefox (35.0.1 voor Ubuntu) als Chromium (39.0.2171.65 Ubuntu 14.10 (64-bit)) ondanks dat de VPN gewoon lokaal draait.

media.peerconnection.enabled stond ook gewoon aan, nu wel uitgezet. Fijn dat mijn IP niet zichtbaar was maar vraag mij nu wel af waardoor ik schijnbaar wel veilig ben.
Linux is niet kwetsbaar. Is ook mijn eigen vaststelling op Linux Mint 17.1
Dit zeer kwalijke zaak, toch maar even in Firefox uitgezet.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True