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
