ID: 469PHID: PHID-TASK-og37a67mwy6fiboykja4Author: PatrickStatus at Migration Time: resolvedPriority at Migration Time: Normal
We have (non-)persistent Tor entry guards documented. (T94)
Notes about Tor (The Onion Router) on Log Analysis, Non-Persistent Entry Guards, Blacklist Certain Onion Services from Connecting, Additional SocksPorts, UDP and more.
Persistent Tor directory guards were implemented in Tor 0.2.4.
They might have the same effect as (non-)persistent Tor entry guards. They might not require additional documentation steps from the user as our current documentation for non-persistent entry guards might already implicitly cover them.
2016-02-11 15:20:39 UTC
2016-02-13 17:56:27 UTC
I am afraid it is a fingerprinting vector in some cases. The critical part is the following:
and failing that, pick more nodes to act as our directory guards
So let’s say fetching the consensus from the entry guard failed for some reason(*), an additional directory guard will be picked. Then it’s some entry guard a plus some directory guard b. Now going to another location and connecting to both relays should be fingerprintable.
(*) Perhaps adversaries could specifically block downloading the consensus from the entry guard only but let through all other traffic.
However, out current instructions should implicitly cover it.
Alternating Bridges
Fresh Tor Entry Guards by regenerating Tor State File
Always Non-Persistent Entry Guards
Any of these should cover the directory guards also. Does that make sense?
2016-02-16 20:28:49 UTC
(*) Perhaps adversaries could specifically block downloading the consensus from the entry guard only but let through all other traffic.
The only way that could happen is if your guard is malicious but then there are bigger problems to worry about.
A bridge acts as a directory guard (to bypass censoring of this data requested by the clients).
However, out current instructions should implicitly cover it.
Agreed.
2016-02-16 21:09:35 UTC