Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2022-08-17T19:29:57Zhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40050Change the 'select all' button for a 'copy all' when giving the bridges2022-08-17T19:29:57ZemmapeelChange the 'select all' button for a 'copy all' when giving the bridgesThis change has been suggested by a translator.
It will be even more comfortable to have the bridges copied when clicking the button, than just selected and then you have to do the copying. Lets save users a step, and copy the bridges f...This change has been suggested by a translator.
It will be even more comfortable to have the bridges copied when clicking the button, than just selected and then you have to do the copying. Lets save users a step, and copy the bridges for them:
![copyall](/uploads/1745238b654be298dfa507734a4352bd/copyall.png)Sponsor 30 - Objective 2.2https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030IRC Tip about Signature used to block Snowflake in Russia, 2022-May-162023-10-03T18:43:00ZshelikhooIRC Tip about Signature used to block Snowflake in Russia, 2022-May-16```
[2:46:20 pm] <blocked> Signature used by ru to block snowflake: \x16\xFE[\xFD\xFF] offset:0 \x00\x1D\x00\x17\x00\x18 offset:0x6e
[2:59:08 pm] <+ggus> cohosh: shelikhoo: ^
```
```
[3:30:38 pm] <shelikhoo> blocked: is there any context...```
[2:46:20 pm] <blocked> Signature used by ru to block snowflake: \x16\xFE[\xFD\xFF] offset:0 \x00\x1D\x00\x17\x00\x18 offset:0x6e
[2:59:08 pm] <+ggus> cohosh: shelikhoo: ^
```
```
[3:30:38 pm] <shelikhoo> blocked: is there any context about this signature, like which ISP/network environment this kind block is observed?
[3:37:11 pm] <+armadev> (blocked left the channel)
[3:47:16 pm] <+armadev> cohosh: and dcf even commented on the ticket just now
[3:47:26 pm] <+armadev> (looks like the same signature as 5 months ago, he says)shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40124Move tor-specific event code outside of library2022-07-28T14:38:06ZCecylia BocovichMove tor-specific event code outside of libraryThere was a slight regression of our library goals (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/31) in the fix for https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transpor...There was a slight regression of our library goals (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/31) in the fix for https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40076.
The goal of separating out the client and server libraries were to:
- implement v2 of the pluggable transports Go API
- allow non-Tor programs to run Snowflake
The cleanest way to do this is the separate the Tor-specific code into the main program that calls the library. Right now there are calls to the tor pt v1 specification in `pt_event_logger.go` inside the client library that will attempt to send log messages to a tor process if used. I'd like to just move this file out of the library. Should be a simple fix.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40122Set up a second snowflake bridge site2023-01-08T18:03:25ZDavid Fifielddcf@torproject.orgSet up a second snowflake bridge siteAt #28651, the plan is to run more than one snowflake bridge site. Each bridge site will have one instance of snowflake-server, speaking to a group of tor instances that all have the same identity keys. The identity keys in different bri...At #28651, the plan is to run more than one snowflake bridge site. Each bridge site will have one instance of snowflake-server, speaking to a group of tor instances that all have the same identity keys. The identity keys in different bridge sites will be different. Until now, we have had only one bridge site, and have kept the tor identity keys the same through server migrations (#40091, #40095, #40110, #40111). This issue is to set up a second bridge site, with its own, independent identity keys.
- [x] get access to the server hardware
- [x] decide on a bridge nickname
- [x] install bridge software ([installation guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide))
- [x] set up user accounts https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40091#note_2768855
- [x] point a domain name at the server https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28651#note_2787394
- [x] disable plain SSH access
/cc @shelikhooDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/102Serge tor restart means no bridges marked Running for 30"2022-05-16T16:49:19ZGeorgeSerge tor restart means no bridges marked Running for 30"frosttall (irc handle) noticed that bridge was marked down on metrics.tpo earlier. Serge had restart (not HUP/reload) around the same time as reported issue:
Mar 23 20:44:20.000 [notice] Clean shutdown finished. Exiting.
Mar 23 20:44:23...frosttall (irc handle) noticed that bridge was marked down on metrics.tpo earlier. Serge had restart (not HUP/reload) around the same time as reported issue:
Mar 23 20:44:20.000 [notice] Clean shutdown finished. Exiting.
Mar 23 20:44:23.000 [notice] Tor 0.4.6.10 opening log file.
The ultimate conclusion was that Serge takes 30" before voting again on running bridges.
arma pointed this code snippet out:
feature/dirauth/dirauth_options.inc:CONF_VAR(TestingAuthDirTimeToLearnReachability, INTERVAL, 0, "30 minutes")
Apparently, this has been going on for a while, most recently
20220207-002949 20220208-195458 20220205-204058 20220205-175303 20220206-044751 are also times when there was no consensus/"all bridges down" as per Serge reporting. It was reported by trinity that there were examples in 2020,2021. Again, very strange that none of us noticed that there were no reported running bridges.
The issue came up recently, and I thought someone on the bridgedb end handled. There were no formal 'outages' on Serge since the IPv6 routing issues a month ago, and didn't connect the outages with tor restarting.
A workaround arma mentioned was ignoring Serge's reporting if no bridges are marked Running.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/rdsys/-/issues/97shorten the period to get fresh bridges in circumvention settings2023-09-11T15:36:19Zmeskiomeskio@torproject.orgshorten the period to get fresh bridges in circumvention settingsAt !30 I implemented (from the [doc I wrote](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/0d4729347c11bb476fcb41eaff47d50241a7567a/doc/moat.md)):
> The resources provided /circumvention/settings and /circumvention/defa...At !30 I implemented (from the [doc I wrote](https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/0d4729347c11bb476fcb41eaff47d50241a7567a/doc/moat.md)):
> The resources provided /circumvention/settings and /circumvention/defaults use a combination of two mechanisms to make it harder for attackers to list all the bridges.
>
> Resources are group so each resource will only be distributed in a certain time period (rotation_period_hours), and will not be distributed again until a number of periods has past (num_periods). If rotation_period_hours=24 and num_periods=30 resources will be divided in 30 groups and each group will be distributed during one day and so a single resource will not be distributed again 30 days has passed.
>
> The IP address of the requester will be used so over the same rotation period every IP coming from the same subnet will get the same resources on each request.
I have some doubts about that mechanism. I'm thinking on setting `rotation_period_hours=24`. So if the bridges that a user gets don't work they need to wait for a day to be able to request new bridges, might that be too long? Might we want to add another rotation period for the IP subnet, something like the current MOAT_ROTATION_PERIOD=3h, so from the same bridge group a single subnet can get different bridges each 3 hours. Or will that just complicate the mechanism without adding much?
I'm using the same subnet definition that [BridgeDB](https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/blob/9f739738fe1eed32933a9fa0165b0835907280e2/bridgedb/distributors/https/distributor.py#L110), /16 for IPv4 and /32 for IPv6. Specifically for IPv4 I guess many countries will not have so many subnets, which means that most users in a country requesting bridges in a single rotation period will get to few bridges. Is that concern real? The second rotation period would help here as well, or we could reduce the subnets (to /24 for IPv4).
(from https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/79#note_2788654)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/bridgedb/-/issues/40048Serge tor restart means no bridges marked Running for 30"2022-03-29T18:26:57ZGeorgeSerge tor restart means no bridges marked Running for 30"frosttall (irc handle) noticed that bridge was marked down on metrics.tpo earlier. Serge had restart (not HUP/reload) around the same time as reported issue:
Mar 23 20:44:20.000 [notice] Clean shutdown finished. Exiting.
Mar 23 20:44:23...frosttall (irc handle) noticed that bridge was marked down on metrics.tpo earlier. Serge had restart (not HUP/reload) around the same time as reported issue:
Mar 23 20:44:20.000 [notice] Clean shutdown finished. Exiting.
Mar 23 20:44:23.000 [notice] Tor 0.4.6.10 opening log file.
The ultimate conclusion was that Serge takes 30" before voting again on running bridges.
arma pointed this code snippet out:
feature/dirauth/dirauth_options.inc:CONF_VAR(TestingAuthDirTimeToLearnReachability, INTERVAL, 0, "30 minutes")
Apparently, this has been going on for a while, most recently
20220207-002949 20220208-195458 20220205-204058 20220205-175303 20220206-044751 are also times when there was no consensus/"all bridges down" as per Serge reporting. It was reported by trinity that there were examples in 2020,2021. Again, very strange that none of us noticed that there were no reported running bridges.
The issue came up recently, and I thought someone on the bridgedb end handled. There were no formal 'outages' on Serge since the IPv6 routing issues a month ago, and didn't connect the outages with tor restarting.
A workaround arma mentioned was ignoring Serge's reporting if no bridges are marked Running.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/95telegram l10n support2023-08-23T18:59:04Zmeskiomeskio@torproject.orgtelegram l10n supportIs l10n support possible? how does this work?Is l10n support possible? how does this work?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/40110Move bridge to an interim faster server2022-05-17T00:24:17ZDavid Fifielddcf@torproject.orgMove bridge to an interim faster serverBackground: [\[tor-project\] More resources required for Snowflake bridge](https://forum.torproject.net/t/tor-project-more-resources-required-for-snowflake-bridge/2353)
I have or have been offered access to a faster server for the snowf...Background: [\[tor-project\] More resources required for Snowflake bridge](https://forum.torproject.net/t/tor-project-more-resources-required-for-snowflake-bridge/2353)
I have or have been offered access to a faster server for the snowflake bridge. I anticipate being able to change DNS and start using the faster server on Wednesday, 2022-03-16.
The current situation is: I have control right now of a suitable *paid* server, and I have an offer of a suitable *free* server that I am supposed to get control of on Tuesday, 2022-03-15. I will prefer to switch to the free server, but if there are any unforeseen problems with that deal, the paid server will be ready as a backup.
I expect to have to move the bridge *again*, to a more permanent home, but not before 2022-03-21 (#40111). The purpose of the migration in this ticket is to improve service until that other server is ready, and to mitigate any possible delays.
- [x] install new bridge ([installation guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide)), try 8 tor instances to start
- [x] copy user accounts https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40091#note_2768855
- [x] copy identity and onion keys from existing bridge
- [x] copy HTTPS TLS keys and certificates from existing bridge
- [x] test tor bootstrap on new bridge using local broker and proxy, and /etc/hosts domain name record https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40095#note_2773365
- [x] make DNS for snowflake.torproject.net point to the new bridge tpo/tpa/team#40664
- [x] monitor for a day, be ready to switch DNS back if connections fail
Cc @artDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40108standalone snowflake operators want a way to bind a specific outbound address2023-05-06T12:48:00ZRoger Dingledinestandalone snowflake operators want a way to bind a specific outbound addressThis is similar to Tor's ```OutboundBindAddress``` config option: if you're running headless snowflake on a server with multiple IP addresses, you want a way to control which IP address your outgoing connections will come from.
Tricks c...This is similar to Tor's ```OutboundBindAddress``` config option: if you're running headless snowflake on a server with multiple IP addresses, you want a way to control which IP address your outgoing connections will come from.
Tricks can be done with routing and iptables and etc, but those are OS-specific, require messing with stuff at the root level, etc. Maybe it is a two-line patch to let snowflake call bind() on the outbound connection socket?itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/72Moat process unexpected quit issue2022-09-23T20:04:10ZshelikhooMoat process unexpected quit issueLast Saturday(March 5, 2022) there is a failure observed at the moat service. The root cause of service failure is due to the unexpected quit of the moat process. @arma restored the service by restarting the moat process. However, the ro...Last Saturday(March 5, 2022) there is a failure observed at the moat service. The root cause of service failure is due to the unexpected quit of the moat process. @arma restored the service by restarting the moat process. However, the root cause of the issue is still present.
To solve this issue we have created the following roadmap:
1. Setup an automatic restart procedure like systemd to restart moat automatically when it fails
2. Setup a log collection system to capture the diagnostic output
3. redact the log file to hide the user IP address
4. Try to fix the root cause of service crashing by analyzing the diagnostic output
The relevant IRC log is as follows:
```
<n8fr8[m]> not sure where the right channel to report this, but the moat service endpoint seems to be down. can't request a bridge in TB, Orbot, OnionBrowser, etc.
<lavamind> n8fr8[m]: thanks for the heads up, usually a good place to start is #tor of forum.torproject.net
<lavamind> or*
<n8fr8[m]> well... a key part of our anti-censorship services for users in places like Russia where tor is blocked is down, and you want me to post it to the general tor forum on a message board? I suppose I will send an email to the right people instead
<lavamind> well I know there was an upgrade to bridgedb done this week, so I've poked a member of the anticensorship team responsible for it
<lavamind> I've looked at the system and couldn't find anything obviously wrong
<n8fr8[m]> thanks for checking!
<n8fr8[m]> could be something with fastly front domain, hopefully temporary
<n8fr8[m]> I am getting a TLS cert error on https://moat.torproject.org.global.prod.fastly.net/
<lavamind> oh nice catch
<lavamind> well we definitely dont generate those certificates :p
<lavamind> so yeah, maybe an issue on Fastly's end
<+armadev> n8fr8[m]: i think i might have fixed moat
<+armadev> if somebody wants to verify, please do :)
<shelikhoo> I think moat is recovered.... how did armadev fix it?
<+armadev> shelikhoo: the moat fix was 'sudo -u moat /srv/bridges.torproject.org/bin/run-moat-shim'
<+armadev> as specified in https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Moat-Survival-Guide
<+armadev> (and i had said this in #tpo-admin but i guess not in more detail here too)
<+armadev> shelikhoo: the bigger issue though is: that moat-shim thing has died at least twice now, mysteriously, for no reason
<+armadev> so somebody should debug it, set up monitoring for when it disappears, etc
<shelikhoow> Yes, so I think a systemd based solution that restart it automatically will work....
<+armadev> can you open a ticket somewhere?
<shelikhoow> Yes, consider it done.
<+armadev> i agree that using systemd to auto restart it is a good first step
<+armadev> there is definitely also a part of me that wants to know why it exits though :)
<+armadev> thanks!
<shelikhoo> That means we need to investigate the log....
<+armadev> yep. the log is full of tls complaints and ip addresses,
<+armadev> but i think the log only goes to stdout
<+armadev> i.e. when you log out from running run-moat-shim, the log now goes nowhere
<shelikhoo> Yes... If we setup a systemd based deployment, we can configure it to store the log from stdout,err
<+armadev> great. so, step one, switch to systemd and start logging stuff somewhere,
<shelikhoo> Systemd have its issues, but it is quite convenient
<shelikhoo> Yes.
<+armadev> then step two, when it dies, see if it said anything useful
<shelikhoo> The effort to do so will be tracked in the issue.
<shelikhoo> Yes
<+armadev> step one-point-five, notice that the log has a bunch of ip addresses in it and wonder if that is urgent enough to fix
<shelikhoo> Yes. I don't think it is urgent but we should fix it....
<+armadev> great
```meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40106proxy-go support for IGD2024-02-20T07:58:00ZJillproxy-go support for IGDI tried using the proxy-go in two setup, one on a laptop behind NAT, the other on a server with its own restrictive firewall.
In both cases the NAT type was detected as "restricted". My understanding is that at most one end of the conne...I tried using the proxy-go in two setup, one on a laptop behind NAT, the other on a server with its own restrictive firewall.
In both cases the NAT type was detected as "restricted". My understanding is that at most one end of the connection can be restricted,
so a restricted proxy can't talk to a restricted client. Getting an unrestricted NAT is better as it's compatible with more clients.
To that effect, proxy-go could use [IGD](https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protocol) to ask the NAT to create a dynamic
port forwarding so it is effectively unrestricted. This would help with the laptop situation (assuming the router doing NAT supports IGD,
which mine does), and using something like [miniupnp](https://miniupnp.tuxfamily.org/), it would also be possible to dynamically open ports
on a local, restrictive, firewall.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40047getting bridges through google docs2023-09-28T14:48:34Ztrinity-1686agetting bridges through google docsI'm not sure this is the right repository to open this ticket, feel free to move it elsewhere if appropriate
I stumbled on [a short blog post](https://web.archive.org/web/20230330055859/https://easrng.blogspot.com/2022/03/get-tor-bridge...I'm not sure this is the right repository to open this ticket, feel free to move it elsewhere if appropriate
I stumbled on [a short blog post](https://web.archive.org/web/20230330055859/https://easrng.blogspot.com/2022/03/get-tor-bridges-with-nothing-but.html) about an interesting way to query BridgeDB, routing requests through Google Docs.
The general idea is to load this payload:
```
data:text/html,<script>google={visualization:{Query:{setResponse:o=>document.write(atob(o.table.rows.map(e=>e.c[0].v).join("")))}}}</script><script src="https://docs.google.com/spreadsheets/d/1SOK9rEPrVLId1NR4KM-mgDO7tlmRk2K5nNi0tv-9gCY/gviz/tq?tqx=out:json"></script>
```
Which loads an entire html document from cells of a Google Sheet. When clicking a button on this page, it submits a Google Form,
which supposedly trigger some processing somewhere. The page then query an other Google Sheet until a new line appear, which
contains a BridgeDB captcha.
The user is prompted to resolve this captcha. This submits a second Google Form, triggering yet again some processing somewhere.
It then poll the same Google Sheet for a new line, which contains 3 bridge lines.
In short, the client doesn't connect to anything but `docs.google.com`, which is used as a (very slow) communication tunnel to some server,
which itself query BridgeDB, coming from a payload small enough to fit in a QR-code.
To implement something like this (for something else than GDocs), it's required to have:
- some place to store the full webpage (a first Google Sheet for this implementation)
- some (possibly low bandwidth high latency) channel for the user to request a captcha and send its answer (public writes, possibly private read, Google Form for this implementation)
- some (possibly low bandwidth high latency) channel for the user to receive the captcha and bridge lines (private writes, public reads, a second Google Sheet for this implementation)
Blocking such a way to query BridgeDB can have high collateral effect a censor might not be ready to accepthttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/69Prepare for s28 site visit: March 25 20222022-03-29T01:45:45ZRoger DingledinePrepare for s28 site visit: March 25 2022Very similar to https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62: "We've got to make slides, wrap up any ongoing work that we want to report, and coordinate with the rest of our group about what our story/goals are."
I...Very similar to https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62: "We've got to make slides, wrap up any ongoing work that we want to report, and coordinate with the rest of our group about what our story/goals are."
In particular, the set of topics I want to learn about ("what did we make progress on") is the same set as listed in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/62#note_2775653
Since the actual presentation is on March 25, it would be good to have things gathered some days earlier, e.g. by March 20 latest.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Roger DingledineRoger Dingledine2022-03-21https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/86gettor - Create alias "macos"2022-06-23T14:43:09ZGusgettor - Create alias "macos"We got this feedback:
> It seems that the instruction (https://support.torproject.org/censorship/gettor-2/) lists the macOS as macOS, while the email service requires "osx" string to be present
> for the valid instructions to be returne...We got this feedback:
> It seems that the instruction (https://support.torproject.org/censorship/gettor-2/) lists the macOS as macOS, while the email service requires "osx" string to be present
> for the valid instructions to be returned.
>
> Consider making an alias from "macos" to "osx" so that the users won't be confused.
-----
If that is not possible, I will fix the main support documentation.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/team/-/issues/62Prepare for s28 PI meeting: May 10 20222022-09-01T23:42:21ZCecylia BocovichPrepare for s28 PI meeting: May 10 2022We've got to make slides, wrap up any ongoing work that we want to report, and coordinate with the rest of our group about what our story/goals are.
We should gather the information we need some days before May 11 (say, by May 5 latest)...We've got to make slides, wrap up any ongoing work that we want to report, and coordinate with the rest of our group about what our story/goals are.
We should gather the information we need some days before May 11 (say, by May 5 latest), so there is enough time to organize it into a coherent presentation and enough time to notice missing things (e.g. graphs and diagrams) and collect them too.Sponsor 28: ONLY PHASE 3 Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)2022-05-11https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/53add a third pool to the telegram bot2022-01-24T11:22:12Zmeskiomeskio@torproject.orgadd a third pool to the telegram botThe new pool is the only one that gets bridges blocked, the mechanism of splitting the bridges depending of the age of the account works. But the new pool is getting many requests that might get bridges that are already blocked. I have t...The new pool is the only one that gets bridges blocked, the mechanism of splitting the bridges depending of the age of the account works. But the new pool is getting many requests that might get bridges that are already blocked. I have the feeling that the minimum age required is too high. Lets divide it in two by age of the accounts and see if the censor is still only blocking the newest one and if we can keep more users in the pools that are not being blocked.Sponsor 125: Rapid Response Fund for Russia censorship circumventionmeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40091Set up a Snowflake bridge staging server2022-04-06T05:00:23ZDavid Fifielddcf@torproject.orgSet up a Snowflake bridge staging serverThe goals of this issue are:
1. Share practical experience setting up a snowflake bridge.
2. Write a [Snowflake Bridge Installation Guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-I...The goals of this issue are:
1. Share practical experience setting up a snowflake bridge.
2. Write a [Snowflake Bridge Installation Guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide), like the existing [Snowflake Broker Installation Guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Broker-Installation-Guide).
3. Install an [experimental load balancing configuration](https://lists.torproject.org/pipermail/tor-relays/2022-January/020183.html) in an attempt to increase the capacity of the bridge.
If the load balancing configuration works, we can then apply it to the production bridge. (Or change DNS so as to swap production and staging.)
We talked about scaling the snowflake bridge and load balancing ideas at the [2022-01-06 team meeting](http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-01-06-15.59.html).
<details>
<summary>Meeting notes</summary>
* Scaling Snowflake bridge
* Already increased from 4 to 8 CPUs
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40085
* We should profile snowflake-server to reduce its CPU use
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40086
* But dcf feels that the bottleneck is not the snowflake-server process (which is multithreaded and can use multiple CPU cores), but the tor process (which can only use 1 CPU core and is already constantly at 100%). See https://lists.torproject.org/pipermail/tor-relays/2021-December/020156.html
* It turns out that it is possible to run multiple instances of tor with the same identity keys (hence the same fingerprint), either on the same host or on different hosts: https://lists.torproject.org/pipermail/tor-relays/2021-December/020157.html. Multiple instances of tor is a way of scaling tor beyond 1 CPU core, with snowflake-server distributing traffic over the available instances: https://lists.torproject.org/pipermail/tor-relays/2021-December/020182.html
* With another shim (similar to moat-shim) you can keep ExtORPort metrics reporting in the load-balanced configuration:
* https://gitlab.torproject.org/dcf/extor-static-cookie
* https://lists.torproject.org/pipermail/tor-relays/2022-January/020183.html
* Though I'm not sure, if Metrics gets multiple descriptors per day with the same fingerprint, whether it will sum all of them, or only keep one of them
* dcf has a bridge running now (with obfs4proxy, not snowflake-server) with this extor-static-cookie + load balancing configuration
* https://metrics.torproject.org/rs.html#details/07B9C6D7BE9685E83FA8C7A4FEB34CAD6CB77503
* Though I have not tested Roger's caveat about DEFAULT_ONION_KEY_LIFETIME_DAYS yet https://lists.torproject.org/pipermail/tor-relays/2022-January/020196.html
* We could apply this same thing to the snowflake bridge. But it is kind of a big configuration change: we need to stop snowflake-server being managed by tor, and instead run it independently (i.e., using runit or systemd) and have it talk to the tor instances' static ExtORPorts through a load balancer. It would be best to do this on a staging server separate from production first.
* we tentatively plan to do this next tuesday, 2022-01-11. dcf will be in touch and have a host ready for installation.
* Once the tor bottleneck is removed, though, we are not too far from the next likely bottleneck, which is total CPU of the host, shared between tor and snowflake-server. It might be time to think about migrating to different hosting for the snowflake bridge. Or we can experiment with running snowflake-server on one host, and N instances of tor on another (preferably nearby) host.
</details>Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40087Let's Encrypt "DST Root X3" root expiration affects old Android clients acces...2024-01-22T16:33:10ZcybertaLet's Encrypt "DST Root X3" root expiration affects old Android clients accessing brokerRunning Snowflake with the default config mentioned in this repository and shown below Snowflake fails to create a connection on some Android devices (apparently older Android versions, I could reproduce that issue using Android 4 and An...Running Snowflake with the default config mentioned in this repository and shown below Snowflake fails to create a connection on some Android devices (apparently older Android versions, I could reproduce that issue using Android 4 and Android 6 on a real device and on an emulator).
The error log tells me the cause of the connection failure is an expired certificate.
`WebRTC: x509: certificate has expired or is not yet valid: current time 2021-12-28T16:12:58Z is after 2021-09-30T14:01:15Z Retrying... `
Default config, I'm referring to:
```
snowflake-target https://snowflake-broker.torproject.net.global.prod.fastly.net/
snowflake-front cdn.sstatic.net
```
Using a different broker and domain-fronting I can work around the issue (config taken from https://github.com/cohosh/snowflake)
Could you please have a look at the broker / domain fronting setup or adapt the documentation here?Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40080Document Snowflake's FreeBSD Package/Port2021-12-06T15:44:03ZVinÃcius ZavamDocument Snowflake's FreeBSD Package/Portwe just introduced Snowflake to the [FreeBSD](https://www.freebsd.org/)'s ports tree:
* **https://cgit.freebsd.org/ports/commit/?id=057c0c3c0645c0b237bb2a96dda440e0426ca983**
today version **[v2.0.1](ead5a960d7fa19dc890ccbfc0765c5ab662...we just introduced Snowflake to the [FreeBSD](https://www.freebsd.org/)'s ports tree:
* **https://cgit.freebsd.org/ports/commit/?id=057c0c3c0645c0b237bb2a96dda440e0426ca983**
today version **[v2.0.1](ead5a960d7fa19dc890ccbfc0765c5ab6629eaa9)** was ported to the ports collection, used to build official packages for FreeBSD. now we should have [official packages](https://pkg.freebsd.org/) available to install Snowflake ]=)
there are 3 different binaries shipping with its package:
```
snowflake
snowflake-client
snowflake-proxy
```
FreeBSD uses `pkg` as its official/main packages manager. it provides an interface for manipulating packages: registering, adding, removing and upgrading packages. after installing a package, we can be presented a message containing few notes about a particular software.
we worked out to present intuitive instructions to setup following scenarios:
- standalone proxy;
- client transport plugin,
- server transport plugin.
besides Snowflake's source code and its documentations, the following material was used to build the port:
> https://gitlab.torproject.org/tpo/core/tor/-/issues/21453
>
> https://gitlab.torproject.org/tpo/core/tor/-/issues/24203
on top of that, the [Snowflake Bridge Survival Guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Survival-Guide) was also pretty handy
by running the standalone proxy on FreeBSD, this would be an output of its log file:
```
2021/11/14 21:50:20 starting
ice ERROR: 2021/11/14 21:50:20 Failed to enable mDNS, continuing in mDNS disabled mode: (listen udp4 224.0.0.0:5353: bind: address already in use)
2021/11/14 21:50:20 WebRTC: Created offer
2021/11/14 21:50:20 WebRTC: Set local description
2021/11/14 21:50:22 Offer: {" ~scrubbed~ "}
2021/11/14 21:50:54 NAT type: restricted
ice ERROR: 2021/11/14 21:53:37 Failed to enable mDNS, continuing in mDNS disabled mode: (listen udp4 224.0.0.0:5353: bind: address already in use)
2021/11/14 21:53:37 sdp offer successfully received.
2021/11/14 21:53:37 Generating answer...
2021/11/14 21:53:38 OnDataChannel
2021/11/14 21:53:38 Connection successful.
2021/11/14 21:53:38 OnOpen channel
2021/11/14 21:53:39 connected to relay
2021/11/14 21:54:22 OnClose channel
2021/11/14 21:54:22 Traffic throughput (up|down): 574 KB|67 KB -- (249 OnMessages, 575 Sends, over 43 seconds)
2021/11/14 21:54:22 copy loop ended
2021/11/14 21:54:22 datachannelHandler ends
```
_there will be packages for different versions and architectures available._ should anyone wants to test it right away (once the package is available):
```
# pkg update -f
# pkg install -U snowflake-tor
# service snowflake onestart
```Cecylia BocovichCecylia Bocovich