Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:45:06Zhttps://gitlab.torproject.org/legacy/trac/-/issues/15604ConnDirectionStatistics is not ignored on client-only mode2020-06-13T14:45:06Zrl1987ConnDirectionStatistics is not ignored on client-only modeStatistics-related torrc options that collect data which makes sense only if Tor is working in some specific role (relay/bridge) are ignored if Tor is not working in that mode of operation. For example, CellStatistics is set to 0 if Tor ...Statistics-related torrc options that collect data which makes sense only if Tor is working in some specific role (relay/bridge) are ignored if Tor is not working in that mode of operation. For example, CellStatistics is set to 0 if Tor instance is not acting as a relay. However, ConnDirectionStatistics is an exception and it should not be.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15515Don't allow multiple INTRODUCE1s on the same circuit2020-06-13T15:17:27ZGeorge KadianakisDon't allow multiple INTRODUCE1s on the same circuitCurrently, it seems like clients are able to send multiple INTRODUCE1 cells to the IP. The result is that many INTRODUCE2 cells reach the HS, which means that the HS will try to establish multiple rendezvous circuits.
This gives a bette...Currently, it seems like clients are able to send multiple INTRODUCE1 cells to the IP. The result is that many INTRODUCE2 cells reach the HS, which means that the HS will try to establish multiple rendezvous circuits.
This gives a better position to attackers who want to flood a HS with rendezvous circuits (like #15463), since with a single circuit they can cause hundreds of rendezvous.
We should fix this in the IP-side, by closing the circuit after sending the `INTRODUCE_ACK` to the client. An alternate behavior, is to change the state of the circuit after `INTRODUCE1` is received and close it if more such cells are received.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15053Improve out-of-tree builds2020-06-13T14:43:42ZcypherpunksImprove out-of-tree buildsSeveral make rules don't work when building out-of-tree. There are also some files that aren't cleaned up on `make clean` or `make distclean`. Lastly, some file generation blobs don't work properly by leaving temporary files behind.
Thes...Several make rules don't work when building out-of-tree. There are also some files that aren't cleaned up on `make clean` or `make distclean`. Lastly, some file generation blobs don't work properly by leaving temporary files behind.
These are just some of the things i have ran into so far and i am currently patching these issues.
Also creating this ticket to discuss certain parts of the build configuration that are unfamiliar and for which the reasons of implementation can't be traced back.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/10267[PATCH] Fixed transparent proxy destination lookup on FreeBSD2020-06-13T14:33:07ZTrac[PATCH] Fixed transparent proxy destination lookup on FreeBSDFreeBSD has two mutually exclusive firewalls: ipfw(8) and pf(8). Currenlty only pf(8) is supported for transparent proxy lookups of destination addresses.
This patch adds support for ipfw(8). It first checks if /dev/pf exists. If it doe...FreeBSD has two mutually exclusive firewalls: ipfw(8) and pf(8). Currenlty only pf(8) is supported for transparent proxy lookups of destination addresses.
This patch adds support for ipfw(8). It first checks if /dev/pf exists. If it does, it assumes pf(8) is in use. Otherwise it assumes ipfw(8) is used.
ipfw(8) is actually native on FreeBSD and much more popular than pf(8).
Patch is against tor-0.2.3.25_1
**Trac**:
**Username**: yurivictTor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8243Getting the HSDir flag should require the Stable flag2020-06-13T14:57:52ZRoger DingledineGetting the HSDir flag should require the Stable flagWhen we invented the HSDir flag, our goal was to only use nodes for storing hidden service descriptors if they're likely enough to be around later. The question was solely around robustness: pick all but the nodes that have a good chance...When we invented the HSDir flag, our goal was to only use nodes for storing hidden service descriptors if they're likely enough to be around later. The question was solely around robustness: pick all but the nodes that have a good chance of going away while your hidden service descriptor is valid. We picked "has 25 hours of uptime" as what we hoped was an adequate threshold to stand in for the real question, which is "will likely remain online for the next hour".
But actually, there are security implications here too: an adversary who can control all six hsdir points for a hidden service can censor it (or, less bad, observe how many anonymous people access it).
So we should raise the bar for getting the HSDir flag, to raise the cost to an adversary who tries the Sybil the network in order to control lots of HSDir points.
That said, there's a contradiction here: the more restrictive we are about who gets the HSDir flag, the more valuable it becomes to get it. At the one extreme (our current choice), we give it to basically everybody, so you have to get a lot of them before your attack matters. At the other extreme, we could give it to our favorite 20 relays, and if we choose wisely then basically no adversaries will get the HSDir flag. What are the sweet spots in between?
(This ticket is inspired by rpw's upcoming Oakland paper)Tor: 0.2.7.x-final