The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:40:34Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28727Remove `broker` and `relay` query string parameters from Snowflake proxy2020-06-27T13:40:34ZDavid Fifielddcf@torproject.orgRemove `broker` and `relay` query string parameters from Snowflake proxyThe browser proxy allows overriding the default [broker](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/proxy/snowflake.coffee?id=596d28b57628dc57dd44080bb50b435c27c48861#n241) and [relay](https://gitweb.torproject...The browser proxy allows overriding the default [broker](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/proxy/snowflake.coffee?id=596d28b57628dc57dd44080bb50b435c27c48861#n241) and [relay](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/proxy/snowflake.coffee?id=596d28b57628dc57dd44080bb50b435c27c48861#n254) using query string parameters. This is a security vulnerability because it can turn browser proxies into a DoS vector against some third party. An attacker only has to get a massive number of browsers to visit a URL like !https://snowflake.example/embed.html?broker=https://victim.example and those browsers will start sending HTTPS requests to victim.example.
This same vulnerability existed in flash proxy; here are the commits removing the feature there:
* [Remove "facilitator" query string parameter.](https://gitweb.torproject.org/flashproxy.git/commit/?id=a6af0da52a1c534799e563beba047ef02cc0a9e8)
* [Remove "client" and "relay" query string parameters.](https://gitweb.torproject.org/flashproxy.git/commit/?id=d518f2615d977475dabaf4a46fbbe83c5a52801c)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/26348Guard against large reads2020-06-27T13:40:36ZDavid Fifielddcf@torproject.orgGuard against large readsSnowflake code calls ioutil.ReadAll from a socket/HTTP in many places in the code: [1](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/broker/broker.go?id=25b304a9a856f8c791882ad523df26ffc8fa629c#n123) [2](https://g...Snowflake code calls ioutil.ReadAll from a socket/HTTP in many places in the code: [1](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/broker/broker.go?id=25b304a9a856f8c791882ad523df26ffc8fa629c#n123) [2](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/broker/broker.go?id=25b304a9a856f8c791882ad523df26ffc8fa629c#n153) [3](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/broker/broker.go?id=25b304a9a856f8c791882ad523df26ffc8fa629c#n200) [4](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/rendezvous.go?id=25b304a9a856f8c791882ad523df26ffc8fa629c#n100) [5](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/proxy-go/snowflake.go?id=25b304a9a856f8c791882ad523df26ffc8fa629c#n160).
These should all get an [io.LimitReader](https://golang.org/pkg/io/#LimitReader) or [http.MaxBytesReader](https://golang.org/pkg/net/http/#MaxBytesReader) with a limit of 100 KB or so. Like [this one](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/server-webrtc/http.go?id=25b304a9a856f8c791882ad523df26ffc8fa629c#n40):
```
body, err := ioutil.ReadAll(http.MaxBytesReader(w, req.Body, 100000))
if err != nil {
http.Error(w, "Bad request.", http.StatusBadRequest)
return
}
```Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25472snowflake-client's `-url` option is intolerant of a missing path2020-06-27T13:40:39ZDavid Fifielddcf@torproject.orgsnowflake-client's `-url` option is intolerant of a missing pathI was following [server-webrtc's README](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/server-webrtc/README.md?id=ff8f3851082e8f7f8b4c8b99b161be35020aeb67) and I made a small mistake in the client torrc. Instead o...I was following [server-webrtc's README](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/server-webrtc/README.md?id=ff8f3851082e8f7f8b4c8b99b161be35020aeb67) and I made a small mistake in the client torrc. Instead of
```
-url http://127.0.0.1:8080/
```
I had (no trailing slash):
```
-url http://127.0.0.1:8080
```
This caused the client to fail with this error:
```
2018/03/13 03:10:40 Negotiating via BrokerChannel...
Target URL:
Front URL: 127.0.0.1:8080
2018/03/13 03:10:40 BrokerChannel Error: dial tcp: unknown port tcp/8080client
2018/03/13 03:10:40 Failed to retrieve answer. Retrying in 10 seconds
```
This is because the URL to request is built using string concatenation. It built the string `"http://127.0.0.1:8080client"` instead of `"http://127.0.0.1:8080/client"`.
https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/rendezvous.go?id=ff8f3851082e8f7f8b4c8b99b161be35020aeb67#n83
```
request, err := http.NewRequest("POST", bc.url.String()+"client", data)
```https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/24954Metrics performance measurements use v2 onion services2020-06-27T14:25:59ZteorMetrics performance measurements use v2 onion servicesI missed these when we did the original v2/v3 onion service update:
https://metrics.torproject.org/torperf.html
https://metrics.torproject.org/torperf-failures.html
They should both say "v2 onion" in their description, or maybe the data...I missed these when we did the original v2/v3 onion service update:
https://metrics.torproject.org/torperf.html
https://metrics.torproject.org/torperf-failures.html
They should both say "v2 onion" in their description, or maybe the data selection label.Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/17786"France, Metropolitan" is unused?2020-06-27T14:26:13ZRoger Dingledine"France, Metropolitan" is unused?In the "direct user stats" graph, in the pull-down menu for countries, one of thes options is "France, Metropolitan". I don't know what that is, but I think Tor doesn't either, since metrics can't graph it.
(Are there any other entries ...In the "direct user stats" graph, in the pull-down menu for countries, one of thes options is "France, Metropolitan". I don't know what that is, but I think Tor doesn't either, since metrics can't graph it.
(Are there any other entries in that list that don't correspond to cctlds?)Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/28888The Relay Search Results table doesn't show the IPv6 capability of a bridge2022-02-09T12:12:19ZtoralfThe Relay Search Results table doesn't show the IPv6 capability of a bridgeThe ORPort is reachable (tested from another IPv6 system in a different network segment), the torrc looks like:
```
# torrc
#
SocksPort 0
ORPort auto
ORPort [<snip>]:auto
BridgeRelay 1
Exitpolicy reject *:*
RunAsDaemon 1
ControlPort 9...The ORPort is reachable (tested from another IPv6 system in a different network segment), the torrc looks like:
```
# torrc
#
SocksPort 0
ORPort auto
ORPort [<snip>]:auto
BridgeRelay 1
Exitpolicy reject *:*
RunAsDaemon 1
ControlPort 9051
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ContactInfo replace k with c : kontakt @ zwiebeltoralf . de
Nickname zwiebeltoralf3
Log warn file /var/log/tor/warn.log
# for arm
#
DisableDebuggerAttachment 0
```
The metrics link is: https://metrics.torproject.org/rs.html#details/662D4E4DE2C883625C543DFA3C4EE466899E6C85https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/15178Improve Atlas' error messages2020-06-27T14:25:21ZPhilipp Winterphw@torproject.orgImprove Atlas' error messagesWhenever Onionoo is offline, Atlas shows an error message:
> Backend error!
> The backend server replied with an error to your query. This probably means that you did not properly format your query. If your query was properly formatted ...Whenever Onionoo is offline, Atlas shows an error message:
> Backend error!
> The backend server replied with an error to your query. This probably means that you did not properly format your query. If your query was properly formatted it may mean that there is an issue with your browser/add-ons. Please report which browser/addons/etc. you're using to the bug tracker.
This suggests that the user made a mistake, which results in several trac tickets every time Onionoo is offline. We should improve the error message and make it clear that waiting a little bit might solve the problem. Here's a suggestion:
> Backend error!
> Atlas is unable to get a response from its backend server. This probably means that the backend server is unavailable right now. This can also happen, however, if you did not format your query correctly. Please have a look at [this page](https://atlas.torproject.org/#about) that explains what type of search queries are supported by Atlas.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/11348Add new graphs on average users per bridge and fractional uptime per relay/br...2020-06-27T14:25:25ZKarsten LoesingAdd new graphs on average users per bridge and fractional uptime per relay/bridge to AtlasOnionoo has two new document types:
- https://onionoo.torproject.org/#clients
- https://onionoo.torproject.org/#uptime
These documents contain graph data that can be displayed by Atlas in the same way as bandwidth and weights data ar...Onionoo has two new document types:
- https://onionoo.torproject.org/#clients
- https://onionoo.torproject.org/#uptime
These documents contain graph data that can be displayed by Atlas in the same way as bandwidth and weights data are displayed. Want to add graphs for them?Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/9231Add consensus weight to relay info2020-06-27T14:25:28ZTracAdd consensus weight to relay info$subj
**Trac**:
**Username**: hsn$subj
**Trac**:
**Username**: hsnArturo FilastòArturo Filastòhttps://gitlab.torproject.org/tpo/community/l10n/-/issues/28432German translation of 'circuit' should be made consistent on the landing page2020-06-27T13:45:03ZwaywardGerman translation of 'circuit' should be made consistent on the landing pageUser pointed out below that the German localization of 'circuit' is inconsistent in various places:
https://blog.torproject.org/comment/277954#comment-277954
"In the German version of TBB, on the introductory page, there are three diff...User pointed out below that the German localization of 'circuit' is inconsistent in various places:
https://blog.torproject.org/comment/277954#comment-277954
"In the German version of TBB, on the introductory page, there are three different translations for the English 'circuit'. There is: 1. Circuit-Ansicht (which is no translation!). 2. In the explanatory text there is 'Zeige deinen Pfad' - here 'circuit' becomes 'Pfad' (= 'path') and users are told to 'choose'( = 'wählen', which should be "click on" = 'klicken auf' - not 'choose') 'Neuer Pfad für diese Seite'. 3. If you do so and click on the "Informations-Symbol" which is the padlock, you will not get 'Neuer Pfad für diese Seite', but 'Neuen Kanal für diese Seite'. (By the way: this should be: 'NeueR Pfad' (nominative) instead of 'NeueN Pfad' (accusative) - but this is only a minor mistake.)
So you have three names for the English word 'circuit': 1. circuit, 2. Pfad, 3. Kanal
On the right, at the bottom of the introduction. you will read 'Pfad' again. If you click on that field, you will get to Duck Duck Go and you will read 'Circuits' again, and:'Relays'. In the old version of TBB you used 'Relais' as translation for 'relay'. And if you click on the green padlock, 'relay' is translated as 'Verteiler'."
We should pick which word works best and change these strings to match where appropriate.emmapeelemmapeelhttps://gitlab.torproject.org/tpo/network-health/metrics/tor-check/-/issues/9631Check.torproject.org message is ambiguous to rational non-technical user.2020-06-27T14:26:41ZTracCheck.torproject.org message is ambiguous to rational non-technical user.Showing an intelligent but non-technical user how to use Tor recently, I decided to direct them to the TorProject.org page and watch over their shoulder as they worked their way through it. Upon encountering the 'check.torproject.org' me...Showing an intelligent but non-technical user how to use Tor recently, I decided to direct them to the TorProject.org page and watch over their shoulder as they worked their way through it. Upon encountering the 'check.torproject.org' message "Congratulations, Your browser is configured to use Tor!" they then used the existing Safari browser they had open.
Fix: Change check.torproject.org message to "Congratulations, This browser is configured to use Tor!"
**Trac**:
**Username**: mpartehttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/22068Make it explicit that Torsocks won't work correctly in certain scenarios in t...2020-06-27T14:12:04ZTracMake it explicit that Torsocks won't work correctly in certain scenarios in the READMEAs far as I understand, Torsocks works by setting LD_PRELOAD, so an application that doesn't uses libc, and instead uses syscalls directly will be able to bypass torsocks and connect directly to the Internet.
I think a warning about it ...As far as I understand, Torsocks works by setting LD_PRELOAD, so an application that doesn't uses libc, and instead uses syscalls directly will be able to bypass torsocks and connect directly to the Internet.
I think a warning about it on the README file, and MAN page is needed, besides making it explicit that using Torsocks is not 100% safe as the README might make you think, for example:
> _Torsocks allows you to use most applications in a safe way with Tor. It ensures that DNS requests are handled safely and explicitly rejects any traffic other than TCP from the application you're using._
> Torsocks is an ELF shared library that is loaded before all others. The library overrides every needed Internet communication libc function calls such as connect(2) or gethostbyname(3).
> _This process is transparent to the user and if torsocks detects any communication that can't go through the Tor network such as UDP traffic, for instance, the connection is denied. If, for any reason, there is no way for torsocks to provide the Tor anonymity guarantee to your application, torsocks will force the application to quit and stop everything._
**Trac**:
**Username**: FranciscouzoDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/17760Torsocks doesn't quote variables, will choke on spaces and special characters...2020-06-27T14:12:06ZteorTorsocks doesn't quote variables, will choke on spaces and special characters in pathsThe script that launches a command using torsocks checks a lot of paths without quoting them.
This means that paths with spaces will cause errors, and paths with special characters may have unintended effects.The script that launches a command using torsocks checks a lot of paths without quoting them.
This means that paths with spaces will cause errors, and paths with special characters may have unintended effects.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/torsocks/-/issues/14268torsocks "make check" target broken in out of tree builds2020-06-27T14:12:10ZYawning Angeltorsocks "make check" target broken in out of tree buildsShould be obvious from the summary, but this fails, when it shouldn't:
```
$ sh autogen.sh
$ mkdir build
$ cd build
$ ../configure; make; make check
```
The failures happen because the build system assumes that the following files are p...Should be obvious from the summary, but this fails, when it shouldn't:
```
$ sh autogen.sh
$ mkdir build
$ cd build
$ ../configure; make; make check
```
The failures happen because the build system assumes that the following files are present under the location that make was run from:
* tests/run.sh
* tests/test_list
* tests/unit/fixtures
Copying the files manually to the right places under "build" fixes things, so this should be easy to fix.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33742Add information about design paper and anonbib inside README.1st2021-06-23T11:55:13ZGhost UserAdd information about design paper and anonbib inside README.1stAs mentioned under legacy/trac#33688 (comment 9) some old "TODO" items were removed from `doc/HACKING/README.1st.md` file.
Link and description should be added for:
- design paper,
- anonbib.As mentioned under legacy/trac#33688 (comment 9) some old "TODO" items were removed from `doc/HACKING/README.1st.md` file.
Link and description should be added for:
- design paper,
- anonbib.https://gitlab.torproject.org/tpo/core/tor/-/issues/33670Fix erroneous spaces in circuitmux_ewma.c2020-06-27T13:48:01ZNeel Chauhanneel@neelc.orgFix erroneous spaces in circuitmux_ewma.cNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33632List ed25519 fingerprints on the command line2021-04-18T13:55:23ZteorList ed25519 fingerprints on the command lineFor RSA keys, tor has `tor --list-fingerprint`.
We could add a feature to tor so it accepts a key type argument:
* `tor --list-fingerprint rsa`
* `tor --list-fingerprint ed25519`
And defaults to RSA (for now).
Related to legacy/trac#30...For RSA keys, tor has `tor --list-fingerprint`.
We could add a feature to tor so it accepts a key type argument:
* `tor --list-fingerprint rsa`
* `tor --list-fingerprint ed25519`
And defaults to RSA (for now).
Related to legacy/trac#30642, which adds an `ed25519-fingerprint` file.https://gitlab.torproject.org/tpo/core/tor/-/issues/33371Build only with required libevent2 libraries2023-09-15T11:40:49ZNick MathewsonBuild only with required libevent2 librariesWe should only need libevent_core and libevent_extra.We should only need libevent_core and libevent_extra.https://gitlab.torproject.org/tpo/core/tor/-/issues/33188Tor Manual: Alphabetize Server and Directory Server Options2021-07-22T16:18:20ZTracTor Manual: Alphabetize Server and Directory Server OptionsAlphabetize options in the Server Options and Directory Server Options
**Trac**:
**Username**: swatiAlphabetize options in the Server Options and Directory Server Options
**Trac**:
**Username**: swatihttps://gitlab.torproject.org/tpo/core/tor/-/issues/33124Controller circuits don't pass the SOCKS request address in relay begin cells2021-07-09T17:22:51ZoparaController circuits don't pass the SOCKS request address in relay begin cellsIf a stream is attached to a circuit with purpose `CIRCUIT_PURPOSE_CONTROLLER`, a RELAY_BEGIN cell will be sent with an empty address. This is because of a bug in `connection_ap_handshake_send_begin()`.
```
tor_snprintf(payload,RELAY_PA...If a stream is attached to a circuit with purpose `CIRCUIT_PURPOSE_CONTROLLER`, a RELAY_BEGIN cell will be sent with an empty address. This is because of a bug in `connection_ap_handshake_send_begin()`.
```
tor_snprintf(payload,RELAY_PAYLOAD_SIZE, "%s:%d",
(circ->base_.purpose == CIRCUIT_PURPOSE_C_GENERAL) ?
ap_conn->socks_request->address : "",
ap_conn->socks_request->port);
```
The function seems to assume that if it's not a general purpose circuit, then it is a rendezvous circuit. This was added in [commit 5b6099e8](https://github.com/torproject/tor/commit/5b6099e8#diff-0798d3d17392dc5c15f3f58a5fc6b29aR946-R957).
There is a similar error in a logging statement in `link_apconn_to_circ()` which logs that a controller circuit is to a "hidden service", even if the circuit is actually to an exit.
```
log_info(LD_APP, "Looks like completed circuit to %s %s allow "
"optimistic data for connection to %s",
circ->base_.purpose == CIRCUIT_PURPOSE_C_GENERAL ?
/* node_describe() does the right thing if exitnode is NULL */
safe_str_client(node_describe(exitnode)) :
"hidden service",
apconn->may_use_optimistic_data ? "does" : "doesn't",
safe_str_client(apconn->socks_request->address));
```
And another example is in `connection_ap_expire_beginning()` which logs the warning:
```
[warn] connection_ap_expire_beginning(): Bug: circuit->purpose == CIRCUIT_PURPOSE_C_GENERAL failed. The purpose on the circuit was Circuit made by controller; it was in state open, path_state new. (on Tor 0.4.2.5 )
```
The relay which receives the RELAY_BEGIN cell will then make a dns request for the address "". Libevent will eventually give up after 3 tries (`global_timeout.tv_sec = 5` seconds per try).
```
Feb 01 01:11:41.369 [info] launch_resolve(): Launching eventdns request for ""
Feb 01 01:11:41.369 [info] evdns_log_cb(): eventdns: Resolve requested.
...
Feb 01 01:11:56.378 [info] eventdns: Giving up on request 0x5565c825ac80; tx_count==3
```
Back at the tor client, the streams detach (reason=timeout, remote_reason=none) after some time, then the controller circuits close a few seconds later (a total of 25 seconds after the streams were first attached) with:
```
[info] circuit_mark_for_close_(): Circuit 2262666673 (id: 15) marked for close at src/core/or/circuituse.c:1507 (orig reason: 9, new reason: 0)
```
Finally a SOCKS error code `0x5b` is returned to the application after some long amount of time.
In summary, the main problems are:
(1) Tor has checks for only `CIRCUIT_PURPOSE_C_GENERAL` when it should be checking for other circuit purposes like `CIRCUIT_PURPOSE_CONTROLLER`.
(2) Tor attempts to resolve the address of an empty string.
(3) (Maybe?) It takes a long time before the application is notified that the SOCKS connection was unsuccessful.
Thanks to arma for help debugging this.Neel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.org