The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:40:27Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30868Modify client rendezvous library to remove hard-coded responses2020-06-27T13:40:27ZCecylia BocovichModify client rendezvous library to remove hard-coded responsesClient tests rely of `client/lib/rendezvous.go` rely on specific HTTP response bodies which are prone to change and unnecessaryClient tests rely of `client/lib/rendezvous.go` rely on specific HTTP response bodies which are prone to change and unnecessaryTor: unspecifiedhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29565Fix broker robots.txt to disallow crawling2020-06-27T13:40:32ZDavid Fifielddcf@torproject.orgFix broker robots.txt to disallow crawlingFrom comment:11:ticket:28848 and https://github.com/ahf/snowflake-notes/blob/fb4304a7df08c6ddeeb103f38fc9103721a20cd9/Broker.markdown#the-robotstxt-handler:
> - Was the question about crawling ever answered? I can't think of a very good...From comment:11:ticket:28848 and https://github.com/ahf/snowflake-notes/blob/fb4304a7df08c6ddeeb103f38fc9103721a20cd9/Broker.markdown#the-robotstxt-handler:
> - Was the question about crawling ever answered? I can't think of a very good reason not to allow it. Even if censors were crawling the web for Snowflake brokers, they could get this information much more easily just from the source code.
I believe the intention behind the robots.txt handler is to prevent search engines from indexing any pages on the site, because there's no permanent information there, not for any security or anti-enumeration reason.
ahf points out that the current robots.txt achieves the opposite: it allows crawling of all pages by anyone. Instead of
```
User-agent: *
Disallow:
```
it should be
```
User-agent: *
Disallow: /
```Cecylia BocovichCecylia Bocovichhttps://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/tpa/team/-/issues/25796Update spec.torproject.org for new specs2020-06-27T14:18:18ZteorUpdate spec.torproject.org for new specsThere are 4 new specs, and one has moved.
It would also be nice to map proposals/
Is this an automated process, or does it need a manual patch?There are 4 new specs, and one has moved.
It would also be nice to map proposals/
Is this an automated process, or does it need a manual patch?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/33832For relays that change ip, only the measurements with the last ip are kept2020-12-18T09:41:15ZjugaFor relays that change ip, only the measurements with the last ip are keptwhich makes those relays more likely to don't be "eligible" cause don't have enough results and therefore, sbws voting in less relays.which makes those relays more likely to don't be "eligible" cause don't have enough results and therefore, sbws voting in less relays.sbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/33831Relays without descriptors are not scaled, but still added to the bwlines wit...2020-11-30T11:49:39ZjugaRelays without descriptors are not scaled, but still added to the bwlines without vote=0As can be seen in: https://gitweb.torproject.org/sbws.git/tree/sbws/lib/v3bwfile.py?h=maint-1.1#n1317
As a result, some relays (in sample data counted ~800) are included in the bandwidth file without its bandwidth scaled, which could b...As can be seen in: https://gitweb.torproject.org/sbws.git/tree/sbws/lib/v3bwfile.py?h=maint-1.1#n1317
As a result, some relays (in sample data counted ~800) are included in the bandwidth file without its bandwidth scaled, which could be quite different (higher or lower) than the scaled bandwidth.
This is one of the several reasons of legacy/trac#33775.sbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/33472Document that bwauths should checkout stable versions when installing sbws fr...2020-07-14T16:44:07ZjugaDocument that bwauths should checkout stable versions when installing sbws from giti think that if some bwauths are installing sbws from git, they should checkout a tag or a bugfix branch. We might want to have a bwauth to run a development branch, but it should be only one.i think that if some bwauths are installing sbws from git, they should checkout a tag or a bugfix branch. We might want to have a bwauth to run a development branch, but it should be only one.sbws: 1.1.x-finaljugajugahttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/33009sbws bandwidth scans should require a minimum exit bandwidth2022-02-11T09:53:47Zteorsbws bandwidth scans should require a minimum exit bandwidthWhen sbws is constructing a two-hop measurement circuit to run a test, it tries to pick an exit that has at least twice the consensus weight of the current relay-under-test:
https://github.com/torproject/sbws/blob/master/sbws/core/scanne...When sbws is constructing a two-hop measurement circuit to run a test, it tries to pick an exit that has at least twice the consensus weight of the current relay-under-test:
https://github.com/torproject/sbws/blob/master/sbws/core/scanner.py#L216
So this means that in this case, sbws would have picked any exit that was not a BadExit, has an acceptable ExitPolicy, and has a consensus weight of at least, well, 2. That's not a lot.
As it turns out, something like 10% of exits have under a 600Kbyte/sec advertised bandwidth. So it seems pretty easy from this weight=1 bootstrap scenario to get paired with an exit that will give poor test results.
Perhaps bwauth path selection should also choose a testing pair from exits/relays with a certain absolute minimum of weight or advertised bandwidth?
Reported by Jimmy on tor-relays:
https://lists.torproject.org/pipermail/tor-relays/2020-January/018027.htmlsbws: 1.1.x-finalGeorg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/29953Parent ticket for easy tickets that do not change version2021-06-15T14:21:22ZjugaParent ticket for easy tickets that do not change versionChild issues:
- #29952
- #28045
- #29294
- #28589
- #28758
- #28759Child issues:
- #29952
- #28045
- #29294
- #28589
- #28758
- #28759sbws: unspecifiedhttps://gitlab.torproject.org/tpo/network-health/sbws/-/issues/29749Remove never used "userquery" code2022-01-28T11:02:56ZjugaRemove never used "userquery" codesbws: 2.0.x-final-old