The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-01T17:47:15Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/19774bridges.torproject.org could use a favicon2021-07-01T17:47:15ZIsis Lovecruftbridges.torproject.org could use a faviconIt doesn't have one. It could. I don't particularly care what it is, but a little bridge or a little onion might be cute.It doesn't have one. It could. I don't particularly care what it is, but a little bridge or a little onion might be cute.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12932Transport Key-Value pairs should be space separated2020-06-27T13:43:08ZMatthew FinkelTransport Key-Value pairs should be space separatedpt-spec says that the options should be space-separated:
```
2.1.0.1. Bridge torrc lines
Bridge lines specify how Tor should connect to a bridge. The Bridge
line format is:
Bridge [<transport>] <address>:<port> [<id-f...pt-spec says that the options should be space-separated:
```
2.1.0.1. Bridge torrc lines
Bridge lines specify how Tor should connect to a bridge. The Bridge
line format is:
Bridge [<transport>] <address>:<port> [<id-fingerprint>] [<k>=<v>] [<k>=<v>] [<k>=<v>]
The PT-specific parts of this format are the [transport] and [k=v]
values.
<transport> is the name of the PT that MUST be used when connecting to
the bridge, and the <k>=<v> values are PT-specific parameters that
MUST be passed to the PT when connecting to the bridge (this MAY
include keys, passwords or other PT configuration options) as
specified in [CLIENTPARAMS].
```
we comma-separate them:
```
args = ",".join(["%s=%s" % (k, v) for k, v in self.argdict.items()])
```Isis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12872Know within which country a bridge is located2020-06-27T13:43:08ZMatthew FinkelKnow within which country a bridge is locatedThis has many uses, but in particular this will allow us to do legacy/trac#12843. I suggest we not bother rewriting large portions of the code to satisfy this and simply add another attribute to the Bridge class specifying its country. A...This has many uses, but in particular this will allow us to do legacy/trac#12843. I suggest we not bother rewriting large portions of the code to satisfy this and simply add another attribute to the Bridge class specifying its country. As soon as we have this information we can do more smart things with it (and those can be other smarter tickets).
For simplicity, we can only rely on the the ORPort netblock. This is what the BA checks. In the future, when ORPorts are disableable, we'll need to rely on the addresses in the transport lines, but that can be dealt with later, I think.Isis LovecruftIsis Lovecrufthttps://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/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/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 Loesing