Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2022-07-26T21:57:26Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40142Race condition in broker library causes broker to crash2022-07-26T21:57:26ZitchyonionRace condition in broker library causes broker to crash(This is the error message from s28 version of broker. Tor version will be slightly different)
```
http: panic serving 127.0.0.1:39380: runtime error: index out of range [0] with length 0
goroutine 105878 [running]:
net/http.(*conn).ser...(This is the error message from s28 version of broker. Tor version will be slightly different)
```
http: panic serving 127.0.0.1:39380: runtime error: index out of range [0] with length 0
goroutine 105878 [running]:
net/http.(*conn).serve.func1(0xc008088aa0)
/usr/local/go/src/net/http/server.go:1800 +0x13b
panic(0x7f12dec52440, 0xc002aa3bc0)
/usr/local/go/src/runtime/panic.go:975 +0x3e7
github.com/RACECAR-GU/snowflake/broker.SnowflakeHeap.Swap(...)
/usr/local/go/pkg/mod/github.com/!r!a!c!e!c!a!r-!g!u/snowflake@v0.0.0-20211214215908-95acebd91684/broker/snowflake-heap.go:32
container/heap.Pop(0x7f12decd1f60, 0xc00030e040, 0x12, 0xc0030c5d94)
/usr/local/go/src/container/heap/heap.go:62 +0x66
github.com/RACECAR-GU/snowflake/broker.clientOffers(0xc000322570, 0x7f12decce160, 0xc009662c40, 0xc005554300)
/usr/local/go/pkg/mod/github.com/!r!a!c!e!c!a!r-!g!u/snowflake@v0.0.0-20211214215908-95acebd91684/broker/broker.go:297 +0x5c9
github.com/RACECAR-GU/snowflake/broker.SnowflakeHandler.ServeHTTP(0xc000322570, 0x7f12deca9b80, 0x7f12decce160, 0xc009662c40, 0xc005554300)
/usr/local/go/pkg/mod/github.com/!r!a!c!e!c!a!r-!g!u/snowflake@v0.0.0-20211214215908-95acebd91684/broker/broker.go:97 +0x213
net/http.(*ServeMux).ServeHTTP(0x7f12df1e8d20, 0x7f12decce160, 0xc009662c40, 0xc005554300)
/usr/local/go/src/net/http/server.go:2416 +0x1a7
net/http.serverHandler.ServeHTTP(0xc000332000, 0x7f12decce160, 0xc009662c40, 0xc005554300)
/usr/local/go/src/net/http/server.go:2836 +0xa5
net/http.(*conn).serve(0xc008088aa0, 0x7f12deccfe60, 0xc006437ec0)
/usr/local/go/src/net/http/server.go:1924 +0x86e
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2962 +0x35e
```itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40141are snowflake events safe to make public their content2022-05-25T16:09:39Zmeskiomeskio@torproject.orgare snowflake events safe to make public their contentOONI wants to use the client event API and publish the strings of the events in the json. Do they contain any personal data like IP addresses?OONI wants to use the client event API and publish the strings of the events in the json. Do they contain any personal data like IP addresses?meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40140Snowflake blocked by ClientHello [RU]2022-10-04T17:50:22ZcypherpunksSnowflake blocked by ClientHello [RU]<details>
<summary>FAIL: https://paste.debian.net/plainh/e32d200a</summary>
```
Datagram Transport Layer Security
DTLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: DTLS 1.2...<details>
<summary>FAIL: https://paste.debian.net/plainh/e32d200a</summary>
```
Datagram Transport Layer Security
DTLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: DTLS 1.2 (0xfefd)
Epoch: 0
Sequence Number: 0
Length: 124
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 112
Message Sequence: 0
Fragment Offset: 0
Fragment Length: 112
Version: DTLS 1.2 (0xfefd)
Random: <snip>...
GMT Unix Time: <snip> UTC
Random Bytes: <snip>...
Session ID Length: 0
Cookie Length: 0
Cipher Suites Length: 12
Cipher Suites (6 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 58
Extension: signature_algorithms (len=16)
Type: signature_algorithms (13)
Length: 16
Signature Hash Algorithms Length: 14
Signature Hash Algorithms (7 algorithms)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Hash Algorithm Hash: SHA256 (4)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
Signature Hash Algorithm Hash: SHA384 (5)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
Signature Hash Algorithm Hash: SHA512 (6)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Signature Hash Algorithm Hash: SHA256 (4)
Signature Hash Algorithm Signature: RSA (1)
Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
Signature Hash Algorithm Hash: SHA384 (5)
Signature Hash Algorithm Signature: RSA (1)
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Hash Algorithm Hash: SHA512 (6)
Signature Hash Algorithm Signature: RSA (1)
Signature Algorithm: ed25519 (0x0807)
Signature Hash Algorithm Hash: Unknown (8)
Signature Hash Algorithm Signature: Unknown (7)
Extension: renegotiation_info (len=1)
Type: renegotiation_info (65281)
Length: 1
Renegotiation Info extension
Renegotiation info extension length: 0
Extension: supported_groups (len=8)
Type: supported_groups (10)
Length: 8
Supported Groups List Length: 6
Supported Groups (3 groups)
Supported Group: x25519 (0x001d)
Supported Group: secp256r1 (0x0017)
Supported Group: secp384r1 (0x0018)
Extension: ec_point_formats (len=2)
Type: ec_point_formats (11)
Length: 2
EC point formats Length: 1
Elliptic curves point formats (1)
EC point format: uncompressed (0)
Extension: use_srtp (len=7)
Type: use_srtp (14)
Length: 7
SRTP Protection Profiles Length: 4
SRTP Protection Profile: SRTP_AEAD_AES_128_GCM (0x0007)
SRTP Protection Profile: SRTP_AES128_CM_HMAC_SHA1_80 (0x0001)
MKI Length: 0
Extension: extended_master_secret (len=0)
Type: extended_master_secret (23)
Length: 0
```
</details>
<details>
<summary>PASS: https://paste.debian.net/plainh/fe7c64fc</summary>
```
Datagram Transport Layer Security
DTLS Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: DTLS 1.0 (0xfeff)
Epoch: 0
Sequence Number: 0
Length: 176
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 164
Message Sequence: 0
Fragment Offset: 0
Fragment Length: 164
Version: DTLS 1.2 (0xfefd)
Random: <snip>...
GMT Unix Time: <snip> UTC
Random Bytes: <snip>...
Session ID Length: 0
Cookie Length: 0
Cipher Suites Length: 16
Cipher Suites (8 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 106
Extension: extended_master_secret (len=0)
Type: extended_master_secret (23)
Length: 0
Extension: renegotiation_info (len=1)
Type: renegotiation_info (65281)
Length: 1
Renegotiation Info extension
Renegotiation info extension length: 0
Extension: supported_groups (len=8)
Type: supported_groups (10)
Length: 8
Supported Groups List Length: 6
Supported Groups (3 groups)
Supported Group: x25519 (0x001d)
Supported Group: secp256r1 (0x0017)
Supported Group: secp384r1 (0x0018)
Extension: ec_point_formats (len=2)
Type: ec_point_formats (11)
Length: 2
EC point formats Length: 1
Elliptic curves point formats (1)
EC point format: uncompressed (0)
Extension: application_layer_protocol_negotiation (len=18)
Type: application_layer_protocol_negotiation (16)
Length: 18
ALPN Extension Length: 16
ALPN Protocol
ALPN string length: 6
ALPN Next Protocol: webrtc
ALPN string length: 8
ALPN Next Protocol: c-webrtc
Extension: signature_algorithms (len=32)
Type: signature_algorithms (13)
Length: 32
Signature Hash Algorithms Length: 30
Signature Hash Algorithms (15 algorithms)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Hash Algorithm Hash: SHA256 (4)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
Signature Hash Algorithm Hash: SHA384 (5)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
Signature Hash Algorithm Hash: SHA512 (6)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Algorithm: ecdsa_sha1 (0x0203)
Signature Hash Algorithm Hash: SHA1 (2)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
Signature Hash Algorithm Hash: Unknown (8)
Signature Hash Algorithm Signature: Unknown (4)
Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
Signature Hash Algorithm Hash: Unknown (8)
Signature Hash Algorithm Signature: Unknown (5)
Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
Signature Hash Algorithm Hash: Unknown (8)
Signature Hash Algorithm Signature: Unknown (6)
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Signature Hash Algorithm Hash: SHA256 (4)
Signature Hash Algorithm Signature: RSA (1)
Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
Signature Hash Algorithm Hash: SHA384 (5)
Signature Hash Algorithm Signature: RSA (1)
Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
Signature Hash Algorithm Hash: SHA512 (6)
Signature Hash Algorithm Signature: RSA (1)
Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
Signature Hash Algorithm Hash: SHA1 (2)
Signature Hash Algorithm Signature: RSA (1)
Signature Algorithm: SHA256 DSA (0x0402)
Signature Hash Algorithm Hash: SHA256 (4)
Signature Hash Algorithm Signature: DSA (2)
Signature Algorithm: SHA384 DSA (0x0502)
Signature Hash Algorithm Hash: SHA384 (5)
Signature Hash Algorithm Signature: DSA (2)
Signature Algorithm: SHA512 DSA (0x0602)
Signature Hash Algorithm Hash: SHA512 (6)
Signature Hash Algorithm Signature: DSA (2)
Signature Algorithm: SHA1 DSA (0x0202)
Signature Hash Algorithm Hash: SHA1 (2)
Signature Hash Algorithm Signature: DSA (2)
Extension: Unknown type 28 (len=2)
Type: Unknown (28)
Length: 2
Data: 4000
Extension: use_srtp (len=11)
Type: use_srtp (14)
Length: 11
SRTP Protection Profiles Length: 8
SRTP Protection Profile: SRTP_AEAD_AES_128_GCM (0x0007)
SRTP Protection Profile: SRTP_AEAD_AES_256_GCM (0x0008)
SRTP Protection Profile: SRTP_AES128_CM_HMAC_SHA1_80 (0x0001)
SRTP Protection Profile: SRTP_AES128_CM_HMAC_SHA1_32 (0x0002)
MKI Length: 0
```
</details>shelikhooshelikhoohttps://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/40138snowflake-01: Change uplink from 1G to 10G2022-05-06T16:46:37ZLinus Nordberglinus@torproject.orgsnowflake-01: Change uplink from 1G to 10Gsnowflake-01.tpn has a 10G network interface but currently is connected to a 1G uplink port. This is planned to be changed on 2022-05-06, service window starting at 12:00 UTC.
Best case this will cause a few seconds of network outage.
...snowflake-01.tpn has a 10G network interface but currently is connected to a 1G uplink port. This is planned to be changed on 2022-05-06, service window starting at 12:00 UTC.
Best case this will cause a few seconds of network outage.
Another case is that we will have to bring down the system and install another PCI board. That might result in up to one hour of downtime for the whole system. I'll update this ticket when I know more.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40137Automated LoadBalanced Tor Snowflake Server Deployment System2022-10-12T18:46:02ZshelikhooAutomated LoadBalanced Tor Snowflake Server Deployment SystemWe are currently using load-balanced tor + snowflake for our current Snowflake setup. However, it still requires significant skill and effort to setup it up manually.
It might be wise for us to create an automated way to set up things t...We are currently using load-balanced tor + snowflake for our current Snowflake setup. However, it still requires significant skill and effort to setup it up manually.
It might be wise for us to create an automated way to set up things to make it easier for other organizations to run the Snowflake server.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40136Offloading KCP related processing from server to proxy2022-11-15T21:01:20ZshelikhooOffloading KCP related processing from server to proxyCurrently, to the best of my knowledge, the proxy will forward all data it received to the server, where packet loss and connection instability are compensated.
@arma asked if it would be possible to offload the packet loss compensation...Currently, to the best of my knowledge, the proxy will forward all data it received to the server, where packet loss and connection instability are compensated.
@arma asked if it would be possible to offload the packet loss compensation(KCP) to the proxy, thus reducing the traffic between proxy and server in order to improve connection speed. I am unsure if this would be possible, so I opened this ticket to start a public discussion that includes @dcf.
The original chat log is as follows:
```[7:17:43 pm] <+nickm> ␡␡␡␡␡␡␡␡␡␡␡␡␡␡␡␡␡␡␡␡␡␡␡␡␡[5~[5~my connection to this irc host seems to be having som e packet loss.
[7:17:46 pm] <+nickm> so i might have a hard time seeing whatever.
[7:36:23 pm] <+nickm> (is hetzner on fire, or is this the threatened upgrade to a new debian version?)
[7:41:20 pm] -*- ahf dont know
[7:47:00 pm] <+meejah> the chances of _two_ fires in one year are low, right?? ;)
[7:53:22 pm] <shelikhoo> there is a tool that can reduce the impact of packet loss: https://github.com/xtaci/kcptun
[7:53:53 pm] <shelikhoo> the KCP part of this tunnel software is already used in snowflake
[7:54:30 pm] <shelikhoo> it will send packets aggressively, so packet loss are overpowered
[7:55:33 pm] <shelikhoo> I use this for my traffic between home network and network egress to compensate for network quality issue with local ISP
[7:58:17 pm] <+armadev> shelikhoo: hey, speaking of kcp and snowflake, and now also speaking of tcp and bbr
[7:58:27 pm] <+armadev> if there is packet loss between the snowflake user and the snowflake volunteer,
[7:58:35 pm] <+armadev> like say one of them is inside china and one of them outside,
[7:58:56 pm] <+armadev> how does snowflake handle this? in the obfs4 case we found that being more aggressive at tcp helped a lot
[7:59:13 pm] <+armadev> ( https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/65 )
[7:59:14 pm] [zwiebelbot] tor:tpo/anti-censorship/team#65: S96 dynamic IP obfs4 bridge performance insufficiency - https://bugs.torproject.org/tpo/anti-censorship/team/65 - [Open]
[7:59:35 pm] <+armadev> is there some similar change we should consider for snowflake? or is the kcp part supposed to already handle that?
[8:00:07 pm] <shelikhoo> I think snowflake have built-in KCP, but test result from vantage point show some of times the bootstrap didn't finish
[8:00:22 pm] <shelikhoo> in our vantage point in China
[8:01:24 pm] <shelikhoo> let's say in the most recent test there is 1 of 10 times that it stuck at 50%
[8:01:43 pm] <+armadev> right. i am wondering if kcp, between client and bridge, is too big a loop
[8:02:22 pm] <shelikhoo> I didn't get the idea behind "is too big a loop"
[8:02:24 pm] <+armadev> (client -> volunteer -> bridge (and back))
[8:02:31 pm] <shelikhoo> oh yes
[8:02:49 pm] <shelikhoo> and KCP create a lot of traffic
[8:02:53 pm] <shelikhoo> which means
[8:03:13 pm] <shelikhoo> (volunteer -> bridge) will be slower
[8:03:16 pm] <shelikhoo> and
[8:03:32 pm] <shelikhoo> bridge will need to process more traffic
[8:04:09 pm] <+armadev> how is webrtc (dtls) at handling packet loss?
[8:04:27 pm] <+armadev> like, how much are we relying on kcp here because the other layers are failing us
[8:04:52 pm] <shelikhoo> however we are unable to move this KCP processing to volunteer side, since that would require rework of turbo tunnel....
[8:05:08 pm] <shelikhoo> webrtc handle packet loss with SCTP
[8:05:12 pm] <shelikhoo> not DTLS
[8:05:24 pm] <shelikhoo> https://github.com/pion/sctp
[8:05:33 pm] <shelikhoo> but it is toooooooo conservative
[8:05:53 pm] <shelikhoo> so won't work at all when there is packet loss
[8:06:17 pm] <shelikhoo> so very slow when there is constant packet loss
[8:06:26 pm] <+armadev> ok so that is a good candidate as The Problem
[8:07:23 pm] <shelikhoo> I think the task in improving snowflake speed is assigned to cecylia ....
[8:07:44 pm] <shelikhoo> But I also have some experience in getting around this issue
[8:07:47 pm] <shelikhoo> as well
[8:08:13 pm] <+armadev> yep. i am not worried that we will steal her task and accidentally finish it :)
[8:09:17 pm] <shelikhoo> it is actually a quite difficult task, the way I was trying to solve it in my own research is with forward error correction
[8:10:14 pm] <shelikhoo> like reed solomon
[8:10:20 pm] <shelikhoo> reed solomon
[8:10:28 pm] <shelikhoo> or Fountain code
[8:11:36 pm] <shelikhoo> so instead of retransmit data when things are lost like tcp
[8:11:46 pm] <shelikhoo> or send a few copy of data like kcp
[8:12:02 pm] <shelikhoo> send original data and a few reconstruction shard
[8:12:47 pm] <+armadev> year. this is an entire research field. i imagine the theory is pretty easy, but if the reality is that packet loss isn't uniformly-at-random, the theory starts to fall apart
[8:13:15 pm] <shelikhoo> so in an given block the number of loss packet is lower than reconstruction shard then it will not need retransmission
[8:13:48 pm] <shelikhoo> and in my own project, there is packet dispatch pattern control
[8:14:20 pm] <shelikhoo> so reconstruction shard are not all send in the same time as the data itself
[8:15:15 pm] <shelikhoo> instead different packet are dynamically scheduled to send interlaced
[8:15:50 pm] <shelikhoo> so burst lost and constant loss case all deal with in an best effort way
[8:18:53 pm] <+armadev> you should learn about... what's it called.. 'network coding'
[8:19:49 pm] <shelikhoo> yes! added to todo list
[8:20:57 pm] <+armadev> all of these things are fun in theory but the people who work on them rarely actually interact with the real world. that makes it tough. :)
[8:22:16 pm] <shelikhoo> Isn't this kind of thing that are in mobile phone's baseband that are also know as 4G/5G?
[8:22:34 pm] <shelikhoo> Isn't this kind of thing are in mobile phone's baseband that are also know as 4G/5G?
[8:22:55 pm] <shelikhoo> so they kind of need to face reality
[8:25:50 pm] <+armadev> i don't know. good question. i would also wonder if the type/pattern of packet loss they see is different from what snowflake sees.
[8:26:04 pm] <+armadev> they probably get transient radio interference etc, which is different from congestion
[8:28:31 pm] <shelikhoo> Yes that could be true. This is a good question that I don't answer now. But when cecylia actually begin the work on this part, I would be happy to join the discussion about transfer performance(and sad if not invited....).
[8:30:07 pm] <+armadev> please grab the backlog here in case you want to use it then
[8:30:24 pm] <+armadev> and bringing it back to snowflake: wait what, we use sctp, not dtls? is that because we use the data channel and not the media channel?
[8:30:50 pm] <shelikhoo> dtls is encryption
[8:31:00 pm] <shelikhoo> sctp is packet -> stream
[8:31:12 pm] <+armadev> oh. it's dtls on the outside, sctp inside, and yet something else inside that probably?
[8:31:31 pm] <shelikhoo> then turbo tunnel inside
[8:31:38 pm] <+armadev> so the answer to "how does dtls handle packet loss" is "some of the packets don't arrive, that's how it handles it"
[8:31:42 pm] <shelikhoo> turbo tunnel includes a layer of kcp
[8:32:47 pm] <shelikhoo> DTLS will propagate packet loss to the user
[8:32:59 pm] <+armadev> does webrtc always use sctp?
[8:33:27 pm] <shelikhoo> yes, but sctp support reliable and unreliable traffic
[8:33:41 pm] <shelikhoo> so it can either propagate packet loss
[8:33:52 pm] <shelikhoo> or deal with it itself
[8:34:30 pm] <shelikhoo> we are asking it to propagate packet loss and deal with it at turbo tunnel's kcp
[8:35:06 pm] <+armadev> oh interesting. so we could try to get it to fix its packet loss at the client -> volunteer layer too.
[8:35:27 pm] <+armadev> and then we'd have two layers fighting each other, but maybe it's stll a win. fun.
[8:35:40 pm] <shelikhoo> that would some rework of turbo tunnel i guess
[8:36:20 pm] <+armadev> not necessarily. we could let turbotunnel keep doing what it is doing, for example to handle when you change snowflakes
[8:38:22 pm] <shelikhoo> I am unsure about that.... We can discuss this in a ticket.... I can create a ticket to discuss this with dcf around....
[8:42:12 pm] <+armadev> yep. i don't have any answers. just yet more possible ways to combine cpomponents.
[8:42:38 pm] <shelikhoo> yes...
[8:42:43 pm] <+armadev> (experiencing my own packet loss here, which makes typos, sorry)
[8:43:12 pm] <shelikhoo> (no problem~)```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40135Cannot build snowflake/proxy2022-07-09T04:20:15ZcypherpunksCannot build snowflake/proxyHello! I want to install the snowflake proxy on my raspberry pi, but I can't seem to build it. I updated my system via apt-get update/update succesfully and the installation of git and golang were also successful. But after cloning the ...Hello! I want to install the snowflake proxy on my raspberry pi, but I can't seem to build it. I updated my system via apt-get update/update succesfully and the installation of git and golang were also successful. But after cloning the git, I went to /home/pi/snowflake/proxy and when I enter go build the system gives me this:
```
pi@raspberrypi:~/snowflake/proxy $ go build
main.go:5:2: cannot find package "git.torproject.org/pluggable-transports/snowflake.git/v2/common/event" in any of:
/usr/lib/go-1.7/src/git.torproject.org/pluggable-transports/snowflake.git/v2/common/event (from $GOROOT)
($GOPATH not set)
main.go:12:2: cannot find package "git.torproject.org/pluggable-transports/snowflake.git/v2/common/safelog" in any of:
/usr/lib/go-1.7/src/git.torproject.org/pluggable-transports/snowflake.git/v2/common/safelog (from $GOROOT)
($GOPATH not set)
main.go:13:2: cannot find package "git.torproject.org/pluggable-transports/snowflake.git/v2/proxy/lib" in any of:
/usr/lib/go-1.7/src/git.torproject.org/pluggable-transports/snowflake.git/v2/proxy/lib (from $GOROOT)
($GOPATH not set)
```
What is the problem here, and how can I fix it? Whe I look into /usr/lib/go-1.7/src/ there is no git.torproject.org subdirectory
I hope, you can help me.itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40134Log messages from client NAT check failures are confusing2022-05-31T22:11:07ZDavid Fifielddcf@torproject.orgLog messages from client NAT check failures are confusingWhen [`CheckIfRestrictedNAT`](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/common/nat/nat.go?h=v2.1.0#n34) fails with an error, it logs a message like `Error: no response from server`. But in context, the message...When [`CheckIfRestrictedNAT`](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/common/nat/nat.go?h=v2.1.0#n34) fails with an error, it logs a message like `Error: no response from server`. But in context, the messages confusingly appear to refer to the broker rendezvous, not the STUN server connection:
```
Target URL: snowflake-broker.torproject.net.global.prod.fastly.net
Front URL: cdn.sstatic.net
Error: no response from server
Error: no response from server
Error: no response from server
```
In this situation, communication with the broker has succeeded and a proxy has been assigned, but the client is having trouble checking its own NAT type. These log messages should say "STUN" or "NAT" somewhere in them, and ideally also the address of the server that failed (possibly subject to safe-log scrubbing).
Refactoring suggestion: instead of having a log call at every return of `isRestrictedMapping`, you can use [`fmt.Errorf("...: %w")`](https://pkg.go.dev/errors) to wrap the underlying error with additional context, and just return the error. That way, the logging can be consolidated in [`updateNATType`](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/lib/snowflake.go?h=v2.1.0#n239), which is also where the STUN server address can be added and displayed.itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40133Idea: Replace long polling for Proxy to Broker2022-07-26T20:47:14ZcheakoIdea: Replace long polling for Proxy to BrokerSee the title: The Proxy(s) already use Websockets to communicate with the Server, are there reasons not to use WS for communicating with the Broker?See the title: The Proxy(s) already use Websockets to communicate with the Server, are there reasons not to use WS for communicating with the Broker?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40131Unix socket support.2023-01-05T17:20:17ZcheakoUnix socket support.I usually want to have nginx reverse proxy over Unix sockets. Otherwise, there are strange fw rules for "random" port numbers.
For both the websocket to tor server and the broker.I usually want to have nginx reverse proxy over Unix sockets. Otherwise, there are strange fw rules for "random" port numbers.
For both the websocket to tor server and the broker.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40129Distributed Snowflake Server Support2024-02-28T14:02:57ZshelikhooDistributed Snowflake Server SupportWe are currently working on making Snowflake more [distrubuted](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28651#note_2787394). And this ticket will be used to track the progress of implemen...We are currently working on making Snowflake more [distrubuted](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28651#note_2787394). And this ticket will be used to track the progress of implementing the proposal made in the respective ticket.
- [x] Implementing Client Bridge Fingerprint Indication [MR](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/81)
- [x] Implementing Bridge List Definition Parser
- [x] Implementing Relay Host Name Pattern Matcher
- [x] Implementing Proxy(forwarder) Distributed Snowflake Server Support Indication Messaging Format Support
- [x] Implementing Broker Relay URL Indication to Proxy(forwarder)
- [x] Implementing Proxy(forwarder) Custom Relay URL Support
- [x] Implementing Proxy(forwarder) Custom Relay URL Hostname Pattern Matching Guard
- [x] Implementing Proxy(forwarder) Side Allowed Relay Hostname Pattern Indication
- [x] Creating Testing Environment for Distributed Snowflake Server
- [x] Implementing Broker Side Allowed Relay Hostname Pattern Indication Rejection for Proxy
- [x] Implementing Broker Side Allowed Relay Hostname Pattern Indication Rejection for Proxy - Better Error Message
- [x] Make sure legacy client will still work
- [x] Make sure legacy client config on new client will still work
- [x] Make sure legacy proxy will still work(to a limited degree)
- [x] Add Metrics for Proxy Relay URL Extension Support Status.
- [ ] Implementing Broker Side Allowed Relay Hostname Pattern Indication Rejection for Server
- [x] Implementing Web Proxy(forwarder) Custom Relay URL Support
- [x] Implementing Web Proxy(forwarder) Custom Relay URL Hostname Pattern Matching Guard
- [x] Implementing Web Proxy(forwarder) Side Allowed Relay Hostname Pattern Indication
- [ ] Implementing Web Proxy(forwarder) Relay URL Hostname Pattern UI
- [ ] User Document for Distributed Snowflake Server - Proxy Operators
- [ ] User Document for Distributed Snowflake Server - Client Users
- [x] Setup a Second Snowflake Bridge
### WIP Branch ###
Distributed Snowflake Testing Environment: https://github.com/xiaokangwang/snowflake-mu-docker
Distributed Snowflake: https://gitlab.torproject.org/shelikhoo/snowflake/-/commits/dev-mubrokershelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40127Bump webrtc and dtls library versions for Snowflake2022-04-14T13:51:52ZCecylia BocovichBump webrtc and dtls library versions for SnowflakeIt's been awhile since we bumped the version of webrtc and dtls.
The most recent release of https://github.com/pion/webrtc/ is `v3.1.28`. It includes the most recent version of https://github.com/pion/dtls/, which is `v2.1.3`. This incl...It's been awhile since we bumped the version of webrtc and dtls.
The most recent release of https://github.com/pion/webrtc/ is `v3.1.28`. It includes the most recent version of https://github.com/pion/dtls/, which is `v2.1.3`. This includes the fingerprinting fixes we made to circumvent blocking in Russia (see #40014).
We should do a quick look at the other changes made and test it out to make sure everything works as we expect.Cecylia BocovichCecylia Bocovichhttps://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/40120Certificate failure in Russia2022-06-20T14:54:34ZcypherpunksCertificate failure in Russia(I wonder whether it is correct place to report)
Latest TBB with snowflake currently fails to connect in Russia. It bootstraps only to 10% and then repeatedly logs:
offer created
broker failure x509: certificate has expired or is not ye...(I wonder whether it is correct place to report)
Latest TBB with snowflake currently fails to connect in Russia. It bootstraps only to 10% and then repeatedly logs:
offer created
broker failure x509: certificate has expired or is not yet valid:
(yes, with colon at the end. Looks like there should be some details)
I can access broker both directly and over Fastly using my normal browser.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40119let user bind interface honor OutboundBindAddressPT2022-04-11T21:45:27ZpseudonymisaTorlet user bind interface honor OutboundBindAddressPTCurrently, snowflake client does ignore torrc `OutboundBindAddressPT` option.
```
# [[OutboundBindAddressPT]] **OutboundBindAddressPT** __IP__::
# Request that pluggable transports makes all outbound connections
# originate fro...Currently, snowflake client does ignore torrc `OutboundBindAddressPT` option.
```
# [[OutboundBindAddressPT]] **OutboundBindAddressPT** __IP__::
# Request that pluggable transports makes all outbound connections
# originate from the IP address specified. Because outgoing connections
# are handled by the pluggable transport itself, it is not possible for
# Tor to enforce whether the pluggable transport honors this option. This
# option overrides **OutboundBindAddress** for the same IP version. This
# option may be used twice, once with an IPv4 address and once with an
# IPv6 address. IPv6 addresses should be wrapped in square brackets. This
# setting will be ignored for connections to the loopback addresses
# (127.0.0.0/8 and ::1).
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40118Fix misleading proxy usage statistics message on launch2022-05-31T20:36:21Zmeskiomeskio@torproject.orgFix misleading proxy usage statistics message on launchAs soon as you launch the proxy it displays:
```
2022/03/23 09:27:18 In the last 1h0m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
```
I guess it will be better to don't display that until some time has actually passed. Or ...As soon as you launch the proxy it displays:
```
2022/03/23 09:27:18 In the last 1h0m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
```
I guess it will be better to don't display that until some time has actually passed. Or at least don't say `In the last 1h`, because it hasn't being running 1hour.itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40117display the proxy NAT type in the logs2022-11-16T18:19:45Zmeskiomeskio@torproject.orgdisplay the proxy NAT type in the logsThe proxy NAT type is only being written to the logs if the `-verbose` flag is set. Will be nice to display it anyway.The proxy NAT type is only being written to the logs if the `-verbose` flag is set. Will be nice to display it anyway.itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40116Soften Tor log output for non critical events2022-04-12T15:57:06ZCecylia BocovichSoften Tor log output for non critical eventsWe had a forum post from a user who interpreted one of the snowflake connection events as a critical failure of snowflake: https://forum.torproject.net/t/snowflake-does-not-work-anymore/2650/2
While a failure to connect to the broker ca...We had a forum post from a user who interpreted one of the snowflake connection events as a critical failure of snowflake: https://forum.torproject.net/t/snowflake-does-not-work-anymore/2650/2
While a failure to connect to the broker can be critical, a failure to open a data channel with a snowflake is not unusual and snowflake can easily recover from it. Let's make a small change of the log message from "connection failed" to "trying a new proxy: [error message]" or something like thatitchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40115Scrub pt.Log calls like other logs2022-11-07T16:25:28ZDavid Fifielddcf@torproject.orgScrub pt.Log calls like other logs!67 added [`ptEventLogger`](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/bd636a1374efb514bbc40acbd1dcaf0ecec26916/client/lib/pt_event_logger.go) which sends messages to the managing process usin...!67 added [`ptEventLogger`](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/bd636a1374efb514bbc40acbd1dcaf0ecec26916/client/lib/pt_event_logger.go) which sends messages to the managing process using `pt.Log`. But these logs are not scrubbed of IP addresses the way all other logs are scrubbed (as in
#21304).
I saw this in the Tor Logs in Tor Browser:
```
3/17/22, 02:24:50.145 [NOTICE] Managed proxy "./TorBrowser/Tor/PluggableTransports/snowflake-client": offer created
3/17/22, 02:24:50.146 [NOTICE] Managed proxy "./TorBrowser/Tor/PluggableTransports/snowflake-client": broker failure dial tcp: lookup cdn.sstatic.net on 192.168.0.1:53: dial udp 192.168.0.1:53: connect: network is unreachable
```itchyonionitchyonion