[tor-talk] using a VPN, proxy or ssh can make you actually less anonymous

[Mirimir]

On 07/08/2016 05:44 AM, Patrick Schleizer wrote:
> Hi!
> 
> It is possible to host Tor relays [any... bridges, entry, middle or
> exit] behind VPN IPs using VPN port forwarding. This is an interesting
> way to contribute to Tor while not exposing oneself to too much legal risk.

Yes, this is a dumb idea, on so many levels.

> #####
> 
> scenario 1)
> 
> * a) User uses VPN IP A on the host, thereby using it as it's first relay.
> * b) User's Tor client happens to pick a Tor exit relay running on VPN IP A.
> * Conditions a and b match at the same time. The user is now using the
> same IP as first and last proxy.
> 
> --> By using the VPN the user did not get more, but less secure.
> 
> #####
> 
> different scenario 2)
> 
> * a) User sets up a VPN inside Whonix-Workstation. Thereby that results
> in user -> Tor -> VPN -> internet. Using VPN IP A.
> * b) A Tor entry guard is being hosted on VPN IP A.
> * Conditions a and b match at the same time. The user is now using the
> same IP as first and last proxy.
> 
> --> By using the VPN the user did not get more, but less secure.
> 
> #####
> 
> This opens up for end-to-end corelation attacks. Ones that would not
> have been possible without using the extra tunnel link. These attacks do
> not require a global adversary or colluding ISPs but simply the provider
> of one server and a bit of bad luck.
> 
> If you think this is unlikely, I am not sure about this. In an economy
> with a deep labor division, ones are providing the service to host
> servers (VPS etc.). Others provide VPN services and rent such servers.
> 
> I conclude that it is very difficult to benefit from extra tunnel links.
> One would have to very cleverly choose a provider that does not support
> port forwarding or otherwise does not use servers/IPs that are being
> reused by others for the purpose of hosting Tor relays or bridges. Very
> cleverly choose the location of its VPN and perhaps use bridges for
> finger location control.
> 
> Perhaps choosing providers that provide private IP addresses in the
> sense that these are not shared with others?
> 
> But even then, even if that was sorted out, the if extra tunnel-link
> improve or decrease anonymity is controversially disputed:
> 
> https://trac.torproject.org/projects/tor/wiki/doc/TorPlusVPN

Well, those (Tor through VPN, and VPN through Tor) are different
situations, with different implications. If you're hitting Tor through
VPNs, you might have an entry guard and VPN server using the same VPS
host. But that would just short out the VPN.

But instead, you might be unlucky enough to have a VPN server and exit
relay using the same VPS host. Tor wouldn't catch that, in the way it
does for relays. However, you might instead be unlucky enough to have an
entry guard and honeypot website using the same VPS host. I'm not
convinced that either of those risks is hugely greater than the other.

If you route a VPN through Tor, you prevent circuit switching, and
that's clearly bad. And you would be hosed with an entry guard and VPN
server using the same VPS host. But again, I'm not convinced that this
is a hugely greater risk than having an entry guard and honeypot website
using the same VPS host.

Still, there is a lesson here for those who use VPNs with Tor: check
that relays and VPN servers aren't using the same VPS hosts.

> #####
> 
> Related:
> 
> - [tor-talk] Tor routing algorithm questions
> https://lists.torproject.org/pipermail/tor-talk/2016-July/041753.html
> 
> Cheers,
> Patrick
> 
> Roger Dingledine:
>> On Thu, Jul 07, 2016 at 10:57:00PM +0000, Patrick Schleizer wrote:
>>> scenario A)
>>>
>>> Let's assume someone's Tor client picked an entry guard on IP
>>> AAA.BBB.CCC.EEE. And then [without knowing and/or by chance] tried to
>>> make a torified connection to [1] IP AAA.BBB.CCC.EEE.
>>>
>>> - Would Tor use that entry guard to establish the connection?
>>
>> Yes.
>>
>> In fact, generally Tor clients go to domain names, not to straight
>> IP addresses, so the client wouldn't even know whether it's in this
>> situation until it was most of the way through making the request.
>>
>> (Also, DNS isn't signed or anything, so you should imagine all the
>> terrible things that could happen if we make clients change their guard
>> selection based on destination IP address, yet exit relays can lie however
>> they like about what IP address the destination supposedly maps to.)
>>
>>> - If so, wouldn't that open up for an end-to-end corelation attack?
>>
>> Yes.
>>
>>> - Does it make a difference if the torified connection is to
>>> AAA.BBB.CCC.EEE or AAA.BBB.CCC.EEF?
>>
>> No.
>>
>> But speaking of all this, see also the research papers proposing to modify
>> route selection to reduce the chance of the same Autonomous System (AS)
>> appearing on two parts of the path. The most recent one is "DeNASA:
>> Destination-Naive AS-Awareness in Anonymous Communications" by Armon
>> Barton and Matthew Wright, and it should become available shortly as it
>> will be presented at PETS in just a few weeks. But the summary of that
>> paper is that clients should pick their guard based on their local IP
>> address and on the common destinations that clients might often go to,
>> to reduce the chance of picking a guard from a network location that
>> will see a lot of their exit traffic too.
>>
>>> #####
>>>
>>> difference scenario B)
>>>
>>> Let's assume someone using WiFi with IP WWW.XXX.YYY.ZZZ starts Tor for
>>> the first time. Its Tor client picked an entry guard on IP
>>> AAA.BBB.CCC.EEE. Now, the user leaves that WiFi and uses another Wifi
>>> with IP AAA.BBB.CCC.EEE or AAA.BBB.CCC.FFF.
>>>
>>> - Would Tor be clever enough to move on to another entry guard?
>>
>> No. How can we know whether the user has changed location a lot or a
>> little? IP addresses can be wildly different yet still located in the
>> same building, and we certainly wouldn't want to keep shifting guards
>> too much.
>>
>> Also, if we *did* shift guards, should we shift back if we went back
>> to the old location? Does that mean Tor should keep track (on disk of
>> course) of its previous locations? Can a hostile DHCP server offer an
>> IP address from a suspected previous location and then see which guard
>> the client opts to use?
>>
>>> - What if the user was using a bridge on IP AAA.BBB.CCC.EEE? Would to be
>>> refusing that bridge?
>>
>> No.
>>
>> For a related (not the same) edge case, see also
>> https://trac.torproject.org/projects/tor/ticket/2998
>>
>> --Roger
>>
>