cryptostorm: "leaks," DNS leaks, & routing tune-ups

[cryptostorm_team]

Those who have been around here for a while know that we're pretty interested in what people generally refer to as "DNS leaks" (although that term is not very easy to pin down, it turns out).

Currently, we're working with several beta testers to nail down mis-handling of pushed DNS servers on several OS platforms. Because these kinds of "leaks" are intimately entwined with the host operating system handing the secure network connection, it's just not possible to have a "one size fits all" answer to them from the server-side of things.

Indeed, those with sharp eyes might have already noticed that there's some commented-out "stubs" in our server-side configuration that involve pushing various script-based route-setup parameters to specific client-side OS flavours. In a nutshell, we're actively testing several of these approaches... and have been for several months.

In addition to these server-side options, our network access widget works with Windows to do manual flushing & refilling of local route/route metric data during session initiation/teardown. This helps to minimise the snarled mess that can occur when Windows is trusted to self-manage its own routing reconfiguration.

But let's cut to the chase. The real solution here, on the Windows side of things, is Leakblock (equivalent versions on Linux are implemented via dynamic iptables rules). Don't tell anyone, but we're hoping to roll the first public version of Leakblock into the 0.9 version of the Windows widget itself. This is how to solve the "leaks" problem from top to bottom.

In the meantime, please report any and all leak-ish things here in this thread. There's nothing secret about this process - we're happy to discuss here in public threads, as it helps ensure we're seeing the most comprehensive sweep of events.

To that end, by far the most useful data are wireshark session analyses (or raw pcap's) - they show us exactly what's going on with secure session characteristics at the packet level. This kind of analytic work has to be done client-side, and there's just no way we can cover all the various permutations of client OS/config setups in-house. Put another way: the more testing, in more situations, we can bring to bear on secure network sessions the more confident we all can be that things are locked-down tight.

The ubiquity of leaky behaviours in supposedly secure "VPN services" is hard to overstate. We're fully dedicated to eliminating leaks, structurally and systematically, for cryptostorm members. This is a process - not a one-shot magical answer, nor a hand-waving promise that all is well when it's not.

Thanks in advance for helping us make cryptostorm the un-leaking-est darknet in the world.

• ~ cryptostorm_team

[DesuStrike]

I cannot provide a wireshark log but for the sake of completeness I'll tell you here what I already wrote via email:

Using the Linux terminal guide will lead to DNS leaks if you have a router that pushes your ISP DNS-Servers via DHCP. It simply overwrites the DNS-Servers pushed by the VPN. This especially happens with ISP branded routers. Those often get remote configured by the ISP or have the DNS-Servers hardcoded in them. Avoid those if you can!

Funny enough the Ubuntu Network-Manager with openVPN plugin does not suffer the same fate. I tested it out extensively with the same crappy router hardware like above but I had no DNS leaks whatsoever.

Viscosity (Windows/MAC) and openVPN for Android by Arne Schwabe have no DNS-Leaks either.

[Pattern_Juggled]

For folks with Debian-based Linux distros, this is one of the client-side scripts we've been testing to clamp down on pushed DNS settings. Current snapshot from git below:

Code: Select all

#!/bin/bash
# 
# Parses DHCP options from openvpn to update resolv.conf
# To use set as 'up' and 'down' script in your openvpn *.conf:
# up /etc/openvpn/update-resolv-conf
# down /etc/openvpn/update-resolv-conf
#
# Used snippets of resolvconf script by Thomas Hood <jdthood@yahoo.co.uk> 
# and Chris Hanson
# Licensed under the GNU GPL.  See /usr/share/common-licenses/GPL. 
#
# 05/2006 chlauber@bnc.ch
# 
# Example envs set from openvpn:
# foreign_option_1='dhcp-option DNS 193.43.27.132'
# foreign_option_2='dhcp-option DNS 193.43.27.133'
# foreign_option_3='dhcp-option DOMAIN be.bnc.ch'

[ -x /sbin/resolvconf ] || exit 0

case $script_type in

up)
        for optionname in ${!foreign_option_*} ; do
                option="${!optionname}"
                echo $option
                part1=$(echo "$option" | cut -d " " -f 1)
                if [ "$part1" == "dhcp-option" ] ; then
                        part2=$(echo "$option" | cut -d " " -f 2)
                        part3=$(echo "$option" | cut -d " " -f 3)
                        if [ "$part2" == "DNS" ] ; then
                                IF_DNS_NAMESERVERS="$IF_DNS_NAMESERVERS $part3"
                        fi
                        if [ "$part2" == "DOMAIN" ] ; then
                                IF_DNS_SEARCH="$part3"
                        fi
                fi
        done
        R=""
        if [ "$IF_DNS_SEARCH" ] ; then
                R="${R}search $IF_DNS_SEARCH
"
        fi
        for NS in $IF_DNS_NAMESERVERS ; do
                R="${R}nameserver $NS
"
        done
        echo -n "$R" | /sbin/resolvconf -a "${dev}.inet"
        ;;
down)
        /sbin/resolvconf -d "${dev}.inet"
        ;;
esac

[marzametal]

I experienced my first dropout yesterday evening. It seems that the widget shut down on its own, which reverted my IP back to its original state.

That was wierd, and fixed by a reboot. It might have been my ISP doing the data usage update or something...