The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-07-09T04:22:45Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12843Bridgedb shouldn't handout bridges from .ir and .sy2022-07-09T04:22:45ZNima FatemiBridgedb shouldn't handout bridges from .ir and .syThe public network in these countries is highly censored and the average non-gov-supported/non-suspicious internet connection a user can have is capped to 128kb/s (16KB/s) by authorities in ir.
I can't think of anything these bridges ca...The public network in these countries is highly censored and the average non-gov-supported/non-suspicious internet connection a user can have is capped to 128kb/s (16KB/s) by authorities in ir.
I can't think of anything these bridges can offer to tor network and its users other than harm and unmasking attacks.
Hopefully, we'd come up with a plan to prevent malicious activity by these bridges in long-term, but for now, we should stop handing them out.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12504Create BridgeDB config setting for which Pluggable Transports are supported2020-06-27T13:43:11ZIsis LovecruftCreate BridgeDB config setting for which Pluggable Transports are supportedCurrently, there is a list of the "currently supported Pluggable Transports" in `bridgedb.strings`. This module attribute can be used to change which PTs are listed in the dropdown menu on https://bridges.torproject.org/options, as well ...Currently, there is a list of the "currently supported Pluggable Transports" in `bridgedb.strings`. This module attribute can be used to change which PTs are listed in the dropdown menu on https://bridges.torproject.org/options, as well as in the list sent out in email responses. Changing this will easily change what both UIs display, however, there still are some sections of BridgeDB's code where the supported PTs are hardcoded.
We need to:
1. Identify where and why PT method names are hardcoded.
2. Create a config setting in `bridgedb.conf` to set this list globally (in the UI, and in code logic).
3. Get rid of all the hardcoded PT method names in (1) and replace them with the thing from (2).Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12091BridgeDB still isn't checking DKIM verification results properly2020-06-27T13:43:12ZIsis LovecruftBridgeDB still isn't checking DKIM verification results properlyFrom [this commit message](https://gitweb.torproject.org/user/isis/bridgedb.git/commitdiff/4c18a4e2b89872c5731d4301665642065980086e) for [this unittest](https://gitweb.torproject.org/user/isis/bridgedb.git/blob/4c18a4e2b89872c5731d430166...From [this commit message](https://gitweb.torproject.org/user/isis/bridgedb.git/commitdiff/4c18a4e2b89872c5731d4301665642065980086e) for [this unittest](https://gitweb.torproject.org/user/isis/bridgedb.git/blob/4c18a4e2b89872c5731d4301665642065980086e:/lib/bridgedb/test/test_email_server.py#l326):
> Also, "dunno" certainly isn't a valid DKIM signature.
See the ticket description for legacy/trac#12086 for how
```
15:30:31 DEBUG L495:server.lineReceived() > X-DKIM-Authentication-Results: dunno
```
ended up in the headers on an incoming email in the first place.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/11377New BridgeDB GimpCaptcha should be case insensitive (or should say it's sensi...2020-06-27T13:43:13ZwfnNew BridgeDB GimpCaptcha should be case insensitive (or should say it's sensitive)Sherief reports that the new captcha is case sensitive (it is), whereas the previous (re)captcha was not (the check was done remotely, remote resource must have implicitly done case-insensitive check.)
I assume this is the relevant line...Sherief reports that the new captcha is case sensitive (it is), whereas the previous (re)captcha was not (the check was done remotely, remote resource must have implicitly done case-insensitive check.)
I assume this is the relevant line: https://gitweb.torproject.org/bridgedb.git/blob/HEAD:/lib/bridgedb/captcha.py#l206
Should probably either do a case-insensitive comparison, or should tell users it's case sensitive (I suppose the former makes more sense.)Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/11346BridgeDB should link to the BridgeDB homepage somewhere2020-06-27T13:43:14ZIsis LovecruftBridgeDB should link to the BridgeDB homepage somewhereProbably on the "BridgeDB" logo at the top of every page.Probably on the "BridgeDB" logo at the top of every page.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/11219BridgeDB's twisted version doesn´t have a `t.w.client.HTTPConnectionPool` class2020-06-27T13:43:14ZIsis LovecruftBridgeDB's twisted version doesn´t have a `t.w.client.HTTPConnectionPool` classAnd as such, bridgedb-0.1.5 with the patches for legacy/trac#11127 will not run, because it uses `twisted.web.client.HTTPConnectionPool` to kill disable persistent connections to the reCaptcha API server. While waiting for it to get upda...And as such, bridgedb-0.1.5 with the patches for legacy/trac#11127 will not run, because it uses `twisted.web.client.HTTPConnectionPool` to kill disable persistent connections to the reCaptcha API server. While waiting for it to get updated, we need to patch this out to that the `HTTPConnectionPool` isn't called.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/11218bridgedb.HTTPServer.ReCaptchaProtectedResource.checkSolution() doesn't expect...2020-06-27T13:43:14ZIsis Lovecruftbridgedb.HTTPServer.ReCaptchaProtectedResource.checkSolution() doesn't expect a deferredFrom bridgedb-0.1.5, `bridgedb.HTTPServer.ReCaptchaProtectedResource.checkSolution()` expects a `bool` for the `solution` internal variable, not a `t.i.defer.Deferred`:
```
Unhandled Error
Traceback (most recent call last):
File "/usr...From bridgedb-0.1.5, `bridgedb.HTTPServer.ReCaptchaProtectedResource.checkSolution()` expects a `bool` for the `solution` internal variable, not a `t.i.defer.Deferred`:
```
Unhandled Error
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1349, in dataReceived
finishCallback(data[contentLength:])
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1563, in _finishRequestBody
self.allContentReceived()
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 1618, in allContentReceived
req.requestReceived(command, path, version)
File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 773, in requestReceived
self.process()
--- <exception caught here> ---
File "/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 132, in process
self.render(resrc)
File "/usr/lib/python2.7/dist-packages/twisted/web/server.py", line 167, in render
body = resrc.render(self)
File "/usr/lib/python2.7/dist-packages/twisted/web/resource.py", line 216, in render
return m(request)
File "/srv/bridges.torproject.org/local/lib/python2.7/site-packages/bridgedb-0.1.5_dirty-py2.7.egg/bridgedb/HTTPServer.py", line 470, in render_POST
return CaptchaProtectedResource.render_POST(self, request)
File "/srv/bridges.torproject.org/local/lib/python2.7/site-packages/bridgedb-0.1.5_dirty-py2.7.egg/bridgedb/HTTPServer.py", line 220, in render_POST
if self.checkSolution(request):
File "/srv/bridges.torproject.org/local/lib/python2.7/site-packages/bridgedb-0.1.5_dirty-py2.7.egg/bridgedb/HTTPServer.py", line 432, in checkSolution
if solution.is_valid:
exceptions.AttributeError: Deferred instance has no attribute 'is_valid'
```
Should be easy, just reorder the current code to make `solution.is_valid` be checked inside a callback function on the deferred returned from `txrecaptcha.submit()`. See the `test_submit_resultIsRecaptchaResponse()` unittest for an example of how it was designed to work.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/11215Add timestamp/expiry to HMAC verification code in BridgeDB's local CAPTCHAs2020-06-27T13:43:15ZIsis LovecruftAdd timestamp/expiry to HMAC verification code in BridgeDB's local CAPTCHAsThe CAPTCHAs created in legacy/trac#10809 are in the form:
```
HMACFn := HMAC(HMAC_KEY, REQUEST_IP_ADDR)
CAPTCHA_VERIFICATION := HMACFn(RSA_ENC(CAPTCHA_ANSWER))
```
When they really should be more like:
```
HMACFn := HMAC(HMAC_KEY, REQ...The CAPTCHAs created in legacy/trac#10809 are in the form:
```
HMACFn := HMAC(HMAC_KEY, REQUEST_IP_ADDR)
CAPTCHA_VERIFICATION := HMACFn(RSA_ENC(CAPTCHA_ANSWER))
```
When they really should be more like:
```
HMACFn := HMAC(HMAC_KEY, REQUEST_IP_ADDR)
CAPTCHA_VERIFICATION := HMACFn(TIMESTAMP, RSA_ENC(CAPTCHA_ANSWER))
```
See [this commit message](https://gitweb.torproject.org/bridgedb.git/commitdiff/eeb6956ed7f7ddd0f2592c17f4a5d58a580fb878) from the original branch. After adding the timestamp to the `CAPTCHA_VERIFICATION` creation in `bridgedb.captcha.GimpCaptcha.createChallenge()`, said timestamp should obviously be checked that it is not expired (according to some easily configurable expiration period) in `bridgedb.captcha.GimpCaptcha.checkSolution()`.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10831Captchas are not accessible for blind users2023-02-13T17:48:03ZTracCaptchas are not accessible for blind usersHi,
There are no way for blind users to solve captchas on bridge.torproject.org, would it be possible to add a way to make it possible please?
A solution could be to provide an audio captcha, using combinations of numbers or in all case...Hi,
There are no way for blind users to solve captchas on bridge.torproject.org, would it be possible to add a way to make it possible please?
A solution could be to provide an audio captcha, using combinations of numbers or in all cases, something spelled.
I think Recaptcha gives the possibility to add it, but I used it a long time ago so I am not sure it is still the case.
**Trac**:
**Username**: PZajdahttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10559BridgeDB writes `keyid=` before fingerprints2020-06-27T13:43:18ZIsis LovecruftBridgeDB writes `keyid=` before fingerprintsWhile testing for legacy/trac#9499, I realised that if I request https://127.0.0.1:6789/bridges?transport=obfs3 (localhost because it's a local test instance) then BridgeDB hands back bridge lines like this:
```
obfs3 245.102.100.252:236...While testing for legacy/trac#9499, I realised that if I request https://127.0.0.1:6789/bridges?transport=obfs3 (localhost because it's a local test instance) then BridgeDB hands back bridge lines like this:
```
obfs3 245.102.100.252:23619 keyid=59ca743e89b508e16b8c7c6d2290efdfd14eea98
```
which is wrong and will need to be fixed before we hand out fingerprints. This should be easy, just figure out where this string is getting added and kill it with fire.Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/10446BridgeDB is/was using a GeoIP module which is incompatible with virtualenvs2020-06-27T13:43:18ZIsis LovecruftBridgeDB is/was using a GeoIP module which is incompatible with virtualenvs```
04:07 [ (isis) ) sysrqb: i realised yesterday that we're actually using the wrong GeoIP module in bridgedb's requirements.txt
04:08 [ (isis) ) although the one we're using, pygeoip.GeoIP, is compatible (at least it has all the same f...```
04:07 [ (isis) ) sysrqb: i realised yesterday that we're actually using the wrong GeoIP module in bridgedb's requirements.txt
04:08 [ (isis) ) although the one we're using, pygeoip.GeoIP, is compatible (at least it has all the same functions we're using from the the GeoIP one)
04:09 [ (isis) ) i am thinking that perhaps we should keep using the "wrong" one, since it is compatible
04:10 [ (isis) ) because the "wrong" one (the pygeoip one) installs cleanly in a virtualenv, while the other one does not
04:10 [ (isis) ) i think they both require the same underlying deps, libgeoip-dev and geoip-database in Debian
04:11 [ (isis) ) which means that my README instructions which said that bridgedb requires tor-geoipdb were also wrong
```Isis LovecruftIsis Lovecrufthttps://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/28681reflected XSS metrics.torproject.org2021-06-30T15:32:58ZTracreflected XSS metrics.torproject.orgHello! I have been found reflected XSS vulnerability on subdomain of torproject.
You should fix it :) Screenshot with easy exploit is attached to ticket.
If it possible, I will proud to get one more sticker pack ^^ .
```
https://metri...Hello! I have been found reflected XSS vulnerability on subdomain of torproject.
You should fix it :) Screenshot with easy exploit is attached to ticket.
If it possible, I will proud to get one more sticker pack ^^ .
```
https://metrics.torproject.org/rs.html#search/1337%22%3E%3Cimg%20src=x%20onerror=alert(1)%3E
```
the vector is:
**"><img src=x onerror=alert(1)>**
P0W3RING D1G1T4L R3S1S74NC3!
**Trac**:
**Username**: 0x539hhttps://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.org