Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

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

A core mission of cryptostorm is ensuring consistent, reliable network security with minimal fuss & drama. From DNS-based services like our DeepDNS in-browser native .onion/.i2p site access, through grounbreaking research on IP6 leakblocking, & to firewall-based structures to enable "fail-closed" security, this is where we discuss & develop cryptostorm-style leakblock tech.
User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

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

Postby cryptostorm_team » Wed Oct 30, 2013 1:52 pm

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
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

DesuStrike
ForumHelper
Posts: 346
Joined: Thu Oct 24, 2013 2:37 pm

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

Postby DesuStrike » Wed Oct 30, 2013 3:04 pm

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.
home is where the artillery hits

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

update-resolv-conf script - Debian distros

Postby Pattern_Juggled » Wed Oct 30, 2013 3:24 pm

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
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

marzametal
Posts: 504
Joined: Mon Aug 05, 2013 11:39 am

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

Postby marzametal » Sun Nov 17, 2013 6:04 am

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...


Return to “DeepDNS.net - cryptostorm's no-compromise DNS resolver framework”

Who is online

Users browsing this forum: Bing [Bot] and 3 guests

cron

Login