Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2022-10-19T20:40:14Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40111Move bridge to a permanent faster server2022-10-19T20:40:14ZDavid Fifielddcf@torproject.orgMove bridge to a permanent 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 expect to be able to move the snowflake bridge to a more permanen...Background: [\[tor-project\] More resources required for Snowflake bridge](https://forum.torproject.net/t/tor-project-more-resources-required-for-snowflake-bridge/2353)
I expect to be able to move the snowflake bridge to a more permanent home on a faster server after 2022-03-21.
#40110 is to use a *different* faster server in the meantime, until the permanent one is prepared.
- [x] get access to new server hardware
- [x] install new bridge ([installation guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide))
- [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] double check onion keys
```
# md5sum /var/lib/tor-instances/*/keys/secret_onion_key{,_ntor}
f57a05262f65beea15ec05bbeefe404c /var/lib/tor-instances/snowflake1/keys/secret_onion_key
a16c5403d18509c79fa7b863eb66892a /var/lib/tor-instances/snowflake1/keys/secret_onion_key_ntor
```
- [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] test rebooting the server to make sure everything comes back up
- [x] start the tor@snowflake* services
- [x] make DNS for snowflake.torproject.net point to the new bridge tpo/tpa/team#40716
- [x] monitor for a day, be ready to switch DNS back if connections fail
- [x] after a week or so, shut down temporary bridge
Cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@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/40049Move code out of #main to support reuse in lib without patching (IPtProxy)2022-10-18T14:43:22ZtlaMove code out of #main to support reuse in lib without patching (IPtProxy)For Snowflake on mobile, we cannot compile an executable with `gomobile`. Instead `gomobile` only produces libraries.
While the new PluggableTransport 2.0 API is nice in theory, we unfortunately need to satisfy Tor, which needs a PT 1.0...For Snowflake on mobile, we cannot compile an executable with `gomobile`. Instead `gomobile` only produces libraries.
While the new PluggableTransport 2.0 API is nice in theory, we unfortunately need to satisfy Tor, which needs a PT 1.0 interface via SOCKS.
So it's either we copy ~ 900 lines of code from [client/snowflake.go](client/snowflake.go) and [proxy/snowflake.go](proxy/snowflake.go), patch that to our needs and then try to keep up with the changes, or we keep a patchfile around, apply that before builds and keep that up to date.
For the `IPtProxy` library, it would be *awesome* if you could factor as much code as possible into a non-main namespace so we could use it without patching. Note: command line option parsing best stays in the `#main` function.
Please see/[apply](https://github.com/tladesignz/IPtProxy/blob/master/build.sh#L48) our [patchfile](https://github.com/tladesignz/IPtProxy/blob/master/snowflake.patch) to understand, what would be most suitable!https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/33995Move pc.CreateOffer and pc.SetLocalDescription out of a goroutine2020-06-27T13:40:11ZDavid Fifielddcf@torproject.orgMove pc.CreateOffer and pc.SetLocalDescription out of a goroutineThis code was formerly the `OnNegotiationNeeded` handler before the switch on pion (comment:28:ticket:28942). We are blocking on `offerChannel` anyway, so we may as well run these operations synchronously and use a normal error return.This code was formerly the `OnNegotiationNeeded` handler before the switch on pion (comment:28:ticket:28942). We are blocking on `offerChannel` anyway, so we may as well run these operations synchronously and use a normal error return.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/23947Move Snowflake proxy page somewhere devs can write2020-08-06T17:53:12ZDavid Fifielddcf@torproject.orgMove Snowflake proxy page somewhere devs can writeThe Snowflake badge code is hosted at serene's site, https[]()://keroserene.net/snowflake/embed.html. serene is the only one who can modify files there. It would be more convenient to move the code to another web server to which all the ...The Snowflake badge code is hosted at serene's site, https[]()://keroserene.net/snowflake/embed.html. serene is the only one who can modify files there. It would be more convenient to move the code to another web server to which all the developers can push files.
Like in the past we moved the flash proxy files from https[]()://crypto.stanford.edu/flashproxy/ to https[]()://flashproxy.bamsoftware.com/flashproxy/. We could even use the same server for Snowflake (using a Snowflake-related domain name).David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40147Move snowflake-broker to a systemd based setup2023-04-10T19:39:01ZshelikhooMove snowflake-broker to a systemd based setupCurrently snowflake-broker is using a [runit](http://manpages.ubuntu.com/manpages/trusty/man8/sv.8.html) based setup. It is simple and working but has some limitations.
We could consider moving to systemd to enable [auto](https://www.fr...Currently snowflake-broker is using a [runit](http://manpages.ubuntu.com/manpages/trusty/man8/sv.8.html) based setup. It is simple and working but has some limitations.
We could consider moving to systemd to enable [auto](https://www.freedesktop.org/software/systemd/man/systemd.service.html#RuntimeMaxSec=) restart.
Edit: remove incorrect info. Thanks @dcf .https://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/40156Multi-Pool Matching Support In Snowflake2023-03-15T06:56:41ZshelikhooMulti-Pool Matching Support In SnowflakeCurrently, there is only one matching pool for all snowflake proxies. The proxies either enter the pool and match with any clients, or if it is deemed ineligible rejected from the pool. This makes it difficult to serve more than one purp...Currently, there is only one matching pool for all snowflake proxies. The proxies either enter the pool and match with any clients, or if it is deemed ineligible rejected from the pool. This makes it difficult to serve more than one purpose as the client sharing a single pool cannot choose which set of servers it would like to relay traffic to.
To add multi-pool matching support into Snowflake:
- Add multi-pool support in the broker
- Add or expression in the domain matcher(Both Standalone and Browser Extension port)
- Add UI changes to the Browser Extension to support selective participationhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40123Multicast DNS noise2023-02-07T04:10:48ZpseudonymisaTorMulticast DNS noiseFrom Firewall logs, I see ❄️ Snowflake client try to create exactly one connection per every second to the 224.0.0.251:5353 well-known multicast address for multicast Domain Name System (mDNS) from any available interface as source.
Whi...From Firewall logs, I see ❄️ Snowflake client try to create exactly one connection per every second to the 224.0.0.251:5353 well-known multicast address for multicast Domain Name System (mDNS) from any available interface as source.
While searching for the reason, I just found: [Detecting Snowflake](https://www.hackerfactor.com/blog/index.php?/archives/944-Tor-0day-Snowflake.html) TLDR:
> Regular WebRTC clients do not do hostname lookups for remote STUN servers on the local network. If you see any DNS lookups for snowflake's STUN servers on the local network (stun.epygi.com.internal.lan, stun.voipgate.com.internal.lan, etc.) then you've found a Tor snowflake client.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25723Multiplex - one client splits traffic across multiple proxies2024-02-27T18:57:33ZDavid Fifielddcf@torproject.orgMultiplex - one client splits traffic across multiple proxiesThis is the dual of legacy/trac#25601.
It would be a great feature if a client could be connected to multiple snowflake proxies at once, and split traffic across all of them. Like the [Conflux](http://cacr.uwaterloo.ca/techreports/2013/...This is the dual of legacy/trac#25601.
It would be a great feature if a client could be connected to multiple snowflake proxies at once, and split traffic across all of them. Like the [Conflux](http://cacr.uwaterloo.ca/techreports/2013/cacr2013-16.pdf) proposal for Tor. It would be a hedge against getting assigned a single slow proxy.
This would require interposing some kind of sequencing and reliability layer, with possible retransmissions.
A potential benefit for privacy is that an individual snowflake proxy only sees a subset of a client's traffic flow.
However, instantly making _N_ WebRTC connections is a tell for traffic classification.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25601Multiplex - one snowflake proxy should be able to support multiple clients2020-06-27T13:40:37ZArlo BreaultMultiplex - one snowflake proxy should be able to support multiple clientsMigrated from https://github.com/keroserene/snowflake/issues/11
This seems to exist for the `proxy-go` but the JavaScript side has things like,
```
MAX_NUM_CLIENTS = 1
CONNECTIONS_PER_CLIENT = 1
```
so I'm guessing it wasn't finished.Migrated from https://github.com/keroserene/snowflake/issues/11
This seems to exist for the `proxy-go` but the JavaScript side has things like,
```
MAX_NUM_CLIENTS = 1
CONNECTIONS_PER_CLIENT = 1
```
so I'm guessing it wasn't finished.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40145NAT type refresh appears to be skipped on 24 hour cycle2023-04-13T16:01:20ZMarkCNAT type refresh appears to be skipped on 24 hour cycleAs of snowflake-proxy v.2.2.0 I’m getting 'Nat type: unknown' in the log. Previously on v.2.1.0 it was 'unrestricted/unrestricted'. When I run the nat behaviour tool it reports endpoint-independant for both mapping and filtering. I have ...As of snowflake-proxy v.2.2.0 I’m getting 'Nat type: unknown' in the log. Previously on v.2.1.0 it was 'unrestricted/unrestricted'. When I run the nat behaviour tool it reports endpoint-independant for both mapping and filtering. I have a static ip for the host computer and all ephemeral udp ports forwarded to it. Traffic flow for the proxy is way down as a result. I was averaging close to 1 GB/hr before.
Here’s the output from the NAT behaviour tool:
```
Users-Mac-mini:~ user$ $GOPATH/bin/stun-nat-behaviour —server stun.voip.blackberry.com:3478
2022/05/26 17:56:13 Connecting to STUN server: stun.voip.blackberry.com:3478
2022/05/26 17:56:15 Local address: 0.0.0.0:59082
2022/05/26 17:56:15 Received xormapped address: xxx.xxx.xx.xxx:59082
2022/05/26 17:56:15 Received xormapped address: xxx.xxx.xx.xxx:59082
2022/05/26 17:56:15 NAT mapping behavior: endpoint-independent
2022/05/26 17:56:15 Local address: 0.0.0.0:55624
2022/05/26 17:56:15 Received xormapped address: xxx.xxx.xx.xxx:55624
2022/05/26 17:56:15 NAT filtering behavior: endpoint-independent
```
And the output from proxy -verbose:
```
Users-Mac-mini:~ user$ proxy -verbose
2022/05/27 00:41:07 In the last 1h0m0s, there are 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/05/27 00:41:07 starting
2022/05/27 00:41:07 WebRTC: Created offer
2022/05/27 00:41:07 WebRTC: Set local description
2022/05/27 00:41:12 Offer: {"type":"offer","sdp":"v=0\r\no=- 8344757767766408414 1653612067 IN IP4 [scrubbed]\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 07:B3:E5:8A:F4:91:22:25:4C:E4:8F:C0:EF:F3:05:1C:8E:72:8A:60:4E:79:18:C5:7A:52:7A:BD:79:E2:6F:C1\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:zLGIWbmOZdWGnHVI\r\na=ice-pwd:mJruWarpiqemHmanJRrtzdcrXziaGsxp\r\na=candidate:1952023002 1 udp 2130706431 [scrubbed] 53922 typ host\r\na=candidate:1952023002 2 udp 2130706431 [scrubbed] 53922 typ host\r\na=candidate:170000163 1 udp 1694498815 [scrubbed] 63454 typ srflx raddr [scrubbed] rport 63454\r\na=candidate:170000163 2 udp 1694498815 [scrubbed] 63454 typ srflx raddr [scrubbed] rport 63454\r\na=end-of-candidates\r\n"}
2022/05/27 00:41:42 error polling probe: http2: timeout awaiting response headers
2022/05/27 00:41:42 NAT type: unknown
2022/05/27 00:41:42 WebRTC: Created offer
2022/05/27 00:41:42 WebRTC: Set local description
2022/05/27 00:41:47 Offer: {"type":"offer","sdp":"v=0\r\no=- 5257956900376912333 1653612102 IN IP4 [scrubbed]\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 0A:5B:00:59:1F:FD:F5:4E:40:DF:D4:80:CB:BE:59:35:9E:DF:CB:D5:AF:92:4F:61:86:17:75:FE:4E:72:D6:43\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:VHAlBzBCTjVuNPMK\r\na=ice-pwd:UyWRcktAolsfjKqCURXlLbeaqVuPUsyy\r\na=candidate:1952023002 1 udp 2130706431 [scrubbed] 58920 typ host\r\na=candidate:1952023002 2 udp 2130706431 [scrubbed] 58920 typ host\r\na=candidate:170000163 1 udp 1694498815 [scrubbed] 62713 typ srflx raddr [scrubbed] rport 62713\r\na=candidate:170000163 2 udp 1694498815 [scrubbed] 62713 typ srflx raddr [scrubbed] rport 62713\r\na=end-of-candidates\r\n"}
2022/05/27 00:42:17 error polling probe: http2: timeout awaiting response headers
2022/05/27 00:55:30 sdp offer successfully received.
2022/05/27 00:55:30 Generating answer...
2022/05/27 00:55:55 Timed out waiting for client to open data channel.
2022/05/27 01:41:07 In the last 1h0m0s, there are 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/05/27 01:48:09 sdp offer successfully received.
2022/05/27 01:48:09 Generating answer...
2022/05/27 01:48:34 Timed out waiting for client to open data channel.
2022/05/27 01:57:56 sdp offer successfully received.
2022/05/27 01:57:56 Generating answer...
2022/05/27 01:58:21 Timed out waiting for client to open data channel.
2022/05/27 02:13:32 sdp offer successfully received.
2022/05/27 02:13:32 Generating answer...
2022/05/27 02:13:57 Timed out waiting for client to open data channel.
2022/05/27 02:13:58 sdp offer successfully received.
2022/05/27 02:13:58 Generating answer...
2022/05/27 02:14:23 Timed out waiting for client to open data channel.
2022/05/27 02:41:07 In the last 1h0m0s, there are 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/05/27 03:15:00 sdp offer successfully received.
2022/05/27 03:15:00 Generating answer...
2022/05/27 03:15:26 Timed out waiting for client to open data channel.
```
Normally I’d have seen at least some traffic by this point. Perhaps I should be more patient?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40216Need documentation for utls-imitate and utls-nosni2023-03-10T15:28:13ZDavid Fifielddcf@torproject.orgNeed documentation for utls-imitate and utls-nosni!76 added support for uTLS in the client for broker rendezvous, using the SOCKS parameters `utls-imitate` and `utls-nosni`.
But I could not find documentation of these options.
They should be described in [client/README.md](client/README...!76 added support for uTLS in the client for broker rendezvous, using the SOCKS parameters `utls-imitate` and `utls-nosni`.
But I could not find documentation of these options.
They should be described in [client/README.md](client/README.md)
and the example client torrc, at least.
There also needs to be a listing somewhere of what values may be passed to `utls-imitate`.
I found the list of understood values in [common/utls/client_hello_id.go](common/utls/client_hello_id.go).
This list should also appear in client/README.md (manually maintained),
the `-help` output (automatically updated), or both.
This is the code in dnstt-client that lists the known fingerprints in `-help` output:
https://repo.or.cz/dnstt.git/blob/14a29048e4b659cb3113a7af37fbdb3349f13d37:/dnstt-client/main.go#l258
Its output looks like this:
```
Known TLS fingerprints for -utls are:
none Firefox Firefox_55 Firefox_56 Firefox_63 Firefox_65 Chrome
Chrome_58 Chrome_62 Chrome_70 Chrome_72 Chrome_83 iOS iOS_11_1
iOS_12_1
```https://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/40139Network activity around :00 every or every second hour2022-05-17T18:17:53ZLinus Nordberglinus@torproject.orgNetwork activity around :00 every or every second hourHere's a graph over 14h for `netfilter.conntrack_sockets` according to local netdata, tracking `/proc/sys/net/netfilter/nf_conntrack_max`. It seems like there are spikes building up to every even hour (:00) except sometimes it's only eve...Here's a graph over 14h for `netfilter.conntrack_sockets` according to local netdata, tracking `/proc/sys/net/netfilter/nf_conntrack_max`. It seems like there are spikes building up to every even hour (:00) except sometimes it's only every two hours.
This is more of an observation than a bug report.![conntrack-sockets](/uploads/062310020bd72e47b950903b4e98bd5a/conntrack-sockets.png)https://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/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 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/40254Nil Pointer Crash when Initializing Snowflake Proxy2023-03-07T15:49:08ZbimNil Pointer Crash when Initializing Snowflake Proxyhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L568
Line 568 ought to be moved below 589 - if the event dispatcher isn't set the proxy will crash. I came across this b...https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/lib/snowflake.go#L568
Line 568 ought to be moved below 589 - if the event dispatcher isn't set the proxy will crash. I came across this bumping snowflake to the the latest release in Orbot via our IPtProxy wrapper library.
https://github.com/tladesignz/IPtProxy/issues/39
For now, we simply just init'd our own event dispatcher instance to sidestep the crash.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40197nil pointer dereference in PeerConnection.PendingLocalDescription2022-10-03T11:53:14Zcypherpunksnil pointer dereference in PeerConnection.PendingLocalDescription```
info] {EDGE} connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
info] {EDGE} connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on...```
info] {EDGE} connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
info] {EDGE} connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
info] {NET} parse_socks_client(): SOCKS 5 client: continuing without authentication
info] {NET} connection_read_proxy_handshake(): Proxy Client: OR connection (handshaking (proxy)) with 192.0.2.3:80 ID=1zOHpg+FxqQfi/6jDLtCpHHqBTH8gjYmCKXkus1D5Ko RSA_ID=2B280B23E1107BB62ABFC40DDCC8824814F80A72 successful
info] {BTRACK} bto_update_best(): ORCONN BEST_ANY state 2->3 gid=4
notice] {CONTROL} Bootstrapped 10% (conn_done): Connected to a relay
info] {BTRACK} bto_update_best(): ORCONN BEST_AP state 2->3 gid=4
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: panic: runtime error: invalid memory address or nil pointer dereference
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: [signal 0xc0000005 code=0x0 addr=0x0 pc=0x5ed17d]
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error:
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: goroutine 53 [running]:
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: github.com/pion/webrtc.(*PeerConnection).PendingLocalDescription(0x0)
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/github.com/pion/webrtc/peerconnection.go:2026 +0x1d
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: github.com/pion/webrtc.(*PeerConnection).LocalDescription(0xc00034c000)
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/github.com/pion/webrtc/peerconnection.go:1007 +0x1e
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib.(*WebRTCPeer).connect(0xc00034c000, 0x0, 0xc000345d48)
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib/webrtc.go:150 +0xd8
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib.NewWebRTCPeerWithEvents(0x35ee40, 0xc0000d6000, {0x223f8f30008, 0xc00022e220})
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib/webrtc.go:73 +0x38b
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib.WebRTCDialer.Catch(...)
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib/rendezvous.go:172
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib.(*Peers).Collect(0xc000234080)
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib/peers.go:69 +0x223
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib.connectLoop({0x846bd0, 0xc000234080})
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib/snowflake.go:345 +0x56
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: created by git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib.(*Transport).Dial
info] {PT} managed_proxy_stderr_callback(): Managed proxy at 'PluggableTransports\snowflake-client.exe' reported via standard error: /var/tmp/dist/gopath/src/git.torproject.org/pluggable-transports/snowflake.git/v2/client/lib/snowflake.go:170 +0x206
info] {NET} TLS error: <syscall error while handshaking> (errno=10054: Connection reset by peer [WSAECONNRESET ]; state=SSLv3/TLS write client hello)
info] {OR} connection_tls_continue_handshake(): tls error [connection reset]. breaking connection.
info] {CIRC} circuit_n_chan_done(): Channel failed; closing circ.
info] {GENERAL} circuit_mark_for_close_(): Circuit 0 (id: 1) marked for close at circuitbuild.c:687 (orig reason: 8, new reason: 0)
info] {HANDSHAKE} connection_or_note_state_when_broken(): Connection died in state 'handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE'
info] {BTRACK} bto_status_rcvr(): ORCONN DELETE gid=4 status=2 reason=4
warn] {CONTROL} Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (CONNECTRESET; CONNECTRESET; count 1; recommendation warn; host 2B280B23E1107BB62ABFC40DDCC8824814F80A72 at 192.0.2.3:80)
warn] {HANDSHAKE} 1 connections have failed:
warn] {HANDSHAKE} 1 connections died in state handshaking (TLS) with SSL state SSLv3/TLS write client hello in HANDSHAKE
info] {OR} circuit_build_failed(): Our circuit 0 (id: 1) died before the first hop with no connection
info] {GUARD} entry_guards_note_guard_failure(): Recorded failure for primary guard $2B280B23E1107BB62ABFC40DDCC8824814F80A72 ($2B280B23E1107BB62ABFC40DDCC8824814F80A72)
info] {CIRC} circuit_free_(): Circuit 0 (id: 1) has been freed.
warn] {PT} Pluggable Transport process terminated with status code 2
```