Hi,
As tor explain it: an attacker could de-anonymize an user if he compromised the guard and exit node, and even more easily if he compromised the middle relay.
In my case i would like to prevent this instead of relying on chance of not picking a malicious guard node:
does proxying a Whonix-Gateway inside another Whonix-Gateway could reduce the chance of this happening ?
In my case i would assume we talk about accessing clearnet only (non-hidden-services)
I mean user-IP → Tor1(Guard1->Relay1->Exit1) → Tor2(Guard2->Relay2->Exit2) → final-clearnet-IP
In my point of view here are the benefits:
the first exit-node won’t know about the final destination
the second guard node (if kept enabled) won’t know the user ip
it’s different from modifying the circuit length directly, allowing a longer circuit without making the user using a different circuit length that each node can see.
As explained in Tor documentation, modifying the circuit length is a bad idea because nodes can easily correlate you as you will be almost lonely using a different circuit length in the network,
but does Tor inside Tor this is detectable by all nodes ?
except the Exit1 that know it connect to a Tor node, and Guard2 that know it come from a Tor node too, other nodes won’t know this is Tor->Tor, isn’t it ?
Does it make more difficult for an attacker to de-anonymize an user with this config accessing a clearnet IP ?
Does anyone have tips of config to being bulletproof against those possible attacks ?
Yes this is not only QubesOS-related, but QubesOS allow to make complex config easier (and less mis-configured) that whonix inside a virtualbox do:
Also as QubesOS allow making disposable VM easily, so my only concern is about finding the best config for using Tor in the safest way, and it clearly don’t seem that using the default of “Tor only” is the best.
If the single point of failure is the Tor network correlation than an user connecting directly to Tor without any further security would simply leak his IP and qubes won’t protect against this.
Example of config that should get reviewed:
user → VPN → Tor
user → Tor → Tor (seem to be not possible anymore due to this issue fix.
user → Tor-> VPN ->Tor
The topics about: “Tor over Tor might be dangerous” seem to be like:
“you could end up with the same hops, maybe in reverse or mixed order. It is not clear if this is safe. It has never been discussed”
Imagine an user connecting directly through tor to X.X.X.X
An attacker want to know the user IP that is connecting to X.X.X.X:
if he succeed to perform a correlation attack than the user is de-anonymized
Now imagine that same user use different config : ( User → Tor1 → VPN → Tor2 → X.X.X.X )
if there is not real security concern about this config than:
The attacker performing an attack against Tor2 will only see the VPN ip
The attacker can’t know its Tor->VPN->Tor as the VPN has its own encryption layer and ip hiding its coming from another Tor traffic, so attacking the whole Tor1 and Tor2 at same time is not possible if the VPN is not compromised by the attacker.
the attacker won’t try to attack Tor1 first as he only search for connection to X.X.X.X
Even if the VPN has log policy, the attacker would need to access the vpn-log, taking time, and finaly see that the entry IP was a Tor Exit node. Meaning that the attack was “blocked” by this config. The attacker would require to compromise the VPN and retry the same attack against the user, meaning more work to achieve.
Imagine an user connecting directly though Tor to X.X.X.X
An attacker want to know the user who is connecting to X.X.X.X
if he succeed to perform a correlation attack than the user is de-anonymized
Now imagine the user use the config ( User → Tor1 → VPN → Tor2 → X.X.X.X )
if there is not security concern about this config:
The attacker perform the same attack against Tor2, and find the VPN IP, the user is safe
the attacker won’t try to attack Tor1 as he is searching for Exit node going to X.X.X.X
the attacker can’t know its Tor->VPN->Tor as the VPN have it’s own encryption layer and IP, so attacking Tor1 and Tor2 is unlikely meaning he will attacks Tor2 first.
If the VPN is used by many user the attacker will need to access it to differentiate the user from others, than he can try to attack the whole Tor->VPN->Tor.
If the VPN is used only by the user, the attacker can directly try to attack Tor1 by searching for Exit Nodes connecting to this VPN
Even if the VPN (in “used by many user” case) have logs, the attacker, after obtaining the VPN logs will see that its a Tor exit node that connected to it. In case there is no logs, he still need to compromise it.
To fully deanonymise, the attacker will need to compromise the VPN, and perform the same attack against Tor1 and Tor2 at same time, needing more work.
I have no idea of possible security implications of this, But I used it a lot when was on Windows and with Virtualbox. When necessary, I put another VPN at the end, Didn’t care of possible de-anonymization though (due to my threat model), while having the same logic as yours.
Tor inside Tor: Can it help against an attacker owning Guard and Exit node in our circuit?
I think there’s some documentation about this in either in the Tor or Whonix docs. From what I recall, it’s strongly discouraged. Here’s a page that covers some similar topics:
People who own the nodes will know. Also everyone who can watch network traffic on a larger scale. Datacenter, TLA …
Correlation attacks would still be possible if someone owns entry and exit no matter the path length.
Same when a VPN is used. You just need to watch more traffic.
(iirc Tor devs also made it impossible to run Tor over Tor for a normal relay)