Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2023-06-01T14:40:43Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/31Dependency Dashboard2023-06-01T14:40:43ZRenovate BotDependency DashboardThis issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbo...This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
- [ ] <!-- rebase-branch=renovate/golang-1.x -->[Update golang Docker tag to v1.20](!11)
## Detected dependencies
<details><summary>gitlabci</summary>
<blockquote>
<details><summary>.gitlab-ci.yml</summary>
- `golang 1.18-buster`
- `golang 1.20-buster`
- `golang 1.20-buster`
</details>
</blockquote>
</details>
<details><summary>gomod</summary>
<blockquote>
<details><summary>go.mod</summary>
- `go 1.17`
- `git.torproject.org/pluggable-transports/snowflake.git/v2 v2.5.1`
- `github.com/pires/go-proxyproto v0.7.0`
- `github.com/refraction-networking/gotapdance v1.5.0`
- `gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib v1.4.0`
</details>
</blockquote>
</details>https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40273Automated Testing Script for Potential Domain Fronting Domains2023-10-25T15:42:23ZshelikhooAutomated Testing Script for Potential Domain Fronting DomainsIn order to make it easier to deal with blocking of domain fronting domains that is being observed in Iran, Russia, and possibly China, a [script](https://gist.github.com/xiaokangwang/3e6b7ca99a30b13f82ed5fe6bf8d8f43) was written to auto...In order to make it easier to deal with blocking of domain fronting domains that is being observed in Iran, Russia, and possibly China, a [script](https://gist.github.com/xiaokangwang/3e6b7ca99a30b13f82ed5fe6bf8d8f43) was written to automate the screening of domain name for domain fronting.
The following domain name was evaluated to be potentially useable for domain fronting. We should try to reduce solo reliance on cdn.sstatic.net with a fronting domain rotation system to reduce the chance any of them get blocked.
See also: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40068 , https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/123shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/logcollector/-/issues/4Implement Alert System for logcollector2023-10-25T13:11:16ZshelikhooImplement Alert System for logcollectorIn order to implement an alert system for resource monitored by logcollector, a standardized result reporting system should be used to report a subset of data to a metrics monitoring system(Prometheus), which will subsequently generate a...In order to implement an alert system for resource monitored by logcollector, a standardized result reporting system should be used to report a subset of data to a metrics monitoring system(Prometheus), which will subsequently generate alert(grafana alert managor).
This would require adding state system to log collector to keep essential data between restart as well as prometheus data exporter for some data.
## State system
A json file with all persistent states will be written to the disk every second if there is a change in the status. The file will be named `status.{start_time}.{time_after_start}.json`, where {start_time} is the system wall clock time when process started in linux time format, {time_after_start} is the number of seconds since the process started in monotonic clock second. (Current wall clock time is not used to deal with leap second or more likely ntp time adjustment).
A new file is always created for each save, and logcollecor is designed to never overwrite any state file. An external [script](https://superuser.com/questions/268344/how-do-i-delete-all-but-10-newest-files-in-linux) will be used to delete old status.
Each exporter have its own state files.
## prometheus data exporter
Log collector will expose a standard prometheus data exporter endpoint to facilitate alerts.
It will initially only expose vantage point last seen information as `vantage_point_lastseen(site=XXX)`.
(See also: https://gitlab.torproject.org/tpo/anti-censorship/connectivity-measurement/logcollector-admin/-/issues/6)shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40038Blocking of Snowflake in China, 2023-05-12 to 2023-05-152023-05-22T17:13:09ZDavid Fifielddcf@torproject.orgBlocking of Snowflake in China, 2023-05-12 to 2023-05-15Reports of failures to connect with Snowflake in China since 2023-05-12
https://github.com/net4people/bbs/issues/249
> Around afternoon time on May 12 2023,tor browser's built in snowflake stops working<br>
> Connection asist doesn't w...Reports of failures to connect with Snowflake in China since 2023-05-12
https://github.com/net4people/bbs/issues/249
> Around afternoon time on May 12 2023,tor browser's built in snowflake stops working<br>
> Connection asist doesn't work neither.
>
> In Wireshark I see full package loss(TCP Spurious Transmission) to the supposely existing bridge front server(i think that what it is called) ip after initial handshake.
https://forum.torproject.net/t/snowflake-bridge-does-not-work-in-china-since-days-ago/7635
> I built the Snowflake client manually and run it, got Tor logs below, the connection hangs on 10% forever.
Bridge users graph.
https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-03-01&end=2023-05-15&country=cn<br>
[![Bridge users by transport from China](/uploads/7e3dcbdc20254fe0df1379015e89ca54/userstats-bridge-combined-cn-2023-03-01-2023-05-15.png)](https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-03-01&end=2023-05-15&country=cn)
A graph that shows the separate contributions of the two bridges, also with the `??` geolocation bug retroactively fixed, by redistributing `??` proportionally to the other countries. This was made from [snowflake-graphs 9de9b4ed](https://gitlab.torproject.org/dcf/snowflake-graphs/-/tree/9de9b4ed7cd7830efce45c191d0a12f63d3cc112) with the additional patch [top-countries-cn.patch.gz](/uploads/d7d96c1e98137a498579f8a12fb7a8df/top-countries-cn.patch.gz).
![Snowflake users in China](/uploads/06f657e8111b9abd9b7f49053dad4069/snowflake-userstats-bridge-combined-cn-20230513.png)
Note that there are events from the the [metrics timeline](https://gitlab.torproject.org/tpo/network-health/metrics/timeline)
that bear on these graphs:
|start date|end date|places|protocols|description|links|? |
|----------|--------|------|---------|-----------|-----|---|
|2023-04-11||cn|obfs4|Sudden drop in access to bridges from the "settings" and "moat" pools from China.|[comment](https://bugs.torproject.org/tpo/anti-censorship/censorship-analysis/40033#note_2896876) [bridge graph](https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-03-01&end=2023-05-31&country=cn)|X|
|2023-04-11|||snowflake|Release of Snowflake WebExtension 0.7.2, with a fix for missing client country information that had been introduced in 0.6.0 on 2022-06-27. The result is better country-level attribution of Snowflake users: most who had been being assigned to `??` are now assigned to their proper geolocated country.|[archive](https://archive.org/details/snowflake-webextension-0.7.2) [comment](https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/82#note_2895133)||
|2023-04-12|||snowflake|Orbot begins a release rollout of version 17.0.0-RC-1-tor.0.4.7.11. First release of Orbot to include the snowflake-02 bridge along with the existing snowflake-01. Has a change to the Snowflake DTLS fingerprint (removes Hello Verify Request) to mitigate reported blocking in Russia.|[release](https://github.com/guardianproject/orbot/releases/tag/17.0.0-RC-1-tor.0.4.7.11) [Orbot commit adding snowflake-02](https://github.com/guardianproject/orbot/commit/c3f6ee18f17770a5904ad19c3cd24b9c8dcb3885) [IPtProxy commit upgrading Snowflake](https://github.com/tladesignz/IPtProxy/commit/5d0654a6a1439c05d3ee52b2b351b5df1ff3f6dc)||
|2023-04-19||cn|obfs4 snowflake|Changed the recommended transport in Circumvention Settings in China from obfs4 to snowflake.|[comment](https://bugs.torproject.org/tpo/anti-censorship/censorship-analysis/40033#note_2898442) [commit](https://gitlab.torproject.org/tpo/anti-censorship/rdsys-admin/-/commit/082c227d680330cf7ff06cd9dff1d59ebc91c4cf)||
Relay users for comparison:
https://metrics.torproject.org/userstats-relay-country.html?start=2023-03-01&end=2023-05-15&country=cn<br>
[![Directly connecting users from China](/uploads/d3c30efab7906b68c67ad6fe429f7ddf/userstats-relay-country-cn-2023-03-01-2023-05-15-off.png)](https://metrics.torproject.org/userstats-relay-country.html?start=2023-03-01&end=2023-05-15&country=cn)
OONI's data on cdn.sstatic.net in China is sparse, though it perhaps shows a larger proportion of anomalies since 2023-05-12:
https://explorer.ooni.org/chart/mat?probe_cc=CN&since=2023-04-22&until=2023-05-16&time_grain=day&axis_x=measurement_start_day&test_name=web_connectivity&domain=cdn.sstatic.net<br>
[![Web Connectivity Test, cdn.sstatic.net in China](/uploads/65d03af08c65170dac75a28a29f6c1c0/ooni-mat-cdn.sstatic.net-cn-20230515.png)](https://explorer.ooni.org/chart/mat?probe_cc=CN&since=2023-04-22&until=2023-05-16&time_grain=day&axis_x=measurement_start_day&test_name=web_connectivity&domain=cdn.sstatic.net)
OONI has more torsf measurements. It does look like there are more anomalies since 2023-05-12, or even before.
https://explorer.ooni.org/chart/mat?probe_cc=CN&since=2023-04-22&until=2023-05-16&time_grain=day&axis_x=measurement_start_day&test_name=torsf<br>
![Tor Snowflake Test in China](/uploads/784152cda8c73c9256d84ad19ae8fc61/ooni-mat-torsf-cn-20230515.png)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40272go snowflake picks 'restricted' but stun-nat-behaviour picked endpoint indepe...2023-05-16T18:32:06ZRoger Dingledinego snowflake picks 'restricted' but stun-nat-behaviour picked endpoint independentOn my new Debian bookworm-rc2, I installed the stun-nat-behaviour testing tool:
```
$ go install github.com/pion/stun/cmd/stun-nat-behaviour@latest
go: downloading github.com/pion/stun v0.5.2
go: downloading github.com/pion/dtls/v2 v2.2....On my new Debian bookworm-rc2, I installed the stun-nat-behaviour testing tool:
```
$ go install github.com/pion/stun/cmd/stun-nat-behaviour@latest
go: downloading github.com/pion/stun v0.5.2
go: downloading github.com/pion/dtls/v2 v2.2.6
go: downloading github.com/pion/transport/v2 v2.2.0
go: downloading golang.org/x/crypto v0.5.0
go: downloading github.com/pion/udp/v2 v2.0.1
$ cd go/bin/
$ ./stun-nat-behaviour
INFO: 2023/05/13 15:45:02 connecting to STUN server: stun.voip.blackberry.com:3478
INFO: 2023/05/13 15:45:02 Local address: 0.0.0.0:33731
INFO: 2023/05/13 15:45:02 Remote address: 20.15.169.7:3478
INFO: 2023/05/13 15:45:02 Mapping Test I: Regular binding request
INFO: 2023/05/13 15:45:02 Sending to 20.15.169.7:3478: (20 bytes)
INFO: 2023/05/13 15:45:03 Response from 20.15.169.7:3478: (92 bytes)
INFO: 2023/05/13 15:45:03 Error: NAT discovery feature not supported by this server
WARNING: 2023/05/13 15:45:03 NAT mapping behavior: inconclusive
INFO: 2023/05/13 15:45:03 connecting to STUN server: stun.voip.blackberry.com:3478
INFO: 2023/05/13 15:45:03 Local address: 0.0.0.0:60922
INFO: 2023/05/13 15:45:03 Remote address: 20.15.169.7:3478
INFO: 2023/05/13 15:45:03 Filtering Test I: Regular binding request
INFO: 2023/05/13 15:45:03 Sending to 20.15.169.7:3478: (20 bytes)
INFO: 2023/05/13 15:45:03 Response from 20.15.169.7:3478: (92 bytes)
WARNING: 2023/05/13 15:45:03 Error: NAT discovery feature not supported by this server
WARNING: 2023/05/13 15:45:03 NAT filtering behavior: inconclusive
$ ./stun-nat-behaviour -server stun.voipgate.com:3478
INFO: 2023/05/13 15:46:13 connecting to STUN server: stun.voipgate.com:3478
INFO: 2023/05/13 15:46:13 Local address: 0.0.0.0:52168
INFO: 2023/05/13 15:46:13 Remote address: 185.125.180.70:3478
INFO: 2023/05/13 15:46:13 Mapping Test I: Regular binding request
INFO: 2023/05/13 15:46:13 Sending to 185.125.180.70:3478: (20 bytes)
INFO: 2023/05/13 15:46:13 Response from 185.125.180.70:3478: (100 bytes)
INFO: 2023/05/13 15:46:13 Received XOR-MAPPED-ADDRESS: 173.56.90.221:52168
INFO: 2023/05/13 15:46:13 Mapping Test II: Send binding request to the other address but primary port
INFO: 2023/05/13 15:46:13 Sending to 185.125.180.71:3478: (20 bytes)
INFO: 2023/05/13 15:46:13 Response from 185.125.180.71:3478: (100 bytes)
INFO: 2023/05/13 15:46:13 Received XOR-MAPPED-ADDRESS: 173.56.90.221:52168
WARNING: 2023/05/13 15:46:13 => NAT mapping behavior: endpoint independent
INFO: 2023/05/13 15:46:13 connecting to STUN server: stun.voipgate.com:3478
INFO: 2023/05/13 15:46:13 Local address: 0.0.0.0:55735
INFO: 2023/05/13 15:46:13 Remote address: 185.125.180.70:3478
INFO: 2023/05/13 15:46:13 Filtering Test I: Regular binding request
INFO: 2023/05/13 15:46:13 Sending to 185.125.180.70:3478: (20 bytes)
INFO: 2023/05/13 15:46:14 Response from 185.125.180.70:3478: (100 bytes)
INFO: 2023/05/13 15:46:14 Filtering Test II: Request to change both IP and port
INFO: 2023/05/13 15:46:14 Sending to 185.125.180.70:3478: (28 bytes)
INFO: 2023/05/13 15:46:14 Response from 185.125.180.71:3479: (100 bytes)
WARNING: 2023/05/13 15:46:14 => NAT filtering behavior: endpoint independent
```
which sure makes me think that I successfully put my laptop in dmz mode behind my router. (As another data point, I can telnet in to services on this laptop from the outside).
But then running headless snowflake, I have
```
2023/05/13 19:57:49 snowflake-proxy 2.4.1
023/05/13 19:57:49 Proxy starting
2023/05/13 19:57:49 WebRTC: Created offer
2023/05/13 19:57:49 WebRTC: Set local description
2023/05/13 19:57:54 Offer: {"type":"offer","sdp":"v=0\r\no=- 4036211437389836707 1684007869 IN IP4 [scrubbed]\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 15:17:2D:41:43:C5:5D:D4:BD:B0:20:17:01:36:DB:0A:60:2B:E5:C4:A0:01:69:55:8F:77:71:17:72:F2:64:57\r\na=extmap-allow-mixed\r\na=group:BUNDLE 0\r\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 [scrubbed]\r\na=setup:actpass\r\na=mid:0\r\na=sendrecv\r\na=sctp-port:5000\r\na=ice-ufrag:TKUQqKORrkMnHIMw\r\na=ice-pwd:xLDVhUwJYEBnMGBjSgqOnluskGZjDVNg\r\na=candidate:1961522861 1 udp 2130706431 [scrubbed] 39181 typ host\r\na=candidate:1961522861 2 udp 2130706431 [scrubbed] 39181 typ host\r\na=end-of-candidates\r\n"}
2023/05/13 19:58:19 NAT Type measurement: unknown -> restricted = restricted
2023/05/13 19:58:19 NAT type: restricted
```
It sure looks like my snowflake is mistakenly calling me restricted when I'm not.
Did the newer go libs or something cause a regression where we think people like me are restricted?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/40011error while building main branch of obfs42023-05-25T20:28:25Zboklmerror while building main branch of obfs4While building the `main` branch (currently baf2254038d2390ac2b4ca97ca78365ae39e4d54), I have the following error:
```
# github.com/klauspost/compress/huff0
../vendor/github.com/klauspost/compress/huff0/decompress.go:774:21: cannot conve...While building the `main` branch (currently baf2254038d2390ac2b4ca97ca78365ae39e4d54), I have the following error:
```
# github.com/klauspost/compress/huff0
../vendor/github.com/klauspost/compress/huff0/decompress.go:774:21: cannot convert out (variable of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:775:24: cannot convert out[dstEvery:] (value of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:776:24: cannot convert out[dstEvery * 2:] (value of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:777:24: cannot convert out[dstEvery * 3:] (value of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:1013:21: cannot convert out (variable of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:1014:24: cannot convert out[dstEvery:] (value of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:1015:24: cannot convert out[dstEvery * 2:] (value of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
../vendor/github.com/klauspost/compress/huff0/decompress.go:1016:24: cannot convert out[dstEvery * 3:] (value of type []byte) to type *[256]byte:
conversion of slices to array pointers requires go1.17 or later (-lang was set to go1.16; check go.mod)
```
I have not tested but I think updating the go version to 1.17 in `go.mod` might fix that.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40270Upgrade tor on snowflake-01 to 0.4.72024-01-22T15:19:37ZDavid Fifielddcf@torproject.orgUpgrade tor on snowflake-01 to 0.4.7snowflake-01 is currently running 0.4.5.16, which is end of life and may get removed from the network as early as next week:
* https://mastodon.social/@torproject/110256009579078954
* https://forum.torproject.net/t/tor-relays-psa-tor-0-4...snowflake-01 is currently running 0.4.5.16, which is end of life and may get removed from the network as early as next week:
* https://mastodon.social/@torproject/110256009579078954
* https://forum.torproject.net/t/tor-relays-psa-tor-0-4-5-reaches-end-of-life-eol-on-2023-02-15/6338
We need to upgrade to the 0.4.7 series.
This probably means switching to the [torproject.org deb repository](https://support.torproject.org/apt/)
rather than the Debian one.
But we need to be careful with this one and be ready to revert the upgrade quickly if necessary.
0.4.7.13 has new support for the [`IP_BIND_ADDRESS_NO_PORT`](https://forum.torproject.net/t/stable-release-0-4-5-16-and-0-4-7-13/6216)
socket option when using `OutboundBindAddress` in torrc.
(As [we currently do](tpo/anti-censorship/pluggable-transports/snowflake#40223)
as an attempted mitigation for anti-DDoS scripts at middle relays.)
Past analysis has shown that different processes interact badly with one another
when they bind sockets to a particular address and differ in whether they use `IP_BIND_ADDRESS_NO_PORT`:
a situation where everything uses the option is stable,
as is one where nothing uses the option;
but when one process uses `IP_BIND_ADDRESS_NO_PORT` and other do not,
the one that does may have its ephemeral ports "stolen" by those that do,
leading to `EADDRNOTAVAIL` errors.
It's why we
[force a source port range](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide?version_id=831f28b730b50c6656ada23ceee0abdad2a134db#haproxy)
in haproxy.cfg, because that has the side effect of disabling `IP_BIND_ADDRESS_NO_PORT` in haproxy.
If tor's new use of `IP_BIND_ADDRESS_NO_PORT` starts giving `EADDRNOTAVAIL`,
the immediate remedy is to downgrade to an old version.
Another possible quick fix is to remove `OutboundBindAddress` from the torrc files:
if the socket is not pre-bound, there's no problem.
The longer-term solution is to make the other programs on the system that bind to a source address
also use `EADDRNOTAVAIL`.
For haproxy it's easy, just remove the source port ranges from haproxy.cfg.
The other programs to worry about are
[snowflake-server](tpo/anti-censorship/pluggable-transports/snowflake!120)
and [extor-static-cookie](https://gitlab.torproject.org/dcf/extor-static-cookie/-/commit/61e0684e40f84aa57a032e3fa9b80d2d24986bde),
both of which
[bind to a random localhost IP address in a range](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide?version_id=831f28b730b50c6656ada23ceee0abdad2a134db#localhost-address-ranges)
to avoid running out of localhost 4-tuples
(which is a separate issue from the `IP_BIND_ADDRESS_NO_PORT` one).
Last time I checked, [`net.Dialer`](https://pkg.go.dev/net#Dialer)
with `LocalAddr` set did *not* use `IP_BIND_ADDRESS_NO_PORT`.
Background on the `IP_BIND_ADDRESS_NO_PORT` issue:
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40201#note_2868367
* https://forum.torproject.net/t/tor-relays-inet-csk-bind-conflict/5757/16
* https://blog.cloudflare.com/the-quantum-state-of-a-tcp-port/
snowflake-02 is already running 0.4.7.13 without any apparent ill effects,
though it is at only about 15% the clients of snowflake-01.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2023-05-10https://gitlab.torproject.org/tpo/anti-censorship/gettor-project/OnionSproutsBot/-/issues/52plugins are loading from the local directory2023-05-24T17:52:27Zmeskiomeskio@torproject.orgplugins are loading from the local directoryRight now onionsprouts bot expect the plugins to be in `./OnionSproutsBot/plugins`. Which works fine for development as is usually run from the git repo, but not for deployment that we might want to run it from a different folder.
I thi...Right now onionsprouts bot expect the plugins to be in `./OnionSproutsBot/plugins`. Which works fine for development as is usually run from the git repo, but not for deployment that we might want to run it from a different folder.
I think plugins should be loaded from the onionsproutsbot library folder where is installed.Sponsor 139: Rapid Response Iranmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/125tpo/anti-censorship/lox/lox-overview#72023-04-18T16:30:56Zonyinyangtpo/anti-censorship/lox/lox-overview#7https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/163export num of bridges per ratio into prometheus2023-05-30T07:45:07Zmeskiomeskio@torproject.orgexport num of bridges per ratio into prometheusCan we add a metric to see how many bridges are per ratio? Something like: https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/152#note_2888840
We could use a counter with a label for the ratio. The problem is that prometh...Can we add a metric to see how many bridges are per ratio? Something like: https://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/152#note_2888840
We could use a counter with a label for the ratio. The problem is that prometheus doesn't handle well having too many different values for the label. We could to pack the ratios together on 0.1 steps and decide a maximum value that we just count together everything above that. I'm not sure if we'll be able to plot this nicelly in graphana or if there are better tools in prometheus for this.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/162Telegram distributor fails for new accounts with few dynamic bridges2023-08-23T18:59:04Zmeskiomeskio@torproject.orgTelegram distributor fails for new accounts with few dynamic bridgesThere is currently only one dynamic bridge. The telegram distributor is not working properly.There is currently only one dynamic bridge. The telegram distributor is not working properly.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40268Restart snowflake bridges for haproxy CVE-2023-08362023-04-15T03:18:15ZDavid Fifielddcf@torproject.orgRestart snowflake bridges for haproxy CVE-2023-0836The vulnerability has to do with FastCGI, which we don't use.
https://security-tracker.debian.org/tracker/DSA-5388-1<br>
https://lists.debian.org/debian-security-announce/2023/msg00078.html
> An information leak vulnerability was disco...The vulnerability has to do with FastCGI, which we don't use.
https://security-tracker.debian.org/tracker/DSA-5388-1<br>
https://lists.debian.org/debian-security-announce/2023/msg00078.html
> An information leak vulnerability was discovered in HAProxy 2.1, 2.2 before 2.2.27, 2.3, 2.4 before 2.4.21, 2.5 before 2.5.11, 2.6 before 2.6.8, 2.7 before 2.7.1. There are 5 bytes left uninitialized in the connection buffer when encoding the FCGI_BEGIN_REQUEST record. Sensitive data may be disclosed to configured FastCGI backends in an unexpected way.
https://ubuntu.com/security/notices/USN-5994-1
> It was discovered that HAProxy incorrectly initialized certain connection
buffers. A remote attacker could possibly use this issue to obtain
sensitive information.
- [x] snowflake-01
- [x] snowflake-02
/cc @linus
Past haproxy upgrade issue: #40253.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2023-04-18https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/161Resources with failing tests (bridgestrap/onbasca) should be explicitly marke...2023-06-16T18:10:10ZonyinyangResources with failing tests (bridgestrap/onbasca) should be explicitly marked as `gone`Resources that fail bridgestrap and/or onbasca tests are not distributed according to the [functionality here](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/pkg/core/backend_resources.go#L171) but as far as I can te...Resources that fail bridgestrap and/or onbasca tests are not distributed according to the [functionality here](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/pkg/core/backend_resources.go#L171) but as far as I can tell are not marked as `gone` explicitly anywhere. Instead resources are determined to be `gone` when they have been pruned [based on their expiration](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/internal/kraken.go#L62) but this is based on when a resource's bridge descriptors expire rather than when a resource is failing for other reasons. If resources are no longer distributed, they should be marked as `gone` to ease syncing with distributors. This functionality is particularly important for systems like Lox that maintain some internal bridge distribution state.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/160Include metrics to track flickering bridges/resources by onbasca ratio2023-05-29T23:19:43ZonyinyangInclude metrics to track flickering bridges/resources by onbasca ratioWhile rdsys [collects metrics for onbasca's bandwidth ratio](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/internal/kraken.go#L118) and provides insight on a resource's state (`untested`, `accepted`, `rejected`), it...While rdsys [collects metrics for onbasca's bandwidth ratio](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/internal/kraken.go#L118) and provides insight on a resource's state (`untested`, `accepted`, `rejected`), it would be useful to have more insight into whether and how often resources "flicker", meaning how often do `accepted` or `rejected` resources change back and forth?
The first step is to figure out if this happens. Then when we have collected some metrics about it and have determined if it does indeed happen, and how often, we can expand upon the information we collect about it.onyinyangonyinyanghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/19Fix crash on launch when unexpected input was supplyed over PT protocol2023-10-16T15:58:12ZshelikhooFix crash on launch when unexpected input was supplyed over PT protocol```
Apr 13 14:32:06.000 [info] launch_managed_proxy(): Managed proxy at '/usr/bin/webtunnel-server' has spawned with PID '100'.
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' repo...```
Apr 13 14:32:06.000 [info] launch_managed_proxy(): Managed proxy at '/usr/bin/webtunnel-server' has spawned with PID '100'.
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error: panic: assignment to entry in nil map
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error:
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error: goroutine 1 [running]:
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error: git.torproject.org/pluggable-transports/goptlib%2egit.Args.Add(...)
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error: /go/pkg/mod/git.torproject.org/pluggable-transports/goptlib.git@v1.2.0/args.go:32
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error: main.main()
Apr 13 14:32:08.000 [info] managed_proxy_stderr_callback(): Managed proxy at '/usr/bin/webtunnel-server' reported via standard error: /webtunnel/main/server/main.go:46 +0x430
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/30Dependency Dashboard2023-05-23T17:02:26ZRenovate BotDependency DashboardThis issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbo...This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.
## Open
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
- [x] <!-- rebase-branch=renovate/github.com-refraction-networking-gotapdance-1.x -->[Update module github.com/refraction-networking/gotapdance to v1.5.0](!9)
## Detected dependencies
<details><summary>gitlabci</summary>
<blockquote>
<details><summary>.gitlab-ci.yml</summary>
- `golang 1.18-stretch`
- `golang 1.20-buster`
- `golang 1.20-buster`
</details>
</blockquote>
</details>
<details><summary>gomod</summary>
<blockquote>
<details><summary>go.mod</summary>
- `go 1.17`
- `git.torproject.org/pluggable-transports/snowflake.git/v2 v2.5.1`
- `github.com/pires/go-proxyproto v0.7.0`
- `github.com/refraction-networking/gotapdance v1.3.0`
- `gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib v1.4.0`
</details>
</blockquote>
</details>Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/29Add CI to the project2023-04-12T15:41:01Zmeskiomeskio@torproject.orgAdd CI to the projectEven if there is no tests for now we could just check that it compiles.Even if there is no tests for now we could just check that it compiles.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/27Properly close all SOCKS connection handles2023-10-12T14:34:34ZCecylia BocovichProperly close all SOCKS connection handlesConjure pluggable transport wrapper fails to close the SOCKS connection in the event of a connection error. This will result in a resource leak that could be abused to deplete the connection resource pool and consequently prevent further...Conjure pluggable transport wrapper fails to close the SOCKS connection in the event of a connection error. This will result in a resource leak that could be abused to deplete the connection resource pool and consequently prevent further connections from being established.
If an attacker is capable of triggering this code path, they will be able to instigate a DoS attack and prevent any further client connections from being made by the Tor Browser. Notably, the standard use case in this scenario stipulates that the Tor Browser connects to the pluggable transport wrapper on localhost. As such, an attacker would already have compromised the host to trigger these connections.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/26Keep dependencies up to date2023-04-12T15:44:38ZCecylia BocovichKeep dependencies up to dateOther projects have started using a [renovate bot](https://gitlab.torproject.org/tpo/tpa/renovate-cron). We should look into this as well.Other projects have started using a [renovate bot](https://gitlab.torproject.org/tpo/tpa/renovate-cron). We should look into this as well.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/158Telegram Bridge Distributor responding with a blank message2023-04-19T11:43:07Zchampionquizzerchampionquizzer@torproject.orgTelegram Bridge Distributor responding with a blank messageThe @GetBridgesBot on Telegram is currently responding with a blank message and no bridge lines.
This is the response I am getting with `/bridges` or `Bridges`:
```
Your bridges:
```The @GetBridgesBot on Telegram is currently responding with a blank message and no bridge lines.
This is the response I am getting with `/bridges` or `Bridges`:
```
Your bridges:
```