Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2023-08-01T19:29:39Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/20813Start producing snowflakes2023-08-01T19:29:39ZArlo BreaultStart producing snowflakesOnce `snowflake-client` gets in the alpha Tor Browser builds (tpo/applications/tor-browser#20735), we're going to have some unhappy users if we don't have a sufficient number of proxies available.
We should start ramping up production a...Once `snowflake-client` gets in the alpha Tor Browser builds (tpo/applications/tor-browser#20735), we're going to have some unhappy users if we don't have a sufficient number of proxies available.
We should start ramping up production asap.
Some ideas in,<br>
https://github.com/glamrock/cupcake<br>
https://github.com/keroserene/snowflake/issues/30
We probably also want to close out the opt-in issue,<br>
https://github.com/keroserene/snowflake/issues/21Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/23888Creating a Snowflake WebExtension addon2023-08-01T19:29:39ZTracCreating a Snowflake WebExtension addonThe idea is to create a WebExtension that allows one to become a Snowflake bridge by just installing it. That way it only suffices to install an extension and forget about it, unlike the approach of keeping a tab always open with the sno...The idea is to create a WebExtension that allows one to become a Snowflake bridge by just installing it. That way it only suffices to install an extension and forget about it, unlike the approach of keeping a tab always open with the snowflake JS code.
Since it's based on WebExtensions it can be easily deployed for other browsers in their addon store.
I did try to make one myself but I don't have the expertise and time to debug all the problems that resulted. One of the important take aways that I learned in that process was that automatically loading scripts from external sites is prohibited and will result in the addon not passing the review in the addon store, so the `snowflake.js` and `modernizr.js` should be embedded with the addon. However, this would require modifying `snowflake.js` since when it's loaded locally it throws some typeError and doesn't show that there's some connection to snowflake.bamsoftware.com in the browser console. For debugging, to verify that the addon works as intended one may load it from `about:debug` and check `about:networking` in the DNS and WebSockets part.
For the implementation these resources should be loaded in the background to ensure a permanent state with this in the `manifest.json`,
```
"background": {
"page": "pages/Snowflake.html"
},
```
**Trac**:
**Username**: oarelSponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25429Need something better than client's `checkForStaleness`2023-08-01T23:54:09ZArlo BreaultNeed something better than client's `checkForStaleness`If no message has been received on the datachannel on the client for `SnowflakeTimeout` (30 seconds), `checkForStaleness` closes the connection. The comment says this is to,
> // Prevent long-lived broken remotes.
but there's no hear...If no message has been received on the datachannel on the client for `SnowflakeTimeout` (30 seconds), `checkForStaleness` closes the connection. The comment says this is to,
> // Prevent long-lived broken remotes.
but there's no heartbeat at this level of abstraction so the connection is constantly being reset anytime the user pauses their activity (for example, to read a webpage).
This greatly exacerbated legacy/trac#21312Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25483Windows reproducible build of snowflake2023-08-01T23:45:54ZArlo BreaultWindows reproducible build of snowflakeBreaking this out from https://trac.torproject.org/projects/tor/ticket/19001#comment:36, where dcf wrote,
> I pushed some preliminary code for getting started with a windows reproducible build.
> https://gitweb.torproject.org/user/dcf...Breaking this out from https://trac.torproject.org/projects/tor/ticket/19001#comment:36, where dcf wrote,
> I pushed some preliminary code for getting started with a windows reproducible build.
> https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/log/?h=snowflake-windows&id=0f48dc9e1904fa0643576fc8dcf3db50a4d2f959
>
> It doesn't work yet; after `./mkbundle-windows.sh versions.alpha`, it eventually fails with:
> {{{
> + /home/ubuntu/build/webrtc/src/out_bootstrap/gn gen out/Release '--args= target_os="win" target_cpu="x86" is_debug=false treat_warnings_as_errors=false is_component_build=false is_clang=true use_sysroot=false clang_use_chrome_plugins=false clang_base_path="/home/ubuntu/build/clang" rtc_include_opus=false rtc_include_ilbc=false rtc_include_internal_audio_device=false rtc_include_tests=true'
> ERROR at //build/config/BUILDCONFIG.gn:239:3: Assertion failed.
> assert(target_os == host_os, "Win cross-compiles only work on win hosts.")
> ^-----
> Win cross-compiles only work on win hosts.
> }}}
> But at this point one can ssh into the build VM and start debugging the build failures.
Some further notes from what we've discovered so far.
* https://chromium.googlesource.com/chromium/src/+/master/docs/win_cross.md says that we need to add `target_os = ['win']` to our `.gclient` file before calling `gclient sync` to get some additional deps.
* https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/master/win_toolchain/README.md says that Googlers have access to the necessary toolchain, but we don't.
* https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/master/win_toolchain/package_from_installed.py points to a method of creating it from a fresh VM. Presumably we can use https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ and the community version of Visual Studio (steps to reproduce will follow)Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/27385https://snowflake.torproject.org/embed is confusing2022-07-09T04:20:15Zcypherpunkshttps://snowflake.torproject.org/embed is confusing`embed.html` should be the go to for embedding snowflake badges in webpages but it currently has a couple of problems,
1. No description, nothing to suggest to the lambda visitor about what to do.
2. Clicking on the badge redirects to ...`embed.html` should be the go to for embedding snowflake badges in webpages but it currently has a couple of problems,
1. No description, nothing to suggest to the lambda visitor about what to do.
2. Clicking on the badge redirects to the options page hosted in torproject.org, but this means that users who have first-party isolation manually enabled (as can be done in Firefox) won't be able to enable it on the page where embed.html is embedded.
Ideally what should be done is:
1. Small description ("Do you want to help censored users access the Tor network?") with a snowflake logo.
2. If user clicks on yes, then in that same iframe there's some JS check to see if WebRTC is disabled, if it is inform the user that WebRTC is necessary and perhaps add a link on how to enable it back.
3. If WebRTC is enabled, then load up snowflake.js and modernizr.js. Description should contain if the connection to the broker is done and is waiting for a client request, and if it is then maybe the logo should change as well as the description. (Since everything is done on the same page then there won't be any problems with first party isolation -- except with 3rd party cookies disabled)
Ideally it should be easy to embed into webpages if what's above is done, and should be small enough.
(cc'ing antonela of the ux-team for her opinions :)Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28942Evaluate pion WebRTC2023-08-01T23:47:27ZTracEvaluate pion WebRTCWe've made a pure Go WebRTC port over at [pions/webrtc](https://github.com/pions/webrtc). This may provide a viable alternative to libwebrtc.
_Disadvantages_
- We've not done much work on security yet. However, we definitely intend to w...We've made a pure Go WebRTC port over at [pions/webrtc](https://github.com/pions/webrtc). This may provide a viable alternative to libwebrtc.
_Disadvantages_
- We've not done much work on security yet. However, we definitely intend to work on this since hardening the security will be a requirement for many other use-cases.
- Not entirely feature complete but this seems less important for your use-case.
- We don't support TURN yet. We currently plan to build this for our next release.
_Advantages_
- It is fully go-gettable, fixing the horrible built process. In addition, it should run everywhere Go runs.
- We've tested our data channel implementation against multiple targets, including Chrome, Firefox and NodeJS and aim to automate these in the future.
- It will give you more freedom to make changes to the WebRTC stack and even allow experimentation, E.g.: to reduce fingerprinting.
- It may solve/invalidate some of your other problems, including #19026, #19315, #19569, #22718 and #25483.
- We're working on exposing an idiomatic API based on the io.ReadWriteCloser.
- We have an active community and development team. We're more than happy to fix any problems that may arise. We're also open to prioritizing any features you conciser blocking. Lastly, we have great PR response times.
I'm also interested in collaborating on NAT testing as mentioned in #25595.
**Trac**:
**Username**: backkemSponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29206New design for client -- server protocol for Snowflake2023-08-01T23:54:09ZCecylia BocovichNew design for client -- server protocol for SnowflakeRight now we just send traffic. We could add some control messages or another layer for reliability/sequencing.Right now we just send traffic. We could add some control messages or another layer for reliability/sequencing.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29207New design for broker -- proxy protocol for snowflakes2020-07-06T23:50:09ZCecylia BocovichNew design for broker -- proxy protocol for snowflakes This is related to the Snowflake protocol design tickets legacy/trac#29206 and legacy/trac#29293.
We want to write these protocols in a way that is not Snowflake-specific but allows any type of bridge to connect to or poll our broker/B... This is related to the Snowflake protocol design tickets legacy/trac#29206 and legacy/trac#29293.
We want to write these protocols in a way that is not Snowflake-specific but allows any type of bridge to connect to or poll our broker/BridgeDB bridge distribution service.
The idea is that in the beginning we will start with very reliable "bridge" (which could be snowflakes) that perhaps rotate IP addresses every month or so. After that we can collect measurements and move towards more ephemeral "bridges".
Some things to keep in mind are the types of information that the snowflakes give to the broker (such as proxy version/type) to allow for metrics. This information might change so we'll want a flexible and extensible protocol.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29258Provide an IPv6 address for the Snowflake broker2020-07-06T23:50:09ZAlexander Færøyahf@torproject.orgProvide an IPv6 address for the Snowflake brokerWe have a bit of a tendency to forget to test IPv6 solutions properly and in a structured way. We should make sure that IPv6 is working properly with Snowflake.We have a bit of a tendency to forget to test IPv6 solutions properly and in a structured way. We should make sure that IPv6 is working properly with Snowflake.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29259Ensure high test coverage for Snowflake2020-07-06T23:50:08ZAlexander Færøyahf@torproject.orgEnsure high test coverage for SnowflakeWe should aim for high test coverage and proper CI setup for Snowflake as early as possible in the process to ensure that we don't cause regressions or break things "randomly".
Known issues:
- We don't currently have many proxy-go tests...We should aim for high test coverage and proper CI setup for Snowflake as early as possible in the process to ensure that we don't cause regressions or break things "randomly".
Known issues:
- We don't currently have many proxy-go tests.
- Tests in `client/lib/rendezvous.go` rely on specific HTTP response bodies which is prone to change and unnecessarySponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29262Look into the network layer of WebRTC2020-07-06T23:50:09ZAlexander Færøyahf@torproject.orgLook into the network layer of WebRTCWe should build up some knowledge about the network layer of the WebRTC protocol. Particularly around how both DataChannel traffic and later MediaStream traffic looks on the wire for a "normal" WebRTC web application versus how our Snowf...We should build up some knowledge about the network layer of the WebRTC protocol. Particularly around how both DataChannel traffic and later MediaStream traffic looks on the wire for a "normal" WebRTC web application versus how our Snowflake application looks.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29734Broker should receive country stats information from Proxy and Client2021-05-20T19:40:10ZCecylia BocovichBroker should receive country stats information from Proxy and ClientWe can use existing geoip data to collect statistics about where clients are connecting from in order to detect possible blocking events. These should be gathered both from the initial domain-fronted client connection and from the proxie...We can use existing geoip data to collect statistics about where clients are connecting from in order to detect possible blocking events. These should be gathered both from the initial domain-fronted client connection and from the proxies (to be passed to the broker) in order to detect the blocking of individual proxies or the blocking of the WebRTC connections.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30704Plan for snowflake update versioning and backwards compatability2021-05-20T19:38:56ZCecylia BocovichPlan for snowflake update versioning and backwards compatabilityWe have some upcoming changes that will change the way snowflake components talk to each other. We should decide (and possibly on a case-by-case basis) how to handle these updates.
- Do we make sure changes are backwards compatible with ...We have some upcoming changes that will change the way snowflake components talk to each other. We should decide (and possibly on a case-by-case basis) how to handle these updates.
- Do we make sure changes are backwards compatible with clients/proxies that haven't updated yet?
- Should we think about introducing some concept of versioning?
- If we support older versions, how long until we no longer support them?
Some examples of tickets that we'll need to think about this for:
- legacy/trac#25429
- legacy/trac#29206
- legacy/trac#29207
- legacy/trac#25985Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31423Improve building documentation2021-05-20T19:41:13ZTracImprove building documentationIn the snowflake monorepo it isn't clear which project does what.
For example the server-webrtc's readme doesn't specify clearly what it is nor what it does, it also has some config and bash lines without much explanation of why.
It wo...In the snowflake monorepo it isn't clear which project does what.
For example the server-webrtc's readme doesn't specify clearly what it is nor what it does, it also has some config and bash lines without much explanation of why.
It would be useful to be more detailed in this kind of documentation for those interested in running a broker, snowflake/proxy or server.
**Trac**:
**Username**: sernaSponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/30579Add more STUN servers to the default snowflake configuration in Tor Browser2023-08-02T00:02:28ZCecylia BocovichAdd more STUN servers to the default snowflake configuration in Tor BrowserRight now snowflake blocking in China is happening in the client's connection to the default STUN server (which is set to Google's STUN servers). We should add more STUN servers, including ones that are popular in regions that are trying...Right now snowflake blocking in China is happening in the client's connection to the default STUN server (which is set to Google's STUN servers). We should add more STUN servers, including ones that are popular in regions that are trying to block snowflake so that blocking this stage causes more collateral damage.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/34080Avoid double delays from ReconnectTimeout2022-07-09T04:20:16ZDavid Fifielddcf@torproject.orgAvoid double delays from ReconnectTimeout[ReconnectTimeout](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/lib/snowflake.go?id=72cfb96edeb7c9a3c93d38539bc31a51e30dbe8d#n18) is used in 2 places:
* In [exchangeSDP](https://gitweb.torproject.org/plug...[ReconnectTimeout](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/lib/snowflake.go?id=72cfb96edeb7c9a3c93d38539bc31a51e30dbe8d#n18) is used in 2 places:
* In [exchangeSDP](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/lib/webrtc.go?id=72cfb96edeb7c9a3c93d38539bc31a51e30dbe8d#n223), where it is a delay inserted between calls to `broker.Negotiate` until one of them succeeds.
`Failed to retrieve answer. Retrying in 10s`
* In the main [ConnectLoop](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/snowflake.go?id=72cfb96edeb7c9a3c93d38539bc31a51e30dbe8d#n27), where it is a delay inserted between every check for getting a new snowflake.
```
WebRTC: <errmsg> Retrying in 10s...
```
The broker itself also terminates requests after 10s when the chosen proxy doesn't respond: `BrokerChannel Response: 504 Gateway Timeout`.
This situation sometimes results in double delays. Here are two cases I've identified.
* The client requests a proxy, the broker responds immediately with an answer, but the proxy doesn't work. After waiting the `DataChannelTimeout` to decide that the proxy doesn't work, the client waits an _additional_ `ReconnectTimeout` in `ConnectLoop`.
Here, I've set `DataChannelTimeout` to 10s. Notice that between `DataChannel created` and `Collecting a new Snowflake` there are 20s (which is `DataChannelTimeout` + `ReconnectTimeout`), when it really should only be 10s.
```
2020/04/30 22:38:29 Received Answer.
2020/04/30 22:38:29 WebRTC: DataChannel created.
2020/04/30 22:38:39 establishDataChannel: timeout waiting for DataChannel.OnOpen
2020/04/30 22:38:39 WebRTC: closing PeerConnection
2020/04/30 22:38:39 WebRTC: Closing
2020/04/30 22:38:39 WebRTC: WebRTC: Could not establish DataChannel Retrying in 10s...
2020/04/30 22:38:49 WebRTC: Collecting a new Snowflake. Currently at [0/1]
```
* The client requests a proxy, and the broker waits for 10s to respond with a 504 Gateway Timeout (indicating that the chosen proxy did not return an answer to the broker in time). The client waits 10s for the broker to respond, then waits another `ReconnectTimeout` in exchangeSDP before trying the broker again.
```
2020/04/30 22:39:30 Negotiating via BrokerChannel...
2020/04/30 22:39:41 BrokerChannel Response: 504 Gateway Timeout
2020/04/30 22:39:41 BrokerChannel Error: Unexpected error, no answer.
2020/04/30 22:39:41 Failed to retrieve answer. Retrying in 10s
2020/04/30 22:39:51 Negotiating via BrokerChannel...
```
Both these cases can probably be fixed by running the timer in parallel with the periodic operation they are rate limiting. That is, instead of
```
for {
operation()
<-time.After(ReconnectTimeout)
}
```
it can be
```
for {
timer := time.After(ReconnectTimeout)
operation()
<-timer
}
```
That way, if the operation itself takes more than 10s, `ReconnectTimeout` doesn't impose any additional delay.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/34129Use STUN to determine NAT behaviour of peers2020-08-12T18:10:24ZCecylia BocovichUse STUN to determine NAT behaviour of peersIn investigating high proxy failure rates at clients (legacy/trac#33666) and the logistics of running our own STUN server (legacy/trac#25591), I came across [RFC5780](https://tools.ietf.org/html/rfc5780), which outlines steps to identify...In investigating high proxy failure rates at clients (legacy/trac#33666) and the logistics of running our own STUN server (legacy/trac#25591), I came across [RFC5780](https://tools.ietf.org/html/rfc5780), which outlines steps to identify NATs with "endpoint independent mapping and filtering".
[Section 4.3](https://tools.ietf.org/html/rfc5780#section-4.3) outlines how a client can use a STUN server with an alternate IP address (returned in the first STUN binding request response) to determine how restrictive their NAT is.
This would be useful to match up clients with snowflake proxies that have compatible NATs. We still have the following questions:
- ~~are there public STUN servers that support this feature?~~
Yes there are several candidates.
- ~~does the pion/stun library we use support this feature for STUN clients?~~
Not yet but we can implement the feature.
- If we're able to implement our own STUN server behind a domain-fronted connection (legacy/trac#25591), how can we implement this functionality?
I see at least one open source STUN server implementation that claims to support this (written in C): https://github.com/coturn/coturnSponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40005Use of http.DefaultTransport can cause the proxy and clients to hang indefini...2020-07-31T14:39:57ZCecylia BocovichUse of http.DefaultTransport can cause the proxy and clients to hang indefinitelyThe [http.DefaultTransport](https://golang.org/pkg/net/http/#RoundTripper) leaves `ResponseHeaderTimeout` unset by default. This means that the proxy and client that use this transport will hang indefinitely if they don't receive a respo...The [http.DefaultTransport](https://golang.org/pkg/net/http/#RoundTripper) leaves `ResponseHeaderTimeout` unset by default. This means that the proxy and client that use this transport will hang indefinitely if they don't receive a response from the broker. This happens rarely in practice, but we've seen it before with #29861. A better thing to do is set a long time out and log an error message if contacting the broker failed.
The timeout for clients should be at least as long as the broker's [ClientTimeout](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/master/broker/broker.go#L31) and likewise the proxies should time out after the broker's [ProxyTimeout](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/master/broker/broker.go#L32) would be triggered.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40008Update snowflake stats to include counts of restricted, unrestricted, and unk...2023-04-10T17:12:58ZCecylia BocovichUpdate snowflake stats to include counts of restricted, unrestricted, and unknown proxiesWe are now keeping proxies in buckets according to their NAT type. In assessing the affectiveness of this and the performance of snowflake for different types of clients, we should record statistics on how many proxies of each NAT type w...We are now keeping proxies in buckets according to their NAT type. In assessing the affectiveness of this and the performance of snowflake for different types of clients, we should record statistics on how many proxies of each NAT type we have.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/32545Perform measurements to concretely understand snowflake throughput and networ...2023-08-01T23:40:00ZCecylia BocovichPerform measurements to concretely understand snowflake throughput and network healthWe know that there are several proxies that don't seem to work once connected (legacy/trac#31960) and that connections are very slow on Windows and possible all platforms (legacy/trac#31971).
It would help to be able to quantify this an...We know that there are several proxies that don't seem to work once connected (legacy/trac#31960) and that connections are very slow on Windows and possible all platforms (legacy/trac#31971).
It would help to be able to quantify this and actively monitor it. There are two things we want to measure: the number of snowflakes that work at all, and the throughput of a sample of snowflakes.
Perhaps something like onionperf can help us out here, but we'll have to see whether onionperf works well with snowflake when we get bad proxies or disconnect.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/32657Investigate Snowflake blocking in China2023-08-02T00:08:33ZCecylia BocovichInvestigate Snowflake blocking in ChinaWe've been receiving updates from amiableclarity2011 about snowflake issues in China for a while now (they first reported the blocking of our default STUN servers a while back).
Recently they have not been able to bootstrap a connection...We've been receiving updates from amiableclarity2011 about snowflake issues in China for a while now (they first reported the blocking of our default STUN servers a while back).
Recently they have not been able to bootstrap a connection at all. I wrote a script for monitoring snowflake health (#32545) to check to see if this is due to the faulty snowflake problem we've been having, and ran these tests from a VPS in China and a VPS in North America. I was expecting to see about half of the snowflake connection attempts to succeed and set a 3 minute time out on circuit construction. However, what I saw was a 90% success rate from North America and a 0% success rate in China.
This almost certainly due to blocking, and as ambleclarity recently confirmed in #32597, not due to the blocking of STUN servers.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40036Implement snowflake as a PT v2 compatible library2022-07-28T14:38:06ZCecylia BocovichImplement snowflake as a PT v2 compatible libraryWe've been talking about moving to the v2 or upcoming v3 PT spec now that core Tor is being rewritten in Rust. We also need something similar to this for our pluggable transport sponsor work and Guardian Project has been asking for somet...We've been talking about moving to the v2 or upcoming v3 PT spec now that core Tor is being rewritten in Rust. We also need something similar to this for our pluggable transport sponsor work and Guardian Project has been asking for something similar (see https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40018). This ticket is for experimenting with how to structure modifications of Snowflake so it can easily be called as a v2 compatible library.
The client is already sort of split into a library and main program, so what I'm thinking is to adapt the existing client library to implement the [v2 Go API](https://github.com/Pluggable-Transports/Pluggable-Transports-spec/blob/master/releases/PTSpecV2.1/Pluggable%20Transport%20Specification%20v2.1%20-%20Go%20Transport%20API.pdf).Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40160Snowflake stops working after large size tests (v2.1.0)2022-11-30T17:16:47ZitchyonionSnowflake stops working after large size tests (v2.1.0)
> Snowflake, after some of the large message size tests, suddenly stopped being able to send/receive. The race app was still running, but starting/stopping the deployment seemed to fix the issue.
Fairly sure this is the culprit: https...
> Snowflake, after some of the large message size tests, suddenly stopped being able to send/receive. The race app was still running, but starting/stopping the deployment seemed to fix the issue.
Fairly sure this is the culprit: https://github.com/RACECAR-GU/plugin/blob/snowflake-rc-2.1.0/source/TA2Plugin.go#L180
```go
func (connection *ta2ConnUnicast) Write(msg []byte) error {
conn, dialErr := connection.ClientFactory.Dial()
if dialErr != nil {
logError("Error Connecting to Send Socket: ", dialErr.Error())
return dialErr
}
// We can't just close this connection right away before it gets a chance to send
//FIXME: This is a kludge
//go func() {
// <-time.After(5 * time.Minute)
// conn.Close()
//}()
// Send Message to Socket
_, writeErr := conn.Write(msg)
if writeErr != nil {
logError("Error Writing Message to Send Socket: ", writeErr.Error())
}
return writeErr
}
```
`connection.ClientFactory.Dial()` is basically the same as defined [here.](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/client/lib/snowflake.go#L157)
Is there an easy way to properly close this `conn` that you can think of? @shelikhoo @meskio
Here's from my previous discussion with @cohosh
```
<cohosh> the reason we can't close the connection when this function terminates is that conn.Write() is not a blocking call here
<cohosh> so that will return before the message is actually written
<cohosh> and in some cases, it takes a few minutes to write the message to the connection'
<cohosh> so if we close the connection before the message has been received by the other side, the message will never be sent
```
```
The best thing to do is implement some higher level connection management/connection caching logic.
So that we're reusing connections when multiple messages are sent to the same destination(s).
```Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29293New Design for client -- broker protocol for Snowflake2021-06-08T14:16:56ZCecylia BocovichNew Design for client -- broker protocol for SnowflakeThis is related to the Snowflake protocol design tickets legacy/trac#29206 and legacy/trac#29207.
We want to write these protocols in a way that is not Snowflake-specific but allows the client to request any type of bridge from our brok...This is related to the Snowflake protocol design tickets legacy/trac#29206 and legacy/trac#29207.
We want to write these protocols in a way that is not Snowflake-specific but allows the client to request any type of bridge from our broker/BridgeDB bridge distribution service.
Some things to keep in mind are that we'd like to give the clients multiple ways to connect to the bridge distributor and should get the necessary information for multiple types of bridges. We also need various ways for identifying or distinguishing clients that will aid our bridge partitioning system (e.g., salmon, hyphae). This could be by supplying email addresses, secrets, etc.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovich