The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:54:55Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24342Various spec fixes to dir-spec, rend-spec-v32020-06-27T13:54:55ZTracVarious spec fixes to dir-spec, rend-spec-v3There are a few commits fixing various things in some of the specs, ranging from implementation mismatches to wording here:
https://github.com/FiloSottile/torspec/compare/53b7dee30b1044ae401338a9ce4b6c76e1c431e1...ab22bd1dce3b62b6120300...There are a few commits fixing various things in some of the specs, ranging from implementation mismatches to wording here:
https://github.com/FiloSottile/torspec/compare/53b7dee30b1044ae401338a9ce4b6c76e1c431e1...ab22bd1dce3b62b6120300fdead958c6924fe553
The commit messages offer more rationale.
**Trac**:
**Username**: filippoTor: 0.3.3.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/24340(Sandbox) Caught a bad syscall attempt (syscall prctl) (asan only)2020-07-28T15:50:45ZDavid Gouletdgoulet@torproject.org(Sandbox) Caught a bad syscall attempt (syscall prctl) (asan only)This is only for libasan support:
```
20777 prctl(PR_GET_DUMPABLE) = 157
20777 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x7f552ac9f047, si_syscall=__NR_prctl, si_arch=AUDIT_ARCH_X86_64} ---
```
We would...This is only for libasan support:
```
20777 prctl(PR_GET_DUMPABLE) = 157
20777 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x7f552ac9f047, si_syscall=__NR_prctl, si_arch=AUDIT_ARCH_X86_64} ---
```
We would need to support `PR_GET_DUMPABLE`.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24339(Sandbox) Caught a bad syscall attempt (syscall mprotect) (asan only)2020-07-28T15:50:48ZDavid Gouletdgoulet@torproject.org(Sandbox) Caught a bad syscall attempt (syscall mprotect) (asan only)Trace is:
```
/usr/lib/x86_64-linux-gnu/libasan.so.4(+0x558c0)[0x7f6e71f908c0]
/lib/x86_64-linux-gnu/libc.so.6(mprotect+0x7)[0x7f6e6fa6ccf7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13150)[0x7f6e70a72150]
/lib/x86_64-linux-gnu/libc.so.6(...Trace is:
```
/usr/lib/x86_64-linux-gnu/libasan.so.4(+0x558c0)[0x7f6e71f908c0]
/lib/x86_64-linux-gnu/libc.so.6(mprotect+0x7)[0x7f6e6fa6ccf7]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13150)[0x7f6e70a72150]
/lib/x86_64-linux-gnu/libc.so.6(mprotect+0x7)[0x7f6e6fa6ccf7]
/lib/x86_64-linux-gnu/libpthread.so.0(pthread_create+0x89b)[0x7f6e70a6737b]
/usr/lib/x86_64-linux-gnu/libasan.so.4(pthread_create+0xf9)[0x7f6e71f72db9]
git/tor/src/or/tor(spawn_func+0x117)[0x55673b5a52c7]
git/tor/src/or/tor(threadpool_new+0x539)[0x55673b5a3499]
git/tor/src/or/tor(cpu_init+0xb7)[0x55673b485917]
git/tor/src/or/tor(do_main_loop+0x7fa)[0x55673b1a047a]
git/tor/src/or/tor(tor_main+0x143d)[0x55673b1a579d]
git/tor/src/or/tor(main+0x1c)[0x55673b1922bc]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f6e6f97f1c1]
git/tor/src/or/tor(_start+0x2a)[0x55673b1940ba]
```
strace shows me:
```
20085 mprotect(0x7f6e6b9bf000, 8388608, PROT_READ|PROT_WRITE) = 10
20085 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x7f6e6fa6ccf7, si_syscall=__NR_mprotect, si_arch=AUDIT_ARCH_X86_64} ---
```
Basically, our sandbox doesn't allow `PROT_READ|PROT_WRITE`. Libc is 2.26.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24338DirAuths that have IPv6 addresses don't include them in their vote on themself2020-06-27T13:54:55ZTom Rittertom@ritter.vgDirAuths that have IPv6 addresses don't include them in their vote on themselfCheck out https://consensus-health.torproject.org/consensus-health.html and Control+f for:
BD6A829255CB08E66FBE7D3748363586E46B3810
847B1F850344D7876491A54892F904934E4EB85D
24E2F139121D4394C54B5BCC368B3B411857C413
F2044413DAC2E02E3D6BCF...Check out https://consensus-health.torproject.org/consensus-health.html and Control+f for:
BD6A829255CB08E66FBE7D3748363586E46B3810
847B1F850344D7876491A54892F904934E4EB85D
24E2F139121D4394C54B5BCC368B3B411857C413
F2044413DAC2E02E3D6BCF4735A19BCA1DE97281
Also strange: dannenberg votes on ReachableIPv6 but is not itself granted ReachableIPv6Tor: 0.4.1.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24337Every _free() function should be a macro that sets the corresponding pointer ...2020-06-27T13:54:55ZNick MathewsonEvery _free() function should be a macro that sets the corresponding pointer to NULL.Our tor_free() macros has saved us a bunch of trouble in the past by ensuring that once we've freed a pointer, that pointer gets set to NULL.
Wouldn't it be cool if all of our free() calls did this? It should make our code generally le...Our tor_free() macros has saved us a bunch of trouble in the past by ensuring that once we've freed a pointer, that pointer gets set to NULL.
Wouldn't it be cool if all of our free() calls did this? It should make our code generally less error-prone.
As we work on legacy/trac#23847, I bet we will find it extremely helpful.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24333Fix TROVE-2017-012: Relays can pick themselves in a circuit path2020-06-27T13:54:55ZteorFix TROVE-2017-012: Relays can pick themselves in a circuit pathTicket for medium severity issue TROVE-2017-012
See https://trac.torproject.org/projects/tor/wiki/TROVE
```
TROVE-2017-012: Relays can pick themselves in a circuit path
SEVERITY: Medium
ALSO TRACKED AS: CVE-2017-8822
DESCRIPTION
...Ticket for medium severity issue TROVE-2017-012
See https://trac.torproject.org/projects/tor/wiki/TROVE
```
TROVE-2017-012: Relays can pick themselves in a circuit path
SEVERITY: Medium
ALSO TRACKED AS: CVE-2017-8822
DESCRIPTION
A relay can open circuits for reachability purposes, preemptive
Exit circuits or possible onion service client usage. If a relay
doesn't have the descriptors of all the relays in the network, it
is possible for the relay to pick itself in a circuit path like so
(R1: Relay, G: Guard, E: Exit):
R1 -> G -> R1 -> E
This leads to a log warning on the Guard node and the circuit
being closed immediately because tor doesn't allow to extend to
the previous node.
Furthermore, a relay can also pick itself as a primary guard,
leading to it being unable to open any circuits for a while, until
enough failures have been recorded and the guard is switched.
This can only happens if the relay doesn't have all descriptors
downloaded yet, and if it considers itself in the consensus.
This affects version >= 0.2.0.x series which is basically every
relay on the network.
MITIGATION NOTES:
1. If you are using tor but it is not configured as a relay, this
doesn't affect you.
2. This can have anonymity consequences if you are running a
onion service and a relay at the same time on the same tor
instance. It is something we do NOT recommend in the first
place, so: avoid doing this.
ACKNOWLEDGMENTS:
Thanks to the Tor network team members who tracked this down!
FIX:
Everyone affected should upgrade to one of the releases with the fix
for this issue: 0.2.5.16, 0.2.8.17, 0.2.9.14, 0.3.0.13, 0.3.1.9, or
0.3.2.6-alpha.
```Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24322make IPv6-only clients bootstrap without needing config changes.2020-06-27T13:54:56Zdkgmake IPv6-only clients bootstrap without needing config changes.legacy/trac#17281 suggests that an IPv6-only client should be able to bootstrap by setting some flags in torrc. I've done:
```
ClientUseIPv4 0
ClientUseIPv6 1
```
But, most clients are not *always* IPv4-only or IPv6-only. In particul...legacy/trac#17281 suggests that an IPv6-only client should be able to bootstrap by setting some flags in torrc. I've done:
```
ClientUseIPv4 0
ClientUseIPv6 1
```
But, most clients are not *always* IPv4-only or IPv6-only. In particular, i tend to move my laptop between networks that have different properties (i'm writing this from a v6-only network).
I shouldn't have to fiddle with my torrc to make tor work. it should be able to auto-detect this situation and do the right thing automatically.https://gitlab.torproject.org/tpo/core/tor/-/issues/24318Clarify that the RelayBandwidth* options exclude directory fetches by relays2021-07-22T16:21:37ZteorClarify that the RelayBandwidth* options exclude directory fetches by relaysTwice in the last few months, I have explained to relay operators that RelayBandwidthRate/Burst includes directory fetches from the relay by clients. But they do not include directory fetches by the relay (from authorities or other relay...Twice in the last few months, I have explained to relay operators that RelayBandwidthRate/Burst includes directory fetches from the relay by clients. But they do not include directory fetches by the relay (from authorities or other relays), because that is considered "client" activity.
We should clarify in the man page, because it clearly causes some confusion.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24317Do not use same country in the Tor circuits2020-06-27T13:54:56ZcypherpunksDo not use same country in the Tor circuitsRecently, Tor circuits often choose paths trough the same country. Paths with three relays within the same country occur frequently but should be a bad idea. This makes it easier for attackers with nation-wide power. The risk of correlat...Recently, Tor circuits often choose paths trough the same country. Paths with three relays within the same country occur frequently but should be a bad idea. This makes it easier for attackers with nation-wide power. The risk of correlation attacks should be mitigated by using relays located across different countries.https://gitlab.torproject.org/tpo/core/tor/-/issues/24315sandbox incompatible with glibc 2.26 (openat() not handled for all our files)2020-06-27T13:54:56ZDavid Gouletdgoulet@torproject.orgsandbox incompatible with glibc 2.26 (openat() not handled for all our files)If I enable the sandbox on my system, I get killed with:
```
(Sandbox) Caught a bad syscall attempt (syscall openat)
/usr/lib/x86_64-linux-gnu/libasan.so.4(+0x558c0)[0x7fb5203ab8c0]
/lib/x86_64-linux-gnu/libpthread.so.0(open64+0x4e)[0x7...If I enable the sandbox on my system, I get killed with:
```
(Sandbox) Caught a bad syscall attempt (syscall openat)
/usr/lib/x86_64-linux-gnu/libasan.so.4(+0x558c0)[0x7fb5203ab8c0]
/lib/x86_64-linux-gnu/libpthread.so.0(open64+0x4e)[0x7fb51ec6667e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13150)[0x7fb51ec67150]
/lib/x86_64-linux-gnu/libpthread.so.0(open64+0x4e)[0x7fb51ec6667e]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(evutil_open_closeonexec_+0x20)[0x7fb51fbb5540]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(evutil_read_file_+0x53)[0x7fb51fbb5603]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(evdns_base_load_hosts+0x8b)[0x7fb51fbc429b]
/home/dgoulet/Documents/git/tor/src/or/tor(+0x9f7adf)[0x55aa44446adf]
/home/dgoulet/Documents/git/tor/src/or/tor(do_main_loop+0x745)[0x55aa440f01d5]
/home/dgoulet/Documents/git/tor/src/or/tor(tor_run_main+0x1895)[0x55aa440f4065]
/home/dgoulet/Documents/git/tor/src/or/tor(tor_main+0x86)[0x55aa440e1fb6]
/home/dgoulet/Documents/git/tor/src/or/tor(main+0x1c)[0x55aa440df20c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fb51db741c1]
/home/dgoulet/Documents/git/tor/src/or/tor(_start+0x2a)[0x55aa440e1c6a]
```
strace output:
```
19360 openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 257
19360 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x7f7d90ab667e, si_syscall=__NR_openat, si_arch=AUDIT_ARCH_X86_64 ---}
```
It is the first file being opened _after_ the seccomp sandbox has been applied. Our sandbox code only considers "open()" to touch that file:
`OPEN("/etc/hosts");`
My libc is 2.26.
We probably need to handle the same files with `openat()` as we do with `open()` for this.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24313Crash: died: Caught signal 11 [crash from rend_consider_services_intro_points]2020-06-27T13:54:56ZcypherpunksCrash: died: Caught signal 11 [crash from rend_consider_services_intro_points]```
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Ignoring directory request, since no bridge nodes are ...```
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 892 buildtimes.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6124/6450).
[notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6124/6450).
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
============================================================ T= 1510821832
Tor 0.3.2.3-alpha (git-894b61b1d19f6235) died: Caught signal 11
/usr/bin/tor(+0x1830c9)[0x55c71b98d0c9]
/usr/bin/tor(extend_info_free+0x1d)[0x55c71b8e0add]
/usr/bin/tor(extend_info_free+0x1d)[0x55c71b8e0add]
/usr/bin/tor(rend_intro_point_free+0x25)[0x55c71b88a8d5]
/usr/bin/tor(rend_consider_services_intro_points+0x5c4)[0x55c71b894744]
/usr/bin/tor(hs_service_run_scheduled_events+0xa1c)[0x55c71b97c15c]
/usr/bin/tor(+0x4e931)[0x55c71b858931]
/usr/bin/tor(+0x6e6d0)[0x55c71b8786d0]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0)[0x7f0067487420]
/usr/bin/tor(do_main_loop+0x29d)[0x55c71b85be1d]
/usr/bin/tor(tor_main+0x1c25)[0x55c71b85f925]
/usr/bin/tor(main+0x19)[0x55c71b8575c9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f0065ea31c1]
/usr/bin/tor(_start+0x2a)[0x55c71b85761a]
```Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24312Update DirCache Warning2020-06-27T13:54:56ZcypherpunksUpdate DirCache WarningWhen DirCache is disabled tor 0.3.1.x says:
```
[warn] DirCache is disabled and we are configured as a relay. This may disqualify us from becoming a guard in the future.
```
Since TorBrowser ships tor 0.3.1.x we can consider this as gr...When DirCache is disabled tor 0.3.1.x says:
```
[warn] DirCache is disabled and we are configured as a relay. This may disqualify us from becoming a guard in the future.
```
Since TorBrowser ships tor 0.3.1.x we can consider this as granted (not in the future), right?Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24308MaxMemInCellQueues minimum of 256MB is still too large for low-RAM relays (LE...2020-08-18T12:53:14ZTracMaxMemInCellQueues minimum of 256MB is still too large for low-RAM relays (LEDE and OpenWRT routers)The minimum value for torrc configuration MaxMemInCellQueues of 256MB is still too large for memory constrained relays. I've been running a tor relay on my OpenWRT router for a few years reliably. I recently upgraded the router to use to...The minimum value for torrc configuration MaxMemInCellQueues of 256MB is still too large for memory constrained relays. I've been running a tor relay on my OpenWRT router for a few years reliably. I recently upgraded the router to use tor 0.2.9.12 where MaxMemInCellQueues is minimally defaulted to 256MB, even if the router only has 128 MB. Naturally, Linux oom-killer kills it after a few hours. I have a lot of bandwidth but I can't share it now...
This is related to ticket legacy/trac#9686
```
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.070987] Mem-Info:
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] active_anon:18341 inactive_anon:51 isolated_anon:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] active_file:35 inactive_file:73 isolated_file:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] unevictable:0 dirty:0 writeback:0 unstable:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] slab_reclaimable:728 slab_unreclaimable:2804
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] mapped:41 shmem:1120 pagetables:102 bounce:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] free:4723 free_pcp:40 free_cma:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.106437] Normal free:18892kB min:16384kB low:20480kB high:24576kB active_anon:73364kB inactive_anon:204kB active_file:
140kB inactive_file:292kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:131072kB managed:125640kB mlocked:0kB dirty:0kB writeback:0kB mapped:164kB shmem
:4480kB slab_reclaimable:2912kB slab_unreclaimable:11216kB kernel_stack:544kB pagetables:408kB unstable:0kB bounce:0kB free_pcp:160kB local_pcp:160kB free_cma:0kB write
back_tmWed Nov 15 11:24:32 2017 kern.warn kernel: [221491.151989] lowmem_reserve[]: 0 0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.155468] Normal: 763*4kB (UMEH) 446*8kB (UMEH) 255*16kB (UMEH) 44*32kB (UME) 20*64kB (UMEH) 3*128kB (UME) 2*256kB (UH)
1*512kB (U) 4*1024kB (UMH) 0*2048kB 0*4096kB = 18892kB
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.171705] 1228 total pagecache pages
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.175610] 0 pages in swap cache
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.179077] Swap cache stats: add 0, delete 0, find 0/0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.184476] Free swap = 0kB
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.187482] Total swap = 0kB
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.190505] 32768 pages RAM
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.193422] 0 pages HighMem/MovableOnly
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.197412] 1358 pages reserved
Wed Nov 15 11:24:32 2017 kern.info kernel: [221491.200683] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
...
Wed Nov 15 11:24:32 2017 kern.info kernel: [221491.370877] [28850] 52 28850 21220 15276 25 0 0 0 tor
Wed Nov 15 11:24:32 2017 kern.info kernel: [221491.379539] [ 9935] 0 9935 296 9 3 0 0 0 sleep
Wed Nov 15 11:24:32 2017 kern.err kernel: [221491.388387] Out of memory: Kill process 28850 (tor) score 487 or sacrifice child
Wed Nov 15 11:24:32 2017 kern.err kernel: [221491.396016] Killed process 28850 (tor) total-vm:84880kB, anon-rss:61096kB, file-rss:8kB
```
**Trac**:
**Username**: pmetrasTor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24303Tor fails to start if %include2020-06-27T13:54:57ZTracTor fails to start if %includeIf %include is present in torrc then tor service will fail to start.
The directive I aded to torrc was
%include /etc/torrc.d/
Folder exist and perms are valid, but tor service will not start and tor will not write the reason why to log...If %include is present in torrc then tor service will fail to start.
The directive I aded to torrc was
%include /etc/torrc.d/
Folder exist and perms are valid, but tor service will not start and tor will not write the reason why to log.
**Trac**:
**Username**: littlefeatherTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24300Failed to find node for hop #1 of our path. Discarding this circuit2020-07-28T15:53:25ZDavid Gouletdgoulet@torproject.orgFailed to find node for hop #1 of our path. Discarding this circuitBeen two days in a row with git master (033-alpha), when I boot up my computer and tor starts and fails to bootstrap. It takes around 8 minutes before it finally work.
The particularity I have with my tor client is that I pin my `EntryN...Been two days in a row with git master (033-alpha), when I boot up my computer and tor starts and fails to bootstrap. It takes around 8 minutes before it finally work.
The particularity I have with my tor client is that I pin my `EntryNodes` with one specific Guard for testing purposes and I stumbled on this issue.
Attached to the ticket are the info logs from the start of tor up to the 100% bootstrap.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24299Allow onion services to distinguish clients from each other2022-10-11T23:40:02ZGeorge KadianakisAllow onion services to distinguish clients from each otherWe should provide onion services with the option to distinguish their anonymous users from each other, and also to handle those clients in a clinical way to do diagnostics, rate-limiting, abusive client blocking, etc.
One proposed way t...We should provide onion services with the option to distinguish their anonymous users from each other, and also to handle those clients in a clinical way to do diagnostics, rate-limiting, abusive client blocking, etc.
One proposed way to do so comes from an old tor-dev thread which suggests we assign a virtual IP to each client based on the circuit ID:
https://lists.torproject.org/pipermail/tor-dev/2014-March/006610.html
I2P seems to have implemented a derivative of this idea. I wonder how it works for them:
https://github.com/i2p/i2p.i2p/blob/920b14212fa80a3a0e92d6e919fdae7e39ed22d5/apps/i2ptunnel/java/src/net/i2p/i2ptunnel/I2PTunnelServer.java#L739Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24298Better handling of DoS attacks on onion services2022-10-11T23:40:02ZGeorge KadianakisBetter handling of DoS attacks on onion servicesWe have received various reports on attackers being able to DoS onion services in various ways. Examples:
a) Layer-7 attacks where the attacker spams HTTP requests: https://www.hackerfactor.com/blog/index.php?/archives/777-Stopping-Tor-...We have received various reports on attackers being able to DoS onion services in various ways. Examples:
a) Layer-7 attacks where the attacker spams HTTP requests: https://www.hackerfactor.com/blog/index.php?/archives/777-Stopping-Tor-Attacks.html
b) DoS through the Tor protocol (intense circuit construction #16052m legacy/trac#15515).
We should come up with designs and plans on how to mitigate those DoS attacks better in the future.
Due to the anonymous unlinkable nature of Tor onion service clients, these designs should be modular enough so that onion service operators can write their own anti-DoS modules to handle specific cases of attacks.
This is a parent ticket to handle the various subtasks.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24279configure libevent leaks2020-06-27T13:54:57ZAlex Xuconfigure libevent leaksbreaks build with "CFLAGS=-fsanitize=address". probably be better just to use pkg-config, but...breaks build with "CFLAGS=-fsanitize=address". probably be better just to use pkg-config, but...Tor: 0.3.2.x-finalAlex XuAlex Xuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24272Add a CacheDirectory option2020-06-27T13:54:57ZteorAdd a CacheDirectory optionTor puts a large number of large, rapidly changing documents in its DataDirectory, which defaults to /var/lib on many systems. This means that the size of backups blows out when running tor 0.3.1.1-alpha or later.
If we added a CacheDir...Tor puts a large number of large, rapidly changing documents in its DataDirectory, which defaults to /var/lib on many systems. This means that the size of backups blows out when running tor 0.3.1.1-alpha or later.
If we added a CacheDirectory option, it could default to /var/cache (or the appropriate paths on other operating systems), and be ignored by most backup tools.
This directory should contain
* cached directory documents, including cached (micro)descriptors and consensuses, and compressed directory document diffs
* any other files that tor can easily regenerate or re-download
This might also benefit mobile users with small disks, but application size appears to be less of a priority for mobile developers than CPU or network usage.
This is a breaking change for tools that expect to find consensuses in the data directory. Perhaps we should make CacheDirectory default to DataDirectory instead?
See this thread for background:
https://lists.torproject.org/pipermail/tor-relays/2017-November/013542.htmlTor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24269Raise a FATAL error if the user tried to combine v2 and prop224 hidden servic...2020-08-05T12:11:46ZcypherpunksRaise a FATAL error if the user tried to combine v2 and prop224 hidden service in same directoryA user is hosting a hidden service:
Hid /path/to/key/hs-www/
hidport 127.0.0.1:80 80
What will happen if he add "HidVersion V3" line to the middle of the config?
Hid /path/to/key/hs-www/
HidVersion V3
hidport 127.0.0.1:80 80
Tor shou...A user is hosting a hidden service:
Hid /path/to/key/hs-www/
hidport 127.0.0.1:80 80
What will happen if he add "HidVersion V3" line to the middle of the config?
Hid /path/to/key/hs-www/
HidVersion V3
hidport 127.0.0.1:80 80
Tor should detect this misconfiguration and raise an error.
(v2 and v3 keys should not exist in same directory)
should be;
==============================
Hid /path/to/key/hs-www/
hidport 127.0.0.1:80 80
Hid /path/to/key/hs-www-v3/
HidVersion V3
hidport 127.0.0.1:80 80
==============================