Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-10-15T16:30:29Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5304Obfsproxy should respect OutboundBindAddress in torrc2020-10-15T16:30:29ZTracObfsproxy should respect OutboundBindAddress in torrcRather it just binds to * (any IP).
Tested with latest git obfsproxy and Tor 0.2.3.12-alpha.
**Trac**:
**Username**: korobkovRather it just binds to * (any IP).
Tested with latest git obfsproxy and Tor 0.2.3.12-alpha.
**Trac**:
**Username**: korobkovTor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40106Tor client could not re-connect to a bridge which removed its obfs4 feature2021-04-13T12:35:47ZtoralfTor client could not re-connect to a bridge which removed its obfs4 featureI removed from a bridge (hashed fp: 662D4E4DE2C883625C543DFA3C4EE466899E6C85) the obfs4 feature and restarted the bridge.
When I restarted now the Tor client configured as:
```
UpdateBridgesFromAuthority 1
UseBridges 1
#ClientTransportPl...I removed from a bridge (hashed fp: 662D4E4DE2C883625C543DFA3C4EE466899E6C85) the obfs4 feature and restarted the bridge.
When I restarted now the Tor client configured as:
```
UpdateBridgesFromAuthority 1
UseBridges 1
#ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy
Bridge <snip>:<snip> <snip>
```
I got
```
Aug 15 17:39:23.000 [notice] Bootstrapped 0% (starting): Starting
Aug 15 17:39:23.000 [notice] Starting with guard context "bridges"
Aug 15 17:39:23.000 [notice] Delaying directory fetches: No running bridges
```
and the Tor client did not connect to the bridge. I stopped the Tor client, changed this line
```
UpdateBridgesFromAuthority 0
```
and now the Tor client could after a restart connect to the bridge.
After that I could revert that change and now every restart of the Tor client works flawlessly.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25528When ClientTransportPlugin is missing, tor connects directly to bridge addres...2022-09-05T17:50:35ZDavid Fifielddcf@torproject.orgWhen ClientTransportPlugin is missing, tor connects directly to bridge addresses, even if they have a transport nameStart `tcpdump -n host 83.212.101.3`
Run tor with this torrc:
```
UseBridges 1
Bridge obfs4 83.212.101.3:50002 A09D536DD1752D542E1FBB3C9CE4449D51298239 cert=lPRQ/MXdD1t5SRZ9MquYQNT9m5DV757jtdXdlePmRCudUU9CFUOX1Tm7/meFSyPOsud7Cw iat-mode...Start `tcpdump -n host 83.212.101.3`
Run tor with this torrc:
```
UseBridges 1
Bridge obfs4 83.212.101.3:50002 A09D536DD1752D542E1FBB3C9CE4449D51298239 cert=lPRQ/MXdD1t5SRZ9MquYQNT9m5DV757jtdXdlePmRCudUU9CFUOX1Tm7/meFSyPOsud7Cw iat-mode=0
```
See a connection to 83.212.101.3:50002, despite that, lacking a `ClientTransportPlugin` line, tor doesn't know how to connect to an "obfs4" bridge.
Another way to see it is with this torrc, using a phony address like meek and snowflake do:
```
UseBridges 1
Bridge dummy 0.0.3.0:1
```
tor actually tries to connect to the 0.0.3.0:1 address, and fails with an "Invalid argument" error:
```
[warn] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Invalid argument; RESOURCELIMIT; count 1; recommendation warn; host 0000000000000000000000000000000000000000 at 0.0.3.0:1)
```
I expected instead that tor would not try to connect to the address, but rather would show [this error message](https://gitweb.torproject.org/tor.git/tree/src/or/connection_or.c?h=tor-0.3.2.10#n1231):
> We were supposed to connect to bridge 'X' using pluggable transport 'Y', but we can't find a pluggable transport proxy supporting 'Y'. This can happen if you haven't provided a ClientTransportPlugin line, or if your pluggable transport proxy stopped running.
The problem exists in both 0.2.9.14 and 0.3.4.0-alpha-dev, which are the two versions I tested.
I found this problem through a user report at legacy/trac#25527. The user was trying to run the Tor Browser tor, but they were in the wrong directory, so they were only getting torrc and not torrc-defaults. torrc contains `UseBridges` and `Bridge`, but torrc-defaults contains `ClientTransportPlugin`.
There was another ticket about tor occasionally connecting to PT bridges as if they were ordinary guards: legacy/trac#20532. It may be the same as this. At legacy/trac#25527 I speculated that the problem might have been caused by cached `Guard` entries, but that doesn't seem to be the case. All you have to do is omit the `ClientTransportPlugin` line.Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33747If the ExtORPort doesn't report an external IP address, Tor won't apply rate ...2020-10-15T16:30:29ZRoger DingledineIf the ExtORPort doesn't report an external IP address, Tor won't apply rate limiting or account for bandwidth on that connectionIn the early days of Tor pluggable transports, on the server side you would run the bridge and the server component of the pluggable transport next to each other, and from Tor's perspective the connection would come in from 127.0.0.1 (i....In the early days of Tor pluggable transports, on the server side you would run the bridge and the server component of the pluggable transport next to each other, and from Tor's perspective the connection would come in from 127.0.0.1 (i.e. "from the obfs4 server sitting next to the bridge"). And because Tor doesn't apply rate limiting to connections from localhost, it wouldn't rate limit connections coming in via the pluggable transport, and also it wouldn't count bytes to/from that connection in its extrainfo counts or in its BW controller events.
We improved the situation by inventing the "ExtORPort", or "Extended ORPort", which has a quick handshake at the front that specifies e.g. what address the connection is "really" from, and then Tor treats the or_connection_t as though it came directly from that external address. So far so good.
But if the ExtORPort handshake doesn't specify an address, then Tor defaults to 127.0.0.1 (or wherever the server-side of the PT actually is), meaning it resumes having the "no rate limit, no bandwidth accounting" original behavior. That's no good, and we've hit this bug in practice because of a Snowflake bug (legacy/trac#33157).
I propose three fixes:
(A) In our documentation for setting up bridges, make it clear that setting an ExtORPort to go with your server-side PT is not just for user count statistics, but it is needed if you want rate limiting and proper bandwidth accounting and reporting.
(B) We could go farther here and tell server-side pluggable transports to demand an ExtORPort from Tor (i.e. refuse to start if you aren't given one). I think this is a good idea, but let me know if you see downsides.
(C) Do something smart with connections over the ExtORPort if they show up without a USERADDR command. I don't know of any concrete reasons why picking a dummy non-internal probably-not-routable address like 255.255.255.255 would break things, but also this is a fine opportunity to do something that doesn't leave future generations shaking their fist at us. For example: add a flag to connection_t called is_external_for_rate_limiting (or a catchier paint color name) where if it's 1 then yes it's external, and if it's 0 then you have to go check the address like before. And then eventually we'd transition more of Tor to use that flag, rather than recomputing whether to apply rate limiting many times over the course of a connection's lifetime.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32622Fix misleading STATUS_CLIENT warning message2020-10-15T16:30:29ZPhilipp Winterphw@torproject.orgFix misleading STATUS_CLIENT warning messageAfter Tor 0.4.3.0-alpha-dev successfully established a TCP connection with a bridge but failed to finish its handshake, it sends the following `STATUS_CLIENT` message to the controller:
```
650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=10 TA...After Tor 0.4.3.0-alpha-dev successfully established a TCP connection with a bridge but failed to finish its handshake, it sends the following `STATUS_CLIENT` message to the controller:
```
650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=10 TAG=handshake_dir SUMMARY="Finishing handshake with directory server" WARNING="DONE" REASON=DONE COUNT=1 RECOMMENDATION=warn HOSTID="0000000000000000000000000000000000000000" HOSTADDR="[scrubbed]"
```
One can reproduce this by using torproject.org's web server as a bridge: 95.216.163.36:80. The substring `WARNING="DONE"` is misleading and should – if I'm interpreting [control-spec.txt](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2682) correctly – contain a human-readable description of what went wrong. Other `STATUS_CLIENT` messages do a better job; for example:
```
650 STATUS_CLIENT WARN BOOTSTRAP PROGRESS=5 TAG=conn_dir SUMMARY="Connecting to directory server" WARNING="Connection refused" REASON=CONNECTREFUSED COUNT=1 RECOMMENDATION=warn HOSTID="0000000000000000000000000000000000000000" HOSTADDR="[scrubbed]"
```
Here, the substring `WARNING="Connection refused"` gives me a good idea of what's going on.
I suggest to fix the warning in this particular error case.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40430Modify default torrc text for PublishServerDescriptor2021-07-08T18:19:04ZCecylia BocovichModify default torrc text for PublishServerDescriptorIn the default torrc file, we see:
```
## By default, Tor will advertise your bridge to users through various
## mechanisms like https://bridges.torproject.org/. If you want to run
## a private bridge, for example because you'll give out...In the default torrc file, we see:
```
## By default, Tor will advertise your bridge to users through various
## mechanisms like https://bridges.torproject.org/. If you want to run
## a private bridge, for example because you'll give out your bridge
## address manually to your friends, uncomment this line:
#PublishServerDescriptor 0
```
However, we've noticed that some default Tor and Orbot bridges are not publishing their descriptors and therefore we aren't getting any metrics from them. This is exactly the use-case that `BridgeDistribution none` was meant to handle. In general, we recommend that people running private (or default) bridges that aren't meant for BridgeDB to configure their torrc file to have:
```
PublishServerDescriptor 1
BridgeDistribution none
```
See also the text in the torrc manpage for `PublishServerDescriptor`:
```
PublishServerDescriptor 0|1|v3|bridge,...
This option specifies which descriptors Tor will publish when acting as a relay. You
can choose multiple arguments, separated by commas.
If this option is set to 0, Tor will not publish its descriptors to any directories.
(This is useful if you’re testing out your server, or if you’re using a Tor controller
that handles directory publishing for you.) Otherwise, Tor will publish its descriptors
of all type(s) specified. The default is "1", which means "if running as a relay or
bridge, publish descriptors to the appropriate authorities". Other possibilities are
"v3", meaning "publish as if you’re a relay", and "bridge", meaning "publish as if
you’re a bridge".
```
I think we should change the default torrc text to match the manpage and say something to the effect of "if you want to, you can avoid publishing your descriptors, but we recommend that you do and that you set `BridgeDistribution none` if you don't want your bridge distributed over BridgeDB. That way we can collect metrics."Tor: 0.4.7.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40360tor stalls at 25% bootstrapped unless there is a fingerprint in the Bridge line2021-05-26T12:25:01ZCecylia Bocovichtor stalls at 25% bootstrapped unless there is a fingerprint in the Bridge lineAccording to the [tor man page](https://2019.www.torproject.org/docs/tor-manual.html.en), the `Bridge` option of the client's torrc file does not require a fingerprint:
```
If "fingerprint" is provided (using the same format as for
DirAu...According to the [tor man page](https://2019.www.torproject.org/docs/tor-manual.html.en), the `Bridge` option of the client's torrc file does not require a fingerprint:
```
If "fingerprint" is provided (using the same format as for
DirAuthority), we will verify that the relay running at that
location has the right fingerprint.
```
However, ever since the fixes for #40106 (I did a git bisect, but couldn't narrow down exactly which commit was the culprit due to other transport related bugs), my bootstrap stalls at 25% unless a fingerprint is provided (with an empty datadir it stalls at 70% weirdly). I have tested this with both Snowflake and Obfs4.
If there's a good security reason to require the fingerprint, we should update the manpage, and also make sure that we always distribute the fingerprint with bridge lines. I'd prefer not requiring the fingerprint since some transports like snowflake have the proxies, not the client, decide which bridge to connect to.Tor: 0.4.5.x-post-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40228Make it possible to disable dormant mode altogether2022-05-13T08:07:54ZPhilipp Winterphw@torproject.orgMake it possible to disable dormant mode altogetherThere is currently no configuration option to disable tor's dormant mode. One can prevent it indirectly by 1) occasionally sending traffic over the SOCKS port, 2) telling tor to set up an onion service, or by 3) sending tor a `SIGNAL ACT...There is currently no configuration option to disable tor's dormant mode. One can prevent it indirectly by 1) occasionally sending traffic over the SOCKS port, 2) telling tor to set up an onion service, or by 3) sending tor a `SIGNAL ACTIVE` (but that only wakes up tor when it's sent from a control port connection that was established _after_ tor went dormant).
In the context of bridgestrap, it would be convenient to simply disable dormant mode rather than deal with the above workarounds. Bridgestrap tests bridges by sending a `SETCONF [bridge]` to tor's control port; it never performs any client activity.
TL;DR: I'd like to have a configuration option that tells tor to never go dormant.Tor: 0.4.5.x-post-stableNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40554Non-fatal assertion !(desc_gen_reason == NULL) when rotate_onion_key fails2023-07-20T14:38:36ZDavid Fifielddcf@torproject.orgNon-fatal assertion !(desc_gen_reason == NULL) when rotate_onion_key failsContext:
https://lists.torproject.org/pipermail/tor-relays/2022-January/020277.html
https://forum.torproject.net/t/tor-relays-how-to-reduce-tor-cpu-load-on-a-single-bridge/1483/22
I prevented [`rotate_onion_key`](https://gitweb.torproje...Context:
https://lists.torproject.org/pipermail/tor-relays/2022-January/020277.html
https://forum.torproject.net/t/tor-relays-how-to-reduce-tor-cpu-load-on-a-single-bridge/1483/22
I prevented [`rotate_onion_key`](https://gitweb.torproject.org/tor.git/tree/src/feature/relay/router.c?h=tor-0.4.6.9#n486) from working by creating directories with the names "secret_onion_key.old" and "secret_onion_key_ntor.old". I set `LastRotatedOnionKey` in the state file to 6 weeks in the past to force an onion key rotation, then started tor.
On first being started, the log shows a failure to rotate the onion key, as expected:
```
Jan 28 23:46:59.000 [info] rotate_onion_key_callback(): Rotating onion key.
Jan 28 23:46:59.000 [warn] Couldn't rotate onion key.
Jan 28 23:46:59.000 [info] router_rebuild_descriptor(): Rebuilding relay descriptor (forced)
...
Jan 28 23:46:59.000 [info] check_onion_keys_expiry_time_callback(): Expiring old onion keys.
```
But one hour later, and every hour thereafter, there's a [`BUG` assertion failure](https://gitweb.torproject.org/tor.git/tree/src/feature/relay/router.c?h=tor-0.4.6.9#n2475) in `router_rebuild_descriptor`:
```
Jan 29 00:46:59.000 [info] router_rebuild_descriptor(): Rebuilding relay descriptor (forced)
Jan 29 00:46:59.000 [warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor address 172.105.3.197. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'.
Jan 29 00:46:59.000 [info] extrainfo_dump_to_string_stats_helper(): Adding stats to extra-info descriptor.
Jan 29 00:46:59.000 [info] read_file_to_str(): Could not open "/var/lib/tor-instances/rot1/stats/bridge-stats": No such file or directory
Jan 29 00:46:59.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/relay/router.c:2452: router_rebuild_descriptor: Non-fatal assertion !(desc_gen_reason == NULL) failed. (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: Tor 0.4.5.10: Non-fatal assertion !(desc_gen_reason == NULL) failed in router_rebuild_descriptor at ../src/feature/relay/router.c:2452. Stack trace: (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x57) [0x5638b9538047] (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0x16b) [0x5638b954327b] (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: /usr/bin/tor(router_rebuild_descriptor+0x13d) [0x5638b94f4e1d] (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: /usr/bin/tor(+0x21f163) [0x5638b9665163] (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: /usr/bin/tor(+0x83577) [0x5638b94c9577] (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.7(+0x239ef) [0x7f701bae49ef] (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.7(event_base_loop+0x52f) [0x7f701bae528f] (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x101) [0x5638b94b1321] (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1d5) [0x5638b94acdd5] (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: /usr/bin/tor(tor_main+0x49) [0x5638b94a92e9] (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x5638b94a8ec9] (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f701b391d0a] (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x5638b94a8f1a] (on Tor 0.4.5.10 )
Jan 29 00:46:59.000 [info] router_upload_dir_desc_to_dirservers(): Uploading relay descriptor to directory authorities
Jan 29 00:46:59.000 [info] directory_post_to_dirservers(): Uploading an extrainfo too (length 822)
Jan 29 00:46:59.000 [info] rep_hist_note_used_internal(): New port prediction added. Will continue predictive circ building for 3332 more seconds.
Jan 29 00:46:59.000 [info] connection_ap_make_link(): Making internal anonymized tunnel to [scrubbed]:9001 ...
Jan 29 00:46:59.000 [info] connection_ap_make_link(): ... application connection created and linked.
Jan 29 00:46:59.000 [info] check_onion_keys_expiry_time_callback(): Expiring old onion keys.
```
```Sponsor 61 - Making the Tor network faster & more reliable for users in Internet-repressive placesAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40406Remove distribution methods from BridgeDistribution option2021-09-20T09:50:36ZCecylia BocovichRemove distribution methods from BridgeDistribution optionFrom the tor manpage:
```
BridgeDistribution string
If set along with BridgeRelay, Tor will include a new line in its
bridge descriptor which indicates to the BridgeDB service how it
would like its...From the tor manpage:
```
BridgeDistribution string
If set along with BridgeRelay, Tor will include a new line in its
bridge descriptor which indicates to the BridgeDB service how it
would like its bridge address to be given out. Set it to "none" if
you want BridgeDB to avoid distributing your bridge address, or
"any" to let BridgeDB decide. (Default: any)
```
We currently allow bridge operators to choose which distribution method their bridge is handed out over. We're re-evaluating the usefulness of this option compared to the complexity required to implement it in our work on https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/12.
The addition of this config option was first proposed in https://gitlab.torproject.org/tpo/core/tor/-/issues/18329 for the purpose of distinguishing between bridges that were to be handed out by BridgeDB and bridges that wished not to be handed out by BridgeDB so that we could still collect metrics from its bridge descriptor. The use case then got expanded to allow operators choice of any existing distribution method, but it's not clear to me why a bridge operator would want a choice beyond the original "do or do not distribute my bridge for me". Or perhaps more relevant: how this choice would help the Tor network. The main reason I can think of is experiments or testing purposes for researchers to measure enumeration by spinning up a bridge for a specific distribution method.
I'm happy to implement this feature if we decide we have good reasons for it. However, removing it would simplify our implementation of rdsys.Sponsor 30 - Objective 2.3Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40209Make it possible to forget bridge descriptors before SETCONF2022-05-20T19:11:30ZPhilipp Winterphw@torproject.orgMake it possible to forget bridge descriptors before SETCONFThe anti-censorship team maintains [bridgestrap](https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap) which does bridge testing for us. Bridgestrap tests bridges by `SETCONF`ing them using tor's control port. Tor's caching gets...The anti-censorship team maintains [bridgestrap](https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap) which does bridge testing for us. Bridgestrap tests bridges by `SETCONF`ing them using tor's control port. Tor's caching gets in the way here, so to repeatedly test bridges, it's helpful for tor to be able to forget bridge descriptors. @arma wrote a patch for that [in this comment](https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/2#note_2710591). It would be convenient for us to have that functionality directly in tor, so I wonder if it would be sensible to merge Roger's patch and expose it via a config option?Sponsor 30 - Objective 2.3Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33669"Pluggable Transport process terminated" but Tor keeps on going (and of cours...2023-05-30T18:39:08ZRoger Dingledine"Pluggable Transport process terminated" but Tor keeps on going (and of course doesn't work)In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
...In https://trac.torproject.org/projects/tor/ticket/33336#comment:20 I encountered the unfortunate situation where my snowflake client exited:
```
Feb 25 14:36:24.458 [warn] Pluggable Transport process terminated with status code 512
```
It still remains unclear whether snowflake had a bug that crashed it, or if Tor has a bug that made it close the socket to snowflake.
But either way, after this event Tor quietly cries to itself:
```
Feb 25 14:36:44.825 [warn] The connection to the SOCKS5 proxy server at 127.0.0.1:45527 just failed. Make sure that the proxy server is up and running.
```
and Tor Browser has no idea this is happening, or that trying to use Tor is now hopeless.
We should figure out something smarter that Tor should do in this situation. Perhaps it should exit, forcing the user to notice? Perhaps it should emit an event that Tor Browser picks up on? Maybe we have an even better idea?Tor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.org2023-05-31https://gitlab.torproject.org/tpo/core/tor/-/issues/40885dual stack bridges only publish an IPv4 bridge line2023-11-16T14:20:15Zdzwdzdual stack bridges only publish an IPv4 bridge lineBridges currently only publish one bridge line per transport, and, if they have both an IPv4 and v6 address available, they always prefer IPv4, leaving the IPv6 address unused.
https://gitlab.torproject.org/tpo/core/tor/-/blob/cec6f9919...Bridges currently only publish one bridge line per transport, and, if they have both an IPv4 and v6 address available, they always prefer IPv4, leaving the IPv6 address unused.
https://gitlab.torproject.org/tpo/core/tor/-/blob/cec6f9919d3128646d85c75d08338bea4b31bffa/src/feature/client/transports.c#L1724-1732
@arma checked the extra-info descriptor of one of my (dual stack) bridges and confirmed it only used its IPv4 address in the transport line. I don't see any IPv6 users either, but that's just anecdotal evidence. I think this has the potential to add a lot of new bridge address to the pool, which would be pretty neat from an anti-censorship perspective.
Right now I'll try to patch a bridge of mine to publish two transport lines in extra-info, one per IP version, and see if that breaks anything. If it doesn't, I can submit a MR after !782 gets merged (it affects the same area of the code).https://gitlab.torproject.org/tpo/core/tor/-/issues/40871Tor incorrectly stores stats on incoming PT connections2023-12-10T21:38:18ZAlexander Færøyahf@torproject.orgTor incorrectly stores stats on incoming PT connections@trinity-1686a and @dcf discussed this issue on tor-dev@ in https://lists.torproject.org/pipermail/tor-dev/2023-October/014858.html
It seems like we have a bug after we updated our connectiong tracking code to track incoming connections...@trinity-1686a and @dcf discussed this issue on tor-dev@ in https://lists.torproject.org/pipermail/tor-dev/2023-October/014858.html
It seems like we have a bug after we updated our connectiong tracking code to track incoming connections earlier. We don't handle the transport name parameter of our eager call to `geoip_note_client_seen()`.
@trinity-1686a may potentially have a patch for this. I think it would be good if we could get some testing on this before we merge it.
Would you be up for running your Tor instance with a patch that potentially fixes this issue, @dcf ?Tor: 0.4.8.x-post-stabletrinity-1686atrinity-1686ahttps://gitlab.torproject.org/tpo/core/tor/-/issues/40584Feature request: do not include the Bridge line into the server descriptor f...2022-08-24T14:42:21ZtoralfFeature request: do not include the Bridge line into the server descriptor for private bridgesWhilst I like the info and the graphs at metrics.t.o, I do not want to share the secret of a private bridge with anybody.
This would allow me to replace "0" with "bridge".Whilst I like the info and the graphs at metrics.t.o, I do not want to share the secret of a private bridge with anybody.
This would allow me to replace "0" with "bridge".https://gitlab.torproject.org/tpo/core/tor/-/issues/40578Let bridge users choose to only reach their first working bridge2024-02-28T17:55:43ZRoger DingledineLet bridge users choose to only reach their first working bridgeWe have some users in Russia who collect dozens or hundreds of obfs4 bridges, and when they start their Tor, it bursts out dozens/hundreds of connections at once to try to reach every single bridge and see which ones are working. That is...We have some users in Russia who collect dozens or hundreds of obfs4 bridges, and when they start their Tor, it bursts out dozens/hundreds of connections at once to try to reach every single bridge and see which ones are working. That is loud, wasteful, and maybe even dangerous.
In Snowflake (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28651) we are heading toward a world where Tor Browser users have k snowflake bridge lines, one per destination bridge, in order to scale up and improve resiliency. But the Snowflake people worry that doing more than one-ish Snowflake connection will be wasteful (since each connection involves a domain front, a stun connection, a webrtc handshake, etc) and also it will stand out on the network. So they are considering having Tor Browser choose just one Snowflake line at random for each user, which helps with the scaling but it discards all the resiliency features that we would be so close to getting.
I think the answer in both these cases is that we want an option in Tor that makes you only try to fetch bridge descriptors from the bridges you actually hope to use.
I expect the main two parts of this change will be:
* When considering launching a bridge descriptor fetch, decide if you would call this bridge one of your primary guards if it worked, and if not, don't fetch.
* As soon as any bridge fails, immediately go through and see if you need to launch any new descriptor fetches (because otherwise you could end up in a situation where your existing bridges failed and you aren't trying any new ones yet).
(I do think we want to retain the existing "try them all" behavior as an option too (maybe even the default? that's a decision we should make), first for the people who use bridges for connectivity because it gives you the best connectivity, and second because we use the "try them all" functionality in e.g. bridgestrap.)Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/40517Bring sanity to the tor side of the PT shutdown process.2022-06-17T19:08:29ZYawning AngelBring sanity to the tor side of the PT shutdown process.This is the final phase of my great PT shutdown process cleanup as a follow up to legacy/trac#15545.
Now that there's a portable mechanism to signal termination to PTs (close the stdin), we should change the PT shutdown process to allow...This is the final phase of my great PT shutdown process cleanup as a follow up to legacy/trac#15545.
Now that there's a portable mechanism to signal termination to PTs (close the stdin), we should change the PT shutdown process to allow graceful termination to look like this:
1. Close stdin (and on U*IX, send a SIGTERM, PT behavior here is equivalent).
2. Wait for a grace period (~1 sec?)
3. If the child still is not dead, send a SIGKILL/TerminateProcess(). (Failsafe)
This fixes legacy/trac#9330 in that, PTs that wish to trap a graceful shutdown on Windows have a way to do so, despite the final stage of the process killing the PT in the most violent way possible as a failsafe (realistically, PTs should exit shortly after step 1).https://gitlab.torproject.org/tpo/core/tor/-/issues/40440Bridges doesn't work with ExcludeNodes2022-06-22T15:25:40ZTracBridges doesn't work with ExcludeNodesBridges doesn't work with ExcludeNodes. I used all bridges that aren't in countries mentioned in Exclude, but it also isn't working.
My torrc:
```
ExcludeNodes {RU},{BY},{US},{DE},{UA}
ExitNodes {SE},{NL},{FI}
bridge obfs4 94.242.249.2:...Bridges doesn't work with ExcludeNodes. I used all bridges that aren't in countries mentioned in Exclude, but it also isn't working.
My torrc:
```
ExcludeNodes {RU},{BY},{US},{DE},{UA}
ExitNodes {SE},{NL},{FI}
bridge obfs4 94.242.249.2:38479 039C0803213355DCC9961876B5650B0BE5691915 cert=8+QodvOgR4ufCz/82xjEE/wQIV0qBPgKIXIEQFohS0J+BNA+m8l+cZyh2TxZhDgZOHTiAw iat-mode=0
```
**Trac**:
**Username**: dECENTRALhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40438PT spec: should 255 bytes be sent in the RFC 1929 UNAME field?2022-06-17T17:52:51ZMark SmithPT spec: should 255 bytes be sent in the RFC 1929 UNAME field?Section 3.5 of the PT spec says:
If the encoded argument list is less than 255 bytes in
length, the "PLEN" field must be set to "1" and the "PASSWD"
field must contain a single NUL character.
When Kathy Brade and I implemented legacy...Section 3.5 of the PT spec says:
If the encoded argument list is less than 255 bytes in
length, the "PLEN" field must be set to "1" and the "PASSWD"
field must contain a single NUL character.
When Kathy Brade and I implemented legacy/trac#29627, we viewed the above as a spec bug and allowed up to 255 bytes to be sent in the RFC 1929 UNAME field. Was that the wrong thing to do? Or should the PT spec be changed to read "If the encoded argument list is less than or equal to 255 bytes in length..."?https://gitlab.torproject.org/tpo/core/tor/-/issues/40311"ServerTransportListenAddr obfs4 0.0.0.0:7002" becomes "TransportProxy obfs4 ...2021-02-24T12:14:48ZRoger Dingledine"ServerTransportListenAddr obfs4 0.0.0.0:7002" becomes "TransportProxy obfs4 [::]:7002" in the state fileWe have a bridge operator on #tor (@JFCaringi) who has set
```
ServerTransportListenAddr obfs4 0.0.0.0:7002
```
in their torrc file, yet obfs4proxy binds to 7002 ipv6 and not to 7002 ipv4.
After some debugging, it turns out their state ...We have a bridge operator on #tor (@JFCaringi) who has set
```
ServerTransportListenAddr obfs4 0.0.0.0:7002
```
in their torrc file, yet obfs4proxy binds to 7002 ipv6 and not to 7002 ipv4.
After some debugging, it turns out their state file says
```
TransportProxy obfs4 [::]:7002
```
!
So my first question had been "is it Tor that is sending the wrong thing to obfs4proxy, or is obfs4proxy doing the wrong thing on its own", and based on that line in the state file, my guess is it it Tor doing the wrong thing.
It looks like something changed in things like INADDR_ANY in a surprising way?
This same issue was also reported on reddit at
https://www.reddit.com/r/TOR/comments/dh9wky/unable_to_force_obfs4proxy_to_listen_on_ipv4/
and it appeared to have no resolution there.