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