[brainstorm] vpn security and design issues - long post

asked 2017-02-09 10:48:33 +0300

This post is a wiki. Anyone with karma >75 is welcome to improve it.

updated 2018-12-13 09:24:29 +0300

cy8aer
9385 ●205 ●263 ●262

tl;dr - there are problems with ipv6, dns resolving, and design with the new vpn gui/connman.

I am using (open) vpn connections for a long time now - even with SailfishOS and want to reveal some problems which IMHO must be shown because it is a very very nasty security issue - especially in countries where such a bug may cost your life (sorry to say but some of the BRICS -> e.g. the C or R [update] and nowadays also B). It is not only a problem of your device it is also a problem of your vpn server side! And it is not only a problem of openvpn - the fritzbox stuff does the same.

Scenario: You have an (open-)vpn server at home and you are visiting a friend with a dual stack network (so he has ipv4 and ipv6). Do not ask your friend (if he is no nerd) if he has ipv6 - he does not know. But several providers just switch v6 on (e.g. Germany's Telekom) do not have ipv4 at all and do ds-lite (Germany: unity media) or you run around a modern conference with a v6-stack only (FOSSDEM - but then it will not work at all...) or dual stack and you cannot trust the other people around like congresses in Germany's late winter time... Probably your LTE-Provider does dual stack too!

assuming your vpn works (so all bugs of the beta are fixed for sailfishos). You configure your network that the default gateway is your tunnel, because you want all your traffic go through the tunnel. You can ping your private machines and a traceroute/tracepath to all known 8.8.8.8 goes through the tunnel. Everything is fine.

Everything? Hm...

• install tcpdump on your device
• start a sniff to your outside interface (jolla: wlan0 or the gprs-interface) and write the sniff via -w into a capture file
• Open https://google.com in the browser
• start the tunnel
• Open https://google.com in the browser (again)
• stop the tcpdump
• open the capture file in wireshark.

What will you see? https://google.com will not go through your tunnel.

For me it does but...

... you must start openvpn direct - this does not work with conman actually, it cannot handle all possible openvpn configuration statements - and you need to prepare the openvpn server. And: the same will occur if you do some tunnel to your fritz box or most of the tunnels around with every device you see.

Same problem will occur with facebook, apple or many other sites, probably 20% [update] (we are better now, we have, say, 40%) of all sites right now.

Why?

... to be continued ...

Part 2 - Dual Stack

Yes, the main problem is dual stack. If you prepare a tunnel for ipv4 then you build up a routing for ipv4. You will not change anything for ipv6. There all routes are still going to the default gateway.

When you do an DNS resolving you get two addresses for e. g. google.com:

~$ host google.com
google.com has address 172.217.23.142
google.com has IPv6 address 2a00:1450:4001:818::200e
...

and modern operating systems try to use ipv6 priorized. For mobile devices it is done by a brutal force method today:

• resolve the ip addresses (v4 and v6)
• try both addresses to connect
• use the first one who answers
• if both, v6 and v4 are slow, try v6 first.

but if a big player address is resolved (google, facebook, apple...) the v6 address will win. And because the v6 resolving is not changed all data will flow through the default gateway for v6 which has nothing to do with your v4 traffic.

... what can I do now?

Part 3 solutions

When designing vpn connections you now have the problem how to make it secure for the end user who thinks that everything is fine.

• build up a 100% dual stack tunnel and default gateways for both, v4 and v6 through the tunnel. This would be the best solution but you need a dual stack compatible v6 configuration on the server side too and: a free v6 /64 prefix for doing that. If you are lucky your provider gives you a bigger v6-prefix, like /48 or /56 so you can subnet. A network >/64 is not standard compatible and tricky to implement. This is the solution I do (but it does not work with the Jolla framework by now -> continuation) - if you are unhappy your plastic router does not have any solution for dual stack tunnels and you are not able to hack them to openwrt/lede.
• disable the v6 stack during tunneling. This is the more brutal method but works without problems. But v6 solutions must be developed in future time. Termination to a v6 address (and tunneling v4) does not work - you cannot reach the v6 gateway address. But this would be wizzard stuff. And you cannot dual stack inside the tunnel to breakout from an v4 net into v6
• If you are in a dual stack and you find out that there is no dual stack vpn configuration is used show a warning dialog to the user. That may panic users who do not know what happens or it sensitises them.
• Do nothing and keep the users in the dark. That would be the professional method. But this is a catastrophy is someone finds it out.

and Jolla?

... to be continued

Part 4 network connection managers

to build up a consistent network controling system desktop and mobile operating systems use some network/connection managers. The desktop systems prefer NetworkManager and for SailfishOS it is connman.

These managers handle the connection to the different networks (wlan, gsm...) and also the background stuff like dhcp handling, switching dns server configurations and reconnecting on moving devices. They also have the possibility to build up different types of vpns. But there are simpler managing systems too, like e.g. the configuration system of openwrt.

If you compare NetworkManager, connman, and openwrt then all of these systems try to put a set of configuration parameters from the configuration gui to the tunnel system. Whereas NetworkManger has a quite complete set of configuration parameters connman just implements parts of the set, as openwrt.

But with openwrt it is possible to leave the configuration empty and include an .ovpn file to just hand this file out to openvpn with no changes. It looks like connman is doing the same but in reality it interprets the file, fills it's own parameter set and starts up openvpn, vpnc, ipsec... It ignores parameters it does not know! The new sailfiish gui makes it possible to set an vpnc file to import but this is a real parameter import and all parameters which are unknown are ignored (without any warning). So it is not possible to just define a .vpnc file and let connman just call it. It is not possible to just use an .ovpn file which works if you use it by a simple devel-su openvpn myfile.ovpn. The last does not work well because a network managing system must know everything about the network. If you do something without the manager disconnection and undefined network configurations are possible.

But if you are able to put the whole parameter set into the manager you must build on an error less implementation of the manager. It must e. g. handle resolv.conf parameters well (this is buggy with connman -> https://together.jolla.com/question/132993/openvpn-dhcp-option-dns-not-working/). This is needed to resolve internal servers behind the vpn tunnel. This could also be used to resolv v4 hosts only -> another possibillity for handling out v4 stuff only.

Part 5 wishlist

So then my little wishlist: It would be nice to

• have an .ovpn file entry which just bypasses the file to openvpn without interpretation of connman. Because then you are able to build up not regular openvpn (or other tunnel) configurations
• have a parameter for connman what dns server to use after building up the tunnel and definition of the domain (like NetworkManager does) and handling the resolv.conf stuff well.
• have some filtering which networks should use vpn and what network should be ignored (like NetworkManager does in background - not with the standard settings - bummer)
• have v6 support
• have a disable v6 support or filtering support or whatever
• have a quick button in events view for enabling/disabling vpn

[end of long article] This is a wiki. feel free for more design brainstorming