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

["l.m" <ter.one.leeboi@xxxxxxxx>]

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

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.

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.

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.

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