Posted on Reddit here: http://redd.it/32d94q
Recently there have been a lot of discussions about the WebRTC IP Leak. Almost all of them call it a “security flaw” or treat it as a bug.
However, many articles about the WebRTC [leaks] talk about a solution: disable WebRTC in your favorite browser.
Two questions:
- Is it really a “security flaw” that needs to be fixed in browsers? Look at browser bug reports to understand how many different opinions exist on this.
- Why can the browser go outside the VPN tunnel? How many apps/protocols can do the same things as the WebRTC leak? So, is disabling WebRTC a sufficient solution for those who use a VPN to avoid exposing their ISP IP address or traffic?
I will explain the details of the issue. But first, if you are connected to a VPN service right now, try this:
ipdetection.zip (source available here )
or, under Unix try this (try also as root):
for s in `ifconfig -a | sed 's/[ \t].*//;/^\(lo\|\)$/d'`; do curl --interface $s http://www.clodo.it/projects/whatismyip/; done
Is your real ISP IP leaked?
Details
When a user connects to OpenVPN, the main interface (ethernet, wifi etc.) is still available (also to talk with the VPN server itself).
And another network interface is opened (tun/tap).
This is the scope of OpenVPN: create a tunnel.
As a plus, OpenVPN can be configured to push a directive from the server to its clients: “redirect-gateway”.
This tells the client side that ALL traffic needs to be redirected inside the tunnel by default.
Almost all VPN services use a specific option of that directive: “redirect-gateway def1”.
From the OpenVPN manual
def1 — Use this flag to override the default gateway by using 0.0.0.0/1 and 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of overriding but not wiping out the original default gateway.
Now, this means that the original 0.0.0.0/0 route is still active, but there are other routes created by OpenVPN that override the original based on precedence.
But 0.0.0.0/0 is a route assigned to the standard interface, while the new 0.0.0.0/1 and 128.0.0.0/1 are assigned to the TUN interface.
In every OS, when a connection/socket is opened, the program can choose a specific network interface that needs to be used.
This is not common, because most applications don’t need that and let the OS use the default network interface.
The program above does exactly this: it binds to a specific network interface to query an external what is my IP address service.
When binding to the standard interface, the overriding rules of OpenVPN are simply ignored, at least under Windows.
I think browsers do the same thing in WebRTC discovery.
Can a VPN service based on OpenVPN resolve the issue server-side, transparently to their users?
Yes.
Simply don’t use the def1 option in the redirect-gateway directive.
Without def1, the OpenVPN client completely removes the 0.0.0.0/0 route, and recreates it on disconnection.
But I don’t recommend this approach: with def1, if the OpenVPN process is terminated, the overriding routes are automatically deleted or unused, and traffic continues to flow over the standard interface.
Without def1, if the OpenVPN process is killed/terminated, the user remains without any route for his/her traffic.
For me, a good VPN service needs to use the def1 option, for the final consideration below.
Final consideration
The WebRTC IP Leak is not a fault of browsers.
It is not a fault of OpenVPN (which is designed to be tunneling software, not an Always hide my traffic software).
It is a fault of users, because they trust the standard OpenVPN client for things outside its scope, or trust a badly written VPN service client.
Users need to use a VPN service that has software addressing this kind of issue, or need to understand how to configure a firewall or a router.
Disclaimer:
I’m the author of the client software of a known VPN service. Anyway I don’t cite it in this Reddit post.