Delivery-Date: Mon, 02 Feb 2015 12:44:29 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY,
	URIBL_BLOCKED autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id D5AA91E094D
	for <archiver@seul.org>; Mon,  2 Feb 2015 12:44:27 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 4B3B533441;
	Mon,  2 Feb 2015 17:44:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id EDB3833423
 for <tor-talk@lists.torproject.org>; Mon,  2 Feb 2015 17:44:18 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 8aVEb-Kc0HD2 for <tor-talk@lists.torproject.org>;
 Mon,  2 Feb 2015 17:44:18 +0000 (UTC)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id B51BF3341C
 for <tor-talk@lists.torproject.org>; Mon,  2 Feb 2015 17:44:18 +0000 (UTC)
Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
 by mx1.riseup.net (Postfix) with ESMTPS id C169240EA9
 for <tor-talk@lists.torproject.org>; Mon,  2 Feb 2015 17:44:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1422899055; bh=dptf1kqK5IUkcp1EOYomDeI+E1PRj9nyxJyy+uXAR6U=;
 h=Date:From:To:Subject:References:In-Reply-To:From;
 b=Mo5s6P0eZMMSn/IsAoy1JDdjo4bRyvpmMWGfz+Te9dgj90ReS+xfBx4OYDGU6LvzL
 7aWa17rc1Lv5y9wmLJt3YdJRw63afU4KQKLrl/xDeGMExFgowhMd2IsJwCpCADed8Z
 aIVo+AoSaHqGQolzCaOz6G6fWDQrhympM2DA2MSg=
Received: from [127.0.0.1] (localhost [127.0.0.1])
 (Authenticated sender: mirimir) with ESMTPSA id C16E940DE9
Message-ID: <54CFB76B.7020709@riseup.net>
Date: Mon, 02 Feb 2015 10:44:11 -0700
From: Mirimir <mirimir@riseup.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <54CB577A.9000100@riseup.net> <54CD1B02.70304@whonix.org>
 <54CD85A8.6080601@riseup.net> <op.xtc9exdbbgbjo9@work-pc.lan>
 <54CDD77E.6010700@riseup.net> <54CDFBBC.5080909@techwang.com>
 <54CE4461.4020106@gmx.com> <20150201215150.311ACC03CC@smtp.hushmail.com>
 <54CEACB5.5020000@gmx.com> <54CEC199.9080206@riseup.net>
 <54CF4C36.2010608@techwang.com> <54CF5D4A.5080407@riseup.net>
 <20150202170027.EFBBBC0373@smtp.hushmail.com>
In-Reply-To: <20150202170027.EFBBBC0373@smtp.hushmail.com>
X-Virus-Scanned: clamav-milter 0.98.5 at mx1
X-Virus-Status: Clean
Subject: Re: [tor-talk] Tor -> VPN  Clarification
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On 02/02/2015 10:00 AM, l.m wrote:
> 
> "Mirimir" wrote:
> Sorry, I wasn't clear. I meant that nobody here has made an argument
> that "VPN -> Tor" is "definitely not good". I agree that leeroy seems
> to
> favor Case 2 aka "Using a VPN to connect to Tor".
> 
> Well lets try to setup an experiment. I'll get you started. It doesn't
> require you to be NSA :P It requires a guard you're in control of. It
> also requires an exit you're in control of. It requires a completely
> separate connection to the internet to perform testing. Let's setup a
> test scenario. The common parameters are circuit length, three, use
> case is VPN over Tor. You'll need to be familiar with R. Let's start
> with the easiest test (ignoring path selection and middle relay
> churn). Analysis of traffic at the guard+exit.

I love it !!!

Let's go for it. I already have a VPS setup for testing the VPN aspect.
I gather that I'd need to setup a private entry guard. As I recall from
the literature, that's doable, but I don't recall precisely how. For the
rest, I can use the public Tor network, right?

> First, in general, it should be clear, from tor spec, that if the VPN
> used doesn't use port 443 then you'll be limited to a subset of all
> exit nodes. You can obtain current data for consensus at CollecTor
> [0]. You can find a parser for said data in the relevant section. It
> should also be clear, from tor spec, that Tor will learn your usage
> over time and restrict your circuit build to one over time. Tor will
> also tend to reuse (bias) exits which it knows can handle your
> request. Your adversary knows where to look for you because you gave
> them some conveniently static traffic signature to look for. Your VPN
> connection is such an indicator.

I also have a test website that loads a complex, asymmetric page.

> What you'll be measuring is how attacks can be used to perform
> statistical correlation across nodes. Analysis of traffic at the guard
> simulates an adversary who is observing your guard traffic. This
> adversary can see incoming (from you) and outgoing connections at the
> guard. Analysis of traffic at the exit simulates an adversary who can
> see incoming and outgoing traffic at the exit. So essentially you'll
> have as much information as the GPA. This adversary has the
> characteristic of being able to share information among national
> intelligence agencies and can trivially place themselves along
> vulnerable routes within the VPN and the ISP at both ends. Again, for
> simplicity, we're ignoring the anonymity network-internal adversary at
> middle hops and analysis of VPN internal traffic. Let's assume you're
> using that VPN for something and you don't want them to see *your* ISP
> address. Metadata alone can trivially filter all use of the VPN to
> reveal outliers that use the VPN in unusual ways. Your use of a Tor
> exit stands out as a particularly juicy target.
> 
> Now to find you using statistical correlation of signals. Some
> hypothesis.

As I noted recently, my traffic correlation skills are primitive. I've
never managed more than 4:1 signal to noise, using my simple-minded dot
product approach. Although I understand some of the fancy
signal-analysis math, I'm not aware of open-source software to implement
it efficiently. It would be sweet if someone would provide some guidance.

> H1 -- If the connection to the VPN gets dropped on it's way to the
> guard or on it's way to the next hop you're in trouble. You can
> simulate this by forcing a destroy. The DESTROY message propagates
> through your Tor circuit and the VPN drops. If you do this reliably,
> over time, you may even get an adversary controlled/observed middle
> hop.
> H2 -- If you interrupt the guard connection at your test machine (on
> the test ISP) on it's way out to the guard you're in trouble. This can
> force TCP congestion control on both the Tor circuit and VPN. Because
> the VPN congestion control depends on end-to-end conditions you must
> first wait for tor to stabilize before the VPN. A measurable change in
> signalling has occurred.
> H3 -- If the VPN connection is dropped at the exit you're in trouble
> for similar reasons as H1. Doing this reliably over time allows the
> reconnect to be observed at one of the exits recently used. This data
> can be obtained using only the metadata of your VPN. Which exits might
> be used in the future depends on the port used by the VPN. This data
> can be obtained using CollecTor.
> H4 -- If you interrupt the VPN at the exit you're in trouble for
> similar reasons as H2 only now you're attacking the congestion control
> of the VPN. This creates a measurable change in signalling.
> H5 -- Combining data sets of observations at both ends completely
> removes any anonymity. Recall this is intended to be a simulation of
> an external adversary who can only see the signalling at both ends of
> Tor and the VPN internal traffic. By putting all the browsing over the
> VPN you've lost the one advantage Tor can provide. You've given an
> adversary a mostly static point to attack and given them many options.
> H6 -- Doing something convoluted like also using pluggable transports
> (at the same time) or using Tor to connect to a VPN, then using that
> VPN to connect to some anonymous network will not help. All you've
> done is created stronger correlation.
> 
> I don't have the resources to do it myself but I'm sure it would make
> a phenomenal study. On the other hand, leaders of most free democratic
> countries have been quoted to the effect of saying "security and
> freedom go hand-in-hand". Consider that some of these leaders forsake
> humanitarian aid and join the propagandist ranks of those countries
> which incite hatred by screwing up foreign countries. All the hate is
> a direct consequence of bungled military operations. We, the lowly
> voter, now have to accept that sacrificing freedom is necessary for
> security. (oops--that's just an opinion not an advocacy for extremism)
> 
> So I stand by my choice for using a VPN to connect to Tor instead of
> the other way around. From my limited understanding the threats posed
> by the alternative far outweigh any possible advantage. Then again the
> way I use Tor naturally follows from project goals so it's the choice
> with more variables in my favor.

I'm glad that we all now seem to agree that "VPN -> Tor" is best.
There's a wider range of perspectives on "Tor -> VPN", but hey ;)

> --leeroy
> 
> [0] https://collector.torproject.org
> 
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

