[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] using a VPN, proxy or ssh can make you actually less anonymous
I've tested for research purposes running both proxychains and openvpn setups using 2-3 VPSs with private ip addresses from bolt vm for really cheap per month. Worked really well as an alternative to using Tor.
Question, If you run your own relays couldn't you just force your host to connect to your relays only, thus ensuring that you won't randomly hit a malicious exit or be de-anon by nefarious actor? Yes this assumes you have a guard and exit relay running as well, but still wondering the security of that versus other setups.
> On Jul 8, 2016, at 7:44 AM, Patrick Schleizer <patrick-mailinglists@xxxxxxxxxx> 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.
>
> #####
>
> 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
>
> #####
>
> 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
>
> --
> 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
--
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