Re: [tor-talk] Tor -> VPN Clarification

[Mirimir <mirimir@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk