The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:57:19Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21293circuit_receive_relay_cell(): Bug: relay crypt failed. Dropping connection.2020-06-27T13:57:19Zs7rcircuit_receive_relay_cell(): Bug: relay crypt failed. Dropping connection.I've hit this today on a machine running Debian Jessie and Tor `0.3.0.1-alpha-dev (git-1a45398ffa713ca3+5156f73)` acting as an onion service client with a SocksPort open and used as well. Functionality appears not to be affected, everyth...I've hit this today on a machine running Debian Jessie and Tor `0.3.0.1-alpha-dev (git-1a45398ffa713ca3+5156f73)` acting as an onion service client with a SocksPort open and used as well. Functionality appears not to be affected, everything continues to run normally.
Besides the incoming rendezvous traffic, this instance also sends outgoing traffic via the SocksPort but to .onion destinations only, so it's mostly rendezvous traffic.
```
Jan 23 15:31:44.000 [warn] circuit_receive_relay_cell(): Bug: relay crypt failed. Dropping connection. (on Tor 0.3.0.1-alpha-dev )
```Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/21295Allow mixed anonymous and non-anonymous onion services in the same tor instance2020-06-27T13:57:18ZteorAllow mixed anonymous and non-anonymous onion services in the same tor instanceSimilar to legacy/trac#21284, some single onion service users want to be able to use hidden (double onion) services most of the time, and single onion services occasionally with trusted peers.
For example, see the OnionShare use case in...Similar to legacy/trac#21284, some single onion service users want to be able to use hidden (double onion) services most of the time, and single onion services occasionally with trusted peers.
For example, see the OnionShare use case in:
https://lists.torproject.org/pipermail/tor-dev/2017-January/011782.html
One potential anonymity issue is that any introduction and rendezvous points see the single onion service's IP addresses, as does anyone with access to the networks those relays are on.
But anyone with access to the network the single onion service is on also sees its IP address, and that it is creating tor traffic. So I'm not sure how much of a threat this is.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21300Recent changes broke GETCONF *Port2020-06-27T13:57:18ZDamian JohnsonRecent changes broke GETCONF *PortHi Nick, shot ya an email earlier about this. Tor changes pushed yesterday broke stem's integ tests. In particular GETCONF is broke. Repro is simple. Here's an example...
```
% ./tor-prompt
>>> GETINFO config-text
250+config-text=
Cont...Hi Nick, shot ya an email earlier about this. Tor changes pushed yesterday broke stem's integ tests. In particular GETCONF is broke. Repro is simple. Here's an example...
```
% ./tor-prompt
>>> GETINFO config-text
250+config-text=
ControlPort 9051
CookieAuthentication 1
DataDirectory /home/atagar/.tor
ExitPolicy reject *:*
HiddenServiceStatistics 0
Log notice stdout
SocksPort 0
.
250 OK
>>> GETCONF ControlPort
250 ControlPort
```
Thanks!Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21302hs: Multiple service issues2020-06-27T13:57:18ZDavid Gouletdgoulet@torproject.orghs: Multiple service issuesWhile investigating legacy/trac#21297, I found several issues. Unfortunately, I can't find the cause of legacy/trac#21297 yet but maybe someone will with that list of issues.
1) Integer overflow in `rend_consider_services_intro_points()...While investigating legacy/trac#21297, I found several issues. Unfortunately, I can't find the cause of legacy/trac#21297 yet but maybe someone will with that list of issues.
1) Integer overflow in `rend_consider_services_intro_points()`. We have a safe guard against that *except* if the `expiring_nodes` list is not empty which is totally a possibility. This is bad because it will ultimately create a LOT of IP circuits and fail in unknown ways...
```
if (smartlist_len(service->expiring_nodes) == 0 &&
intro_nodes_len >= service->n_intro_points_wanted) {
continue;
}
/* Number of intro points we want to open which is the wanted amount
* minus the current amount of valid nodes. */
n_intro_points_to_open = service->n_intro_points_wanted - intro_nodes_len;
```
2) In `rend_service_intro_has_opened()`, this if is subject to a bad "cast overflow" if we have a case that brings the `expiring_nodes` size bigger than the number of circuits. The following result is cast as an `unsigned int` so for instance "5 - 6" is actually a BIG number.
```
if ((count_intro_point_circuits(service) -
smartlist_len(service->expiring_nodes)) >
service->n_intro_points_wanted) {
```
The consequence of this is that if we have a bug (maybe legacy/trac#21297!!) that brings the size of `expiring_nodes` to 6 and then we try to open 5 IP circuits for the service (3 + 2 extras), all 5 will always be closed and it will loop non stop.
3) In `remove_invalid_intro_points()`, if we put an IP object in the `retry_nodes` list and this IP also expires, it will be put in the `expiring_nodes` list of the service and *removed* from the service valid list. After this, we'll retry a circuit to that IP object but since it's not in the valid list anymore, the `rend_consider_services_intro_points()` will launch a bunch of other IP circuit(s) ignoring the one being retried. This is OK because the one we want to retry should actually expire BUT we could avoid a useless circuit being created since we know it will expire and potential bug of losing the reference to that circuit if we have issues with cleaning up our `expiring_nodes` list.
My theory is that the solution to legacy/trac#21297 lies in a combination of the above bugs. Either we overflow with (2) or we have IP circuits that we've lost the reference to (1) making (2) always closing the 5 circuits we just opened and thus not having any valid IP object for the service. I don't think (1) is involved but you never know.Tor: 0.3.0.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/21334prop224: Update prop224 HS desriptor generation code to produce the latest de...2020-06-27T13:57:17ZGeorge Kadianakisprop224: Update prop224 HS desriptor generation code to produce the latest descriptor formatThis is the older cousin of legacy/trac#20852. In this ticket we need to go over our prop224 HS descriptor generation code and make it produce descriptors that conform with the latest format (which includes the fake client authorization ...This is the older cousin of legacy/trac#20852. In this ticket we need to go over our prop224 HS descriptor generation code and make it produce descriptors that conform with the latest format (which includes the fake client authorization entries and such).Tor: 0.3.1.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/21346Clients with NoIPv4Traffic should only choose IPv6-supporting Exits2020-06-27T13:57:17ZteorClients with NoIPv4Traffic should only choose IPv6-supporting ExitsTor logs a warning when this happens in connection_ap_get_begincell_flags(), but it should actually fail.
Earlier in the process, it should choose an IPv6-supporting exit when NoIPv4Traffic is set (and choose an IPv4-supporting exit whe...Tor logs a warning when this happens in connection_ap_get_begincell_flags(), but it should actually fail.
Earlier in the process, it should choose an IPv6-supporting exit when NoIPv4Traffic is set (and choose an IPv4-supporting exit when NoIPv6 traffic is set).Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/21356[0.2.9.9] Bug: compat_time.c: monotime_coarse_absolute_nsec() called before m...2020-06-27T13:57:16Zcypherpunks[0.2.9.9] Bug: compat_time.c: monotime_coarse_absolute_nsec() called before monotime_init() on windows service```
[notice] Bootstrapped 85%: Finishing handshake with first hop
[warn] tor_bug_occurred_(): Bug: compat_time.c:636: monotime_coarse_absolute_nsec: Non-fatal assertion !(monotime_initialized == 0) failed. (on Tor 0.2.9.9 )
[warn] Bug: N...```
[notice] Bootstrapped 85%: Finishing handshake with first hop
[warn] tor_bug_occurred_(): Bug: compat_time.c:636: monotime_coarse_absolute_nsec: Non-fatal assertion !(monotime_initialized == 0) failed. (on Tor 0.2.9.9 )
[warn] Bug: Non-fatal assertion !(monotime_initialized == 0) failed in monotime_coarse_absolute_nsec at compat_time.c:636. (Stack trace not available) (on Tor 0.2.9.9 )
[notice] Bootstrapped 90%: Establishing a Tor circuit
```
type: Win32 Tor service
result: show error only. Can connect to internet without problem.Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21357potential bug: Some IPv6Exits do not add the ipv6-policy line to their descri...2020-06-27T13:57:16Zcypherpunkspotential bug: Some IPv6Exits do not add the ipv6-policy line to their descriptorAn exit relay is expected to add a ipv6-policy line to its descriptor when:
{{{ IPv6Exit 1 }}
and its exit policy allows at least a single IPv6 destination.
There are 10 known cases where the exit didn't generate an ipv6-policy line.
...An exit relay is expected to add a ipv6-policy line to its descriptor when:
{{{ IPv6Exit 1 }}
and its exit policy allows at least a single IPv6 destination.
There are 10 known cases where the exit didn't generate an ipv6-policy line.
legacy/trac#21355 should help with debugging.
references:
list of exit relays with IPv6 ORPort and no ipv6-policy (if IPv6Exit setting is known, it is shown at the end of the line)
https://gist.githubusercontent.com/nusenu/1534d210049fcb04919ae5a4529ea894/raw/4a5611aedb81c5bc01630433c85e8fc818c01a1d/IPv6Exit%25201%253F
https://lists.torproject.org/pipermail/tor-dev/2017-January/011860.html
https://lists.torproject.org/pipermail/tor-relays/2017-January/011806.htmlTor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21359Build with opaque LibreSSL2020-06-27T13:57:16ZTracBuild with opaque LibreSSLLibreSSL in OpenBSD-current now has opaque structures like recent OpenSSL.
There's a few quirks to this:
LibreSSL doesn't have the SSL_get_client_ciphers() function. It's currently assumed that if OPENSSL_OPAQUE is set that function wi...LibreSSL in OpenBSD-current now has opaque structures like recent OpenSSL.
There's a few quirks to this:
LibreSSL doesn't have the SSL_get_client_ciphers() function. It's currently assumed that if OPENSSL_OPAQUE is set that function will exist.
Fixing this (probably?) shouldn't use LIBRESSL_VERSION_NUMBER because that only changes when a new versions of libresl-portable is released, so the libressl in -current with opaque structures still has the same LIBRESSL_VERSION_NUMBER as the released version of LibreSSL without opaque structures.
The SSL_STATE_STR hasn't changed in LibreSSL like it apparently did in OpenSSL 1.1.0.
**Trac**:
**Username**: rubiateTor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21362Intermittent crash when selected guard lacks a descriptor or routerstatus2020-06-27T13:57:16ZteorIntermittent crash when selected guard lacks a descriptor or routerstatusI see this crash when running make test-network-all with the latest master:
```
Feb 01 16:53:22.000 [info] choose_good_exit_server_general(): Chose exit server '$65B77ACB2E202F610D3D7D12CA7BA1269C945DEB~test002r at 127.0.0.1'
Feb 01 16:...I see this crash when running make test-network-all with the latest master:
```
Feb 01 16:53:22.000 [info] choose_good_exit_server_general(): Chose exit server '$65B77ACB2E202F610D3D7D12CA7BA1269C945DEB~test002r at 127.0.0.1'
Feb 01 16:53:22.000 [debug] extend_info_from_node(): using 127.0.0.1:5002 for test002r
Feb 01 16:53:22.000 [info] extend_info_from_node(): Including Ed25519 ID for $65B77ACB2E202F610D3D7D12CA7BA1269C945DEB~test002r at 127.0.0.1
Feb 01 16:53:22.000 [debug] onion_extend_cpath(): Path is 0 long; we want 3
Feb 01 16:53:22.000 [info] select_entry_guard_for_circuit(): Selected primary guard test000a ($02C177E1A8001A62F9476B8BCFC80B6A7F45AFB8) for circuit.
Feb 01 16:53:22.000 [err] tor_assertion_failed_(): Bug: src/or/circuitbuild.c:2372: onion_extend_cpath: Assertion info || client failed; aborting. (on Tor 0.3.0.2-alpha-dev 6dd7e66019e9aa53)
Feb 01 16:53:22.000 [err] Bug: Assertion info || client failed in onion_extend_cpath at src/or/circuitbuild.c:2372. Stack trace: (on Tor 0.3.0.2-alpha-dev 6dd7e66019e9aa53)
Feb 01 16:53:22.000 [err] Bug: 0 tor 0x000000010872ad34 log_backtrace + 68 (on Tor 0.3.0.2-alpha-dev 6dd7e66019e9aa53)
```
It appears that this check in extend_info_from_node is failing:
```
if (node->ri == NULL && (node->rs == NULL || node->md == NULL))
return NULL;
```
We really shouldn't be selecting a guard unless it passes this test.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21369Tor crashes with tor_assertion_failed_() [Assertion buf->datalen < INT_MAX fa...2020-06-27T13:57:16ZTracTor crashes with tor_assertion_failed_() [Assertion buf->datalen < INT_MAX failed in write_to_buf at ../src/or/buffers.c:832]One (of two) tor instance has crashed two times today:
```
Feb 1 13:15:58 arnor Tor-eriador[5110]: tor_assertion_failed_(): Bug: ../src/or/buffers.c:832: write_to_buf: Assertion buf->datalen < INT_MAX failed; aborting. (on Tor 0.2.9.9 ...One (of two) tor instance has crashed two times today:
```
Feb 1 13:15:58 arnor Tor-eriador[5110]: tor_assertion_failed_(): Bug: ../src/or/buffers.c:832: write_to_buf: Assertion buf->datalen < INT_MAX failed; aborting. (on Tor 0.2.9.9 )
Feb 1 13:15:58 arnor Tor-eriador[5110]: Bug: Assertion buf->datalen < INT_MAX failed in write_to_buf at ../src/or/buffers.c:832.
Stack trace: (on Tor 0.2.9.9 )
Feb 1 13:15:58 arnor Tor-eriador[5110]: Bug: /usr/bin/tor(log_backtrace+0x42) [0x556620673ba2] (on Tor 0.2.9.9 )
Feb 1 13:15:58 arnor Tor-eriador[5110]: Bug: /usr/bin/tor(tor_assertion_failed_+0x8d) [0x55662068b71d] (on Tor 0.2.9.9 )
Feb 1 13:15:58 arnor Tor-eriador[5110]: Bug: /usr/bin/tor(+0xadf7a) [0x5566205daf7a] (on Tor 0.2.9.9 )
Feb 1 13:15:58 arnor Tor-eriador[5110]: Bug: /usr/bin/tor(connection_write_to_buf_impl_+0x294) [0x556620620294] (on Tor 0.2.9.9 )
Feb 1 13:15:58 arnor Tor-eriador[5110]: Bug: /usr/bin/tor(+0x1081e6) [0x5566206351e6] (on Tor 0.2.9.9 )
Feb 1 13:15:58 arnor Tor-eriador[5110]: Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f5a40489a0c] (on Tor 0.2.9.9 )
Feb 1 13:15:58 arnor Tor-eriador[5110]: Bug: /usr/bin/tor(do_main_loop+0x27d) [0x55662057079d] (on Tor 0.2.9.9 )
Feb 1 13:15:58 arnor Tor-eriador[5110]: Bug: /usr/bin/tor(tor_main+0x1c25) [0x556620574105] (on Tor 0.2.9.9 )
Feb 1 13:15:58 arnor Tor-eriador[5110]: Bug: /usr/bin/tor(main+0x19) [0x55662056c1b9] (on Tor 0.2.9.9 )
Feb 1 13:15:58 arnor Tor-eriador[5110]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f5a3f5c4830] (on Tor 0.2.9.9 )
Feb 1 13:15:58 arnor Tor-eriador[5110]: Bug: /usr/bin/tor(_start+0x29) [0x55662056c209] (on Tor 0.2.9.9 )
Feb 1 13:15:58 arnor systemd[1]: tor@eriador.service: Main process exited, code=killed, status=6/ABRT
```
And three hours later:
```
Feb 1 16:54:26 arnor Tor-eriador[24009]: tor_assertion_failed_(): Bug: ../src/or/buffers.c:832: write_to_buf: Assertion buf->datalen < INT_MAX failed; aborting. (on Tor 0.2.9.9 )
Feb 1 16:54:26 arnor Tor-eriador[24009]: Bug: Assertion buf->datalen < INT_MAX failed in write_to_buf at ../src/or/buffers.c:832. Stack trace: (on Tor 0.2.9.9 )
Feb 1 16:54:26 arnor Tor-eriador[24009]: Bug: /usr/bin/tor(log_backtrace+0x42) [0x55744384dba2] (on Tor 0.2.9.9 )
Feb 1 16:54:26 arnor Tor-eriador[24009]: Bug: /usr/bin/tor(tor_assertion_failed_+0x8d) [0x55744386571d] (on Tor 0.2.9.9 )
Feb 1 16:54:26 arnor Tor-eriador[24009]: Bug: /usr/bin/tor(+0xadf7a) [0x5574437b4f7a] (on Tor 0.2.9.9 )
Feb 1 16:54:26 arnor Tor-eriador[24009]: Bug: /usr/bin/tor(connection_write_to_buf_impl_+0x294) [0x5574437fa294] (on Tor 0.2.9.9 )
Feb 1 16:54:26 arnor Tor-eriador[24009]: Bug: /usr/bin/tor(+0x1081e6) [0x55744380f1e6] (on Tor 0.2.9.9 )
Feb 1 16:54:26 arnor Tor-eriador[24009]: Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f164f746a0c] (on Tor 0.2.9.9 )
Feb 1 16:54:26 arnor Tor-eriador[24009]: Bug: /usr/bin/tor(do_main_loop+0x27d) [0x55744374a79d] (on Tor 0.2.9.9 )
Feb 1 16:54:26 arnor Tor-eriador[24009]: Bug: /usr/bin/tor(tor_main+0x1c25) [0x55744374e105] (on Tor 0.2.9.9 )
Feb 1 16:54:26 arnor Tor-eriador[24009]: Bug: /usr/bin/tor(main+0x19) [0x5574437461b9] (on Tor 0.2.9.9 )
Feb 1 16:54:26 arnor Tor-eriador[24009]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f164e881830] (on Tor 0.2.9.9 )
Feb 1 16:54:26 arnor Tor-eriador[24009]: Bug: /usr/bin/tor(_start+0x29) [0x557443746209] (on Tor 0.2.9.9 )
Feb 1 16:54:26 arnor systemd[1]: tor@eriador.service: Main process exited, code=killed, status=6/ABRT
```
The rest of the time everything was okay.
**Trac**:
**Username**: svengoTor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21372Don't crash when we fail to find extend info for a middle node2020-06-27T13:57:15ZteorDon't crash when we fail to find extend info for a middle nodeIn legacy/trac#21242, we eliminated a crash when we failed to find an extend info for a guard in onion_extend_cpath. But we left in an assert for the middle case. (We should also make sure the equivalent exit case is non-fatal.)In legacy/trac#21242, we eliminated a crash when we failed to find an extend info for a guard in onion_extend_cpath. But we left in an assert for the middle case. (We should also make sure the equivalent exit case is non-fatal.)Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21377DirAuths should expose bwauth bandwidth files2020-06-27T13:57:15ZTom Rittertom@ritter.vgDirAuths should expose bwauth bandwidth filesCurrently, DirAuths that vote on bwauth files do not expose the raw voting file they used. This data would be good to archive for debugging and transparency purposes.Currently, DirAuths that vote on bwauth files do not expose the raw voting file they used. This data would be good to archive for debugging and transparency purposes.Tor: 0.4.0.x-finaljugajugahttps://gitlab.torproject.org/tpo/core/tor/-/issues/21394connection timeouts are affecting Tor Browser usability2020-06-27T13:57:15ZArthur Edelsteinconnection timeouts are affecting Tor Browser usabilityI have spent some time watching circuit and stream events while connecting to different sites. I telnet into tor's config port using the following command (using ts to give time stamps):
```
telnet localhost 9151 | ts
```
I open the brow...I have spent some time watching circuit and stream events while connecting to different sites. I telnet into tor's config port using the following command (using ts to give time stamps):
```
telnet localhost 9151 | ts
```
I open the browser console and get the tor password by entering
`m_tb_control_pass`
And then I paste the result like this:
`authenticate [value of m_tb_control_pass]`
Finally I enter
`setevents circ stream`.
What I have noticed is that a significant fraction of new site connections result in at least 1 timeout of 10 seconds. (Tor Browser's CircuitStreamTimeout is set to 0, which results in a timeout equal to MIN_CIRCUIT_STREAM_TIMEOUT, or 10 seconds.) Here's what a timeout looks like:
```
Feb 03 19:00:03 650 STREAM 868 NEW 0 people.torproject.org:443 SOURCE_ADDR=127.0.0.1:50318 PURPOSE=USER
Feb 03 19:00:03 650 CIRC 149 LAUNCHED BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597
Feb 03 19:00:03 650 CIRC 149 EXTENDED [...] BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597 SOCKS_USERNAME="torproject.org" SOCKS_PASSWORD="7d8ea4ccf4ba6345846e0fccacd4d941"
Feb 03 19:00:04 650 CIRC 149 EXTENDED [...] BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597 SOCKS_USERNAME="torproject.org" SOCKS_PASSWORD="7d8ea4ccf4ba6345846e0fccacd4d941"
Feb 03 19:00:04 650 CIRC 149 EXTENDED [...] BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597 SOCKS_USERNAME="torproject.org" SOCKS_PASSWORD="7d8ea4ccf4ba6345846e0fccacd4d941"
Feb 03 19:00:04 650 CIRC 149 BUILT [...] BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597 SOCKS_USERNAME="torproject.org" SOCKS_PASSWORD="7d8ea4ccf4ba6345846e0fccacd4d941"
Feb 03 19:00:04 650 STREAM 868 SENTCONNECT 149 people.torproject.org:443
[...]
Feb 03 19:00:14 650 STREAM 868 DETACHED 149 people.torproject.org:443 REASON=TIMEOUT
Feb 03 19:00:14 650 CIRC 150 LAUNCHED BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:14.588714
```
After a timeout occurs, the tor client closes the circuit, builds a new circuit and attempts to connect to the same site again. This repeats at least 3 times.
I did an experiment where I connected to https://people.torproject.org/~arthuredelstein (a page with hardly any content) and then repeatedly selected "New Tor Circuit for this Site" 50 times.
Here are the results for 50 reloads. Each digit represents the number of 10-second stream timeouts observed before a given connection succeeded.
20020000000000000000002010000000000001000100000103
In other words 8 out of 50 connections showed a timeout. And interestingly, four of these connections exhibited a double or triple timeout (20 or 30 seconds delay).
I think this may be a big part of the perception of Tor Browser as "slow". Actual loading of pages doesn't seem drastically slow to me, and once I have successfully connected to a new site, following links to other pages on the same site (i.e., the same circuit) is usually acceptable.
(I also did another quick test on another site and 5/25 connections had at least 1 timeout.)
So here are some questions for further investigation:
* Why are there so many timeouts? Are any of these timeouts due to silent errors in a Tor node? (If such errors could be promptly reported back to the client, maybe we could avoid the waiting for the long timeout.)
* What's the reason for MIN_CIRCUIT_STREAM_TIMEOUT being 10 seconds? Would it do any harm to make this shorter, say 5 seconds or 2 seconds?
* So many double or triple timeouts are suspicious, because each timeout in a double or triple is reported for a different circuit. Could this mean the connection error is caused by the client or guard rather than a connection failure at the exit node?Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21403prop224: Implement HS descriptor fetching2020-06-27T13:57:15Zhaxxpopprop224: Implement HS descriptor fetchingBefore the client actually can connect to the service, it has to fetch the descriptor first. As already specified in prop224 section 2.1 and 2.2.6
The client needs to parse the service's master public key from the onion address, derive ...Before the client actually can connect to the service, it has to fetch the descriptor first. As already specified in prop224 section 2.1 and 2.2.6
The client needs to parse the service's master public key from the onion address, derive the blinded public key, and then use that blinded public key to fetch the descriptor from the HSDir.
(Note that, this ticket doesn't implement how to pick the HSDir)Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/21406The channel is_client flag is inaccurate2020-06-27T13:57:14ZteorThe channel is_client flag is inaccurateThe channel_t is_client flag is inaccurate: relays set it when the other end uses a CREATE_FAST cell, but usecreatefast is set to 0 in the consensus.
This means that the only time CREATE_FAST is used is when a relay gets an extend reque...The channel_t is_client flag is inaccurate: relays set it when the other end uses a CREATE_FAST cell, but usecreatefast is set to 0 in the consensus.
This means that the only time CREATE_FAST is used is when a relay gets an extend request *without* an ntor key, and the purpose of the circuit is *not* one of the hidden service purposes where TAP is allowed.
See should_use_create_fast_for_circuit() for details.Tor: 0.3.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21415tor_bug_occurred_: Bug: src/or/entrynodes.c:1845: select_entry_guard_for_circ...2020-06-27T13:57:14Zcypherpunkstor_bug_occurred_: Bug: src/or/entrynodes.c:1845: select_entry_guard_for_circuit: Non-fatal assertion !(!guard_has_descriptor(guard)) failed.using public obfs4 bridges.
```
Feb 08 12:13:40.000 [warn] tor_bug_occurred_: Bug: src/or/entrynodes.c:1845: select_entry_guard_for_circuit: Non-fatal assertion !(!guard_has_descriptor(guard)) failed. (on Tor 0.3.0.3-alpha bb2ea3642d54f...using public obfs4 bridges.
```
Feb 08 12:13:40.000 [warn] tor_bug_occurred_: Bug: src/or/entrynodes.c:1845: select_entry_guard_for_circuit: Non-fatal assertion !(!guard_has_descriptor(guard)) failed. (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: Non-fatal assertion !(!guard_has_descriptor(guard)) failed in select_entry_guard_for_circuit at src/or/entrynodes.c:1845. Stack trace: (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: 0 tor 0x000000010f4e3f98 log_backtrace + 73 (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: 1 tor 0x000000010f4f852b tor_bug_occurred_ + 268 (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: 2 tor 0x000000010f40f587 entry_guard_pick_for_circuit + 307 (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: 3 tor 0x000000010f4732b5 guards_choose_guard + 138 (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: 4 tor 0x000000010f400c16 circuit_establish_circuit + 2261 (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: 5 tor 0x000000010f411f1b circuit_build_needed_circs + 751 (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: 6 tor 0x000000010f47f4ef second_elapsed_callback + 811 (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: 7 libevent-2.1.6.dylib 0x000000010f641127 event_process_active_single_queue + 1262 (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: 8 libevent-2.1.6.dylib 0x000000010f63d9d6 event_base_loop + 1189 (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: 9 tor 0x000000010f47eed4 do_main_loop + 1118 (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: 10 tor 0x000000010f4810cd tor_main + 235 (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: 11 tor 0x000000010f3e9775 main + 25 (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
Feb 08 12:13:40.000 [warn] Bug: 12 libdyld.dylib 0x00007fffbc194255 start + 1 (on Tor 0.3.0.3-alpha bb2ea3642d54ff03)
```Tor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21416util/fgets_eagain test failure on FreeBSD2020-06-27T13:57:14ZAlexander Færøyahf@torproject.orgutil/fgets_eagain test failure on FreeBSDThe `util/fgets_again` test currently fails on FreeBSD with the following error:
```
$ ./src/test/test util/fgets_eagain
util/fgets_eagain:
FAIL src/test/test_util.c:3969: assert(retptr OP_EQ buf): 0x0 vs 0x7efe49dea1f0
[fgets_eaga...The `util/fgets_again` test currently fails on FreeBSD with the following error:
```
$ ./src/test/test util/fgets_eagain
util/fgets_eagain:
FAIL src/test/test_util.c:3969: assert(retptr OP_EQ buf): 0x0 vs 0x7efe49dea1f0
[fgets_eagain FAILED]
1/1 TESTS FAILED. (0 skipped)
```
This causes the FreeBSD build-bot to report failure on every commit.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/21420Link certificate start date in the future2020-06-27T13:57:14ZTracLink certificate start date in the futureSome link certificates are generated with start dates in the future. Is this intentional, or a bug?
These lines of code generate a start date for the link certificate. Why does this add two days?
https://github.com/torproject/tor/blob/...Some link certificates are generated with start dates in the future. Is this intentional, or a bug?
These lines of code generate a start date for the link certificate. Why does this add two days?
https://github.com/torproject/tor/blob/9a9f4ffdfa965e50de05a4f1bd8c4d68cfb95f12/src/common/tortls.c#L481-L487
I confirmed this happens in the wild. This code connects to tor relays and inspects the link certificate. (Not beautiful code but it does the job.)
https://github.com/mmcloughlin/torcerts
It doesn't take too long to find an example. One I found just now:
```
addr=117.201.240.2:9001
now=Wed Feb 8 22:05:15 UTC 2017
notBefore=Feb 10 00:00:00 2017 GMT
-----BEGIN CERTIFICATE-----
MIIBtzCCASCgAwIBAgIJAOqgI76M4OOKMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNV
BAMMEHd3dy5iamdpN2d0dS5jb20wHhcNMTcwMjEwMDAwMDAwWhcNMTcwMjE2MjM1
OTU5WjAgMR4wHAYDVQQDDBV3d3cuM242bWNvaWp6Z3Jzai5uZXQwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAKRkfrD4q5HNIkE9lglJjljlZoT15OE3VDE66GYT
hZ/FsCMtGPw1TKj+EB6NyjEYSxP7+EgJOOVGzxb3ybmEs8wJSbVhue8NeavbgcVY
X3UcVyPMFLSDGBKhOADrHztyznMRzDkmMx83OtJH5QpNZvNcMVP0H1QHCFB/YJMY
iIVnAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAvPVq5VcF/s9TCknZaxzDNHT/c0SQ
4UKQ0y1iZbMJeWlYeMqU3o1NwGnvJ7PEeVo+Cpst0A6accbStYpiXuhuuaFGcpFl
ZJWMlMpr5GSK9uxrxwa82M69hukW4eVP4o7rZARN0o5/ilNLmy3r/vJkvFPNX5us
80t7Euud8VkyVJU=
-----END CERTIFICATE-----
```
**Trac**:
**Username**: mmcloughlinTor: 0.3.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21437issue a warning log message when an exit uses Google DNS servers in /etc/reso...2020-06-27T13:57:13Zcypherpunksissue a warning log message when an exit uses Google DNS servers in /etc/resolv.conf or via ServerDNSResolvConfFileIn an attempt to make tor exit operators more aware of this problem [1] (phw's et. all research), issue a warning log level message when tor exits use Google DNS servers.
[1] https://nymity.ch/tor-dns/In an attempt to make tor exit operators more aware of this problem [1] (phw's et. all research), issue a warning log level message when tor exits use Google DNS servers.
[1] https://nymity.ch/tor-dns/