[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

entry node gateway

Hi, first of all thanks to all dev team for your great work, this is a fantastic project! But since I’m not so high skilled on these things, I have a question for you: is the entry node 1.1.1.1 of x gateway able to understand that it’s always the y user that establish the connection even if, for example, the user connecction on the host comes from two different VPN IP in two different times? If yes, how is it possible? Is there a way to prevent this?
Many thanks

can you rephrase the question , i cant get what you mean.

Surely
This is my configuration:
User -> VPN (on host) -> Tor -> Internet
Since the entry node is the same for months and I use several VPNs in the host system, I would like to understand if a malicious entry node is able somehow to bring back always to me. So also if I use various VPN IP addresses, the entry node with a (magic/impossible? :smiley: ) fingerprint technique already knows that is always the same user to use his node.
The reason behind this question is that I would like to understand if it is better to use 1) always the same VPN server or 2) change it from time to time. To try to understand what is the best solution I assume that the tor network is already compromised. Now the main reason for choosing the first option is that if only one VPN server has my real IP and the adversary is not able to compromise it, I’m safe, while using more VPN servers it’s more likely that the adversary will succeed to compromise a server and consequently to de-anonymize me. The main reason for choosing the second option is that if I am a victim of traffic correlation, having many different IPs from which few packets come from means for the adversary having many small targets, while having only one IP (even if it is a VPN IP) from which many packets come it means having one big target. This advantage is true only if it’s not possible for the entry node to link different IPs to the same user through some (unknown to me) fingerprinting technique: hence the question :smiley:
These are just my reflections and I’m not assuming that what I wrote is right :thinking: I’m not even assuming that my grammar is correct, because I already know it’s not :sunglasses:


This Page answers your Question(s)

If you assume this, why do you want to use it?

1 Like

I’m with goldstein-otg on this. If the Tor network is compromised it doesn’t matter if you use 100 different VPN providers. Its game over.

Traffic correlation can be used on a VPN server as well. Easier than watching traffic on both ends of the Tor network?

Tor: over 6000 relays all over the world.
You -> entry guard -> middle relay -> exit node -> Intenet

Your VPN provider: 1 sever. Know location.
You -> vpn sever -> Internet/Tor entry guard

VPNs don’t necessarily make you safer or strengthen anonymity. They can actually do the opposite. Are you certain they are not logging everything you do?

https://whonix.org/wiki/Comparison_Of_Tor_with_CGI_Proxies,_Proxy_Chains,_and_VPN_Services#Comparison_of_Tor_and_VPN_services

The Snowden release showed VPNs are actively targeted.

https://s3.amazonaws.com/s3.documentcloud.org/documents/1077764/vpn-and-voip-exploitation-with-hammerchant-and.pdf

1 Like

Thanks for your replies guys :smiley:

Wow, the link I needed! So the only known problem comes from the forwarding of the MAC address? Re-randomize the MAC of the gateway’s NAT interface at every power-up could be the solution to this problem, or am I on the wrong track?

I don’t think that the entire network is compromised and I’m aware that probably my nodes are not, I made a hypothesis to understand how to add an additional layer of security if it happens that my nodes were compromised.

So if I’m using a cracked network is game over? If what the adversaries got from the monitoring of the tor network is an IP of a VPN server that didn’t hold any log is game over? I’m not sure of this.
Surely there may be VPNs that log traffic on request from third parties or that do so indistinctly, I’m aware of this, but it’s the adversary’s job to take possession of those logs. The link you posted regarding Snowden’s leak is certainly interesting, but I have to admit that I cannot fully understand it, there are too many terms and mechanisms that I don’t know.

How is it possible to do a traffic correlation having only the VPN server control? What the VPN sees is encrypted traffic coming from my ISP going to the entry node. I think it’s also needed the monitoring of the exit node or server, but it’s highly unlikely that an adversary tries to correlate traffic from a VPN, while it’s much more likely to try to do so starting from an entry node.
If I assume that the exit node or server is already monitored, plus this configuration:

  1. User -> Entry node
    -I’m vulnerable at ISP level, which seeing the tor traffic will be much more sensitive to log it
    -The monitoring of the entry node combined with traffic correlation attack implies game over

If instead I try this:

  1. User -> VPN -> Entry node
    -The ISP doesn’t know that the generated traffic is tor traffic: no particular predisposition to log it
    -The monitoring of the entry node combined with the traffic correlation attack doesn’t imply game over: further actions are needed to de-anonymize the user

IMHO 2 is better.

VPNs are not that good a hiding Tor traffic especially with modern deep packet inspection.

Yes, if an adversary went through all that trouble how difficult would it be to correlate VPN traffic? Adversary would be know what VPN server the network traffic was coming from. If adversary was able to correlate Tor trafficc it would be a cake walk.

1 Like

Ok, maybe not a foolproof choice, but between giving them this info and forcing them to decrypt OpenVPN packets and also do a DPI to get it, I would prefer the latter. Anyway there are also ISPs that claim not to do a DPI, maybe it’s not the case of ISPs in countries like China, and maybe soon all ISPs will be forced to do it, but for now I feel that this info is significantly more protected with a VPN.

I don’t think that once the adversary has obtained the VPN IP he intends to make a correlation attack starting from the logs of all the ISPs on the planet, or is it a realistic threat? In this case it’s better to use a double VPN.
If the correlation attack on tor network succeeds it will take more time to get legal authorization to get hold of the VPN server, assuming this happens, the VPN may hasn’t kept any log. If they obtained legal authorization to monitor the server, the VPN could simply choose not to provide that server to its customers anymore. Everything is very hypothetical and things could also go wrong, but regardless of what will be the epilogue, what is sure is that the adversary will have to spend more time and money to try to de-anonymize the user.

Please could you tell me if this is the right solution?

Hi tsitspas

As you can see I’m not a big fan of VPNs anymore. I used to use them though.

That if for you to decide. Nothing is fool proof.

2 Likes

Hi and thank you for your help

Well after all it’s still an open question whether it’s helpful to use them or not, I think that with the utmost care in the choice and a bit of luck they can come in handy, but who knows, maybe these VPNs are doing more damage than useful activities without the user’s knowledge :see_no_evil:

OK, if there is no way (or at least doesn’t happens by default) to leak the MAC address outside the local network, there is no need to re-randomize it every time the vm is powered up. In the case of open/cracked network the question seems more complex and it starts already from the host because it’s vulnerable to sniffing from network administrators and spoofing could not work as intended against advanced tracking techniques, but again, seems not by the entry node which it was what I wanted to know.

I hope I haven’t misunderstood the documentation yet again :sweat_smile:
I feel myself a bit like the average voter: I look for simple solutions to complex issues :roll_eyes:

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]