Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:57:50Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20615Your Guard is failing an extremely large amounts of circuits.2020-06-27T13:57:50ZTracYour Guard is failing an extremely large amounts of circuits.Hello,
Its been several weeks, I am experiencing some problems with tor.
Few weeks ago I started experiencing some connection drops, highly inconsistent bandwidth.
I use to connect my RDP's through tor but connections are dropping abrup...Hello,
Its been several weeks, I am experiencing some problems with tor.
Few weeks ago I started experiencing some connection drops, highly inconsistent bandwidth.
I use to connect my RDP's through tor but connections are dropping abruptly after every few minutes, speed is also highly fluctuating, I never had this problem before.
Then I decided to look at ARM, and I been seeing these messages over and over again.
*TIME* [WARN] Your Guard ---- ($****) is failing an extremely large amounts of circuits.
This could indicate a route manipulation attack, extreme network overload or a bug. Success counts are ---.
Use counts are ---. --- cicuits completed. --- were unusable, --- collapsed and --- timed out. For referrence,
your timeout cutoff is 60 seconds.
*TIME* [WARN] Your Guard ----- ($****) is failing a very large amounts of circuits.
Most likely this means The Tor network is overloaded, but it could also mean an attack against you or
potentially the guard itself. Success counts .... etc.
And
circuit_package_rely_cell(): Bug: outgoing reply cell sent from ../src/or/rely.c:701 has n_chan==NULL.
Dropping.
What is this? is this some kind of attack?
I tried researching about same errors, but with no avail.
I am using physical isolation technique through virtual environment.
I was using Tor 0.2.8.9 then I decided to try older versions but still the same problem.
**Trac**:
**Username**: bug_bunnyTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20020Strange Warning: "Couldn't add re-parsed router: Some certs on this router ar...2020-06-27T13:58:18ZTracStrange Warning: "Couldn't add re-parsed router: Some certs on this router are expired."Today I updated my bridge to Tor 0.2.8.7 due to the upcoming bridge authority switch.
After some hours of operation I see in the log the following warning:
"Couldn't add re-parsed router: Some certs on this router are expired."
Can so...Today I updated my bridge to Tor 0.2.8.7 due to the upcoming bridge authority switch.
After some hours of operation I see in the log the following warning:
"Couldn't add re-parsed router: Some certs on this router are expired."
Can someone please explain what this warning means. Is this something I have to worry about?
**Trac**:
**Username**: torlandTor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19990EntryNodes is incompatible with IPv6-only bootstrap2020-06-27T13:58:20ZteorEntryNodes is incompatible with IPv6-only bootstrapWhen UseMicrodescriptors is 1, tor clients which bootstrap over IPv6 have to get descriptors from the fallback directories, because there are no IPv6 addresses in the microdescriptor consensus.
When EntryNodes is set, it excludes all th...When UseMicrodescriptors is 1, tor clients which bootstrap over IPv6 have to get descriptors from the fallback directories, because there are no IPv6 addresses in the microdescriptor consensus.
When EntryNodes is set, it excludes all the fallback directories, meaning that IPv6 clients can't bootstrap.
This can be tested with:
```
src/or/tor DataDirectory /tmp/tor.$$ SOCKSPort 0 EntryNodes x ClientUseIPv4 0
```Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19610IPv6-only clients fetch microdescriptors from a small number of IPv6 fallbacks2020-11-04T14:18:56ZteorIPv6-only clients fetch microdescriptors from a small number of IPv6 fallbacksWhen an IPv6-only client bootstraps using microdescriptors (legacy/trac#19608), it fetches the microdescriptor consensus from an IPv6 fallback, but the microdescriptor consensus has no IPv6 addresses.
So it falls back to the fallback di...When an IPv6-only client bootstraps using microdescriptors (legacy/trac#19608), it fetches the microdescriptor consensus from an IPv6 fallback, but the microdescriptor consensus has no IPv6 addresses.
So it falls back to the fallback directories, fetching ~7500/500 = 15 sets of descriptors from 15 of the 25 IPv6 fallbacks.
We should improve this behaviour somehow, to avoid overloading the fallbacks. One simple way of doing this is selecting 200 fallbacks for 0.2.9 in legacy/trac#18828.
It's worth noting that this extra load only happens on bootstrap, when there are no cached microdescriptors. If an IPv6-only client has any IPv6 microdescriptors that match the current consensus, it will use those relays instead.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13837Mitigate guard discovery by pinning middle node2020-06-27T14:02:09ZGeorge KadianakisMitigate guard discovery by pinning middle nodeHello,
inspired by the recent discussions on guard discovery, I went ahead
and implemented a small patch for Tor that tries to help defend
against Hidden Service guard discovery attacks.
It basically allows the operator to specify a se...Hello,
inspired by the recent discussions on guard discovery, I went ahead
and implemented a small patch for Tor that tries to help defend
against Hidden Service guard discovery attacks.
It basically allows the operator to specify a set of nodes that will
be pinned as middle nodes in Hidden Service rendezvous circuits. The
option only affects HS rendezvous circuits and nothing else.
Of course, it doesn't fix guard discovery, it just pushes guard
discovery to the next hop, so that they need to compromise two boxes
to win.
You can find my branch in 'sticky_mids' at
https://git.torproject.org/user/asn/tor.git .
(Here it is in HTTP shape:
https://gitweb.torproject.org/user/asn/tor.git/shortlog/refs/heads/sticky_mids )
[This is the trac version of https://lists.torproject.org/pipermail/tor-dev/2014-November/007730.html]Tor: 0.3.3.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13605Create a client/relay-side ReducedExitPolicy2020-06-27T14:02:18ZMike PerryCreate a client/relay-side ReducedExitPolicyWe should have an "ExitPolicy Reduced" or "ReducedExitPolicy 1" torrc option for relay operators to more easily opt in to https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy.
We have a lot of people doing this on an ad-h...We should have an "ExitPolicy Reduced" or "ReducedExitPolicy 1" torrc option for relay operators to more easily opt in to https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy.
We have a lot of people doing this on an ad-hoc basis. We should make it official.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13043torspec lies about accepting both IPv4 and IPv6 for ORAddress lines2020-06-27T14:02:36ZIsis Lovecrufttorspec lies about accepting both IPv4 and IPv6 for ORAddress lines(From [this comment on #9380](https://trac.torproject.org/projects/tor/ticket/9380#comment:27))
**tl;dr**: The `"a"`/`"or-address"` lines, _in implementation_, only happen once each per router, and only ever contain IPv6 addresses, desp...(From [this comment on #9380](https://trac.torproject.org/projects/tor/ticket/9380#comment:27))
**tl;dr**: The `"a"`/`"or-address"` lines, _in implementation_, only happen once each per router, and only ever contain IPv6 addresses, despite what `dir-spec.txt` says.
The spec [says](https://gitweb.torproject.org/torspec.git/blob/d4cb76a81f26dcc41a2c2041b12977dfdf62c3f8:/dir-spec.txt#l1166):
```
"a" SP address ":" port NL
[Any number]
The "or-address" element as specified in section 2.1.1.
```
[and](https://gitweb.torproject.org/torspec.git/blob/d4cb76a81f26dcc41a2c2041b12977dfdf62c3f8:/dir-spec.txt#l587):
```
"or-address" SP ADDRESS ":" PORT NL
[Any number]
ADDRESS = IP6ADDR | IP4ADDR
IPV6ADDR = an ipv6 address, surrounded by square brackets.
IPV4ADDR = an ipv4 address, represented as a dotted quad.
PORT = a number between 1 and 65535 inclusive.
An alternative for the address and ORPort of the "router" line, but with
two added capabilities:
* or-address can be either an IPv4 or IPv6 address
* or-address allows for multiple ORPorts and addresses
A descriptor SHOULD NOT include an or-address line that does nothing but
duplicate the address:port pair from its "router" line.
The ordering of or-address lines and their PORT entries matter because
Tor MAY accept a limited number of addresses or ports. As of Tor 0.2.3.x
only the first address and the first port are used.
```
- In terms of how many `"a"`/`"or-address"` lines there may be, the spec is only correct if you pay _super close attention to the last sentence_ (this is actually the first time I've noticed it :) ).
- In terms of whether IPv4 and/or IPv6 addresses are acceptable, _the spec is currently wrong_, according to the functions `router_rebuild_descriptor()` [https://gitweb.torproject.org/tor.git/blob/9f9b19ed7b06d8313a9bcbd6647fa097ec0a059d:/src/or/router.c#l1811 [source]] and `router_dump_router_to_string()` [https://gitweb.torproject.org/tor.git/blob/9f9b19ed7b06d8313a9bcbd6647fa097ec0a059d:/src/or/router.c#l2330 [source]] in `src/or/router.c` in tor's source code.Tor: 0.3.3.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12062Audit DisableNetwork, we_are_hibernating usage2022-05-07T06:54:09ZNick MathewsonAudit DisableNetwork, we_are_hibernating usageI think a lot of our DisableNetwork checks should instead check net_is_disabled, since so much of what we're doing turning off when the network is disabled is also something we're trying to turn off when we're hibernating.
And probably ...I think a lot of our DisableNetwork checks should instead check net_is_disabled, since so much of what we're doing turning off when the network is disabled is also something we're trying to turn off when we're hibernating.
And probably some of our DisableNetwork checks should call should_delay_dir_fetches or something similar, if they're related to fetching non-bridge-descriptor directory stuff.
Possibly there should be a better designed hierarchy here.
Possibly, most of the fixes here should wait for 0.2.6, since this code is tricky.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6767tor crashes with Assertion smartlist_get(rl->old_routers, idx) == sd failed2020-06-27T14:05:48ZLeonid Evdokimovtor crashes with Assertion smartlist_get(rl->old_routers, idx) == sd failedI started my gateway with stderr redirected to syslog and got following crash:
```
Sep 2 12:30:07 OpenWrt cron.info crond[708]: crond: USER root pid 1794 cmd /root/tor-watchdog.sh
Sep 2 12:43:19 OpenWrt daemon.err Tor[1280]: routerlist...I started my gateway with stderr redirected to syslog and got following crash:
```
Sep 2 12:30:07 OpenWrt cron.info crond[708]: crond: USER root pid 1794 cmd /root/tor-watchdog.sh
Sep 2 12:43:19 OpenWrt daemon.err Tor[1280]: routerlist_remove_old(): Bug: routerlist.c:3004: routerlist_remove_old: Assertion idx == sd->routerlist_index failed; aborting.
Sep 2 12:43:21 OpenWrt user.notice tor.stdout: routerlist.c:3004 routerlist_remove_old: Assertion idx == sd->routerlist_index failed; aborting.
Sep 2 12:45:01 OpenWrt cron.info crond[708]: crond: USER root pid 1797 cmd /root/tor-watchdog.sh
Sep 2 12:45:01 OpenWrt user.notice Tor.watchdog: pidfile exists and process is missing - start
Sep 2 12:45:02 OpenWrt user.notice Tor.init: Sep 02 12:45:02.684 [notice] Tor v0.2.2.37 (git-fce6eb1c44e87bc2). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux mips)
```
OpenWrt package versions: libopenssl - 1.0.1c-1, tor - 0.2.2.37-1
openssl build information:
```
root@OpenWrt:~# strings /usr/lib/libcrypto.so.1.0.0 | grep gcc
libgcc_s.so.1
mipsel-openwrt-linux-uclibc-gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DDSO_DLFCN -DHAVE_DLFCN_H -I/home/fnord/slave/brcm47xx/build/staging_dir/target-mipsel_uClibc-0.9.33.2/usr/include -I/home/fnord/slave/brcm47xx/build/staging_dir/target-mipsel_uClibc-0.9.33.2/include -I/home/fnord/slave/brcm47xx/build/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/usr/include -I/home/fnord/slave/brcm47xx/build/staging_dir/toolchain-mipsel_gcc-4.6-linaro_uClibc-0.9.33.2/include -DOPENSSL_SMALL_FOOTPRINT -DHAVE_CRYPTODEV -DOPENSSL_NO_ERR -DTERMIO -Os -pipe -mips32 -mtune=mips32 -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -fpic -DOPENSSL_THREADS -pthread -D_REENTRANT -D_THREAD_SAFE -D_THREADSAFE -fomit-frame-pointer -Wall
```Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3940Allow MapAddress .exit even if AllowDotExit is 02020-06-27T14:07:46ZSteven MurdochAllow MapAddress .exit even if AllowDotExit is 0If AllowDotExit is 0 (the default) MapAddress doesn't permit a .exit address to be set as the destination. It is desirable to keep AllowDotExit disabled for security reasons, but there shouldn't be any harm in always permitting MapAddres...If AllowDotExit is 0 (the default) MapAddress doesn't permit a .exit address to be set as the destination. It is desirable to keep AllowDotExit disabled for security reasons, but there shouldn't be any harm in always permitting MapAddress entries because the user must enter these manually. This feature is desirable because it allows the user to force exit enclaving.
Using Tor v0.2.2.32 (git-877e17749725ab88).Tor: 0.3.3.x-final