Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2023-04-06T13:05:39Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40258Resynchronization with Upsteamed Remove HelloVerify countermeasure2023-04-06T13:05:39ZshelikhooResynchronization with Upsteamed Remove HelloVerify countermeasureAs of https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249, we have finished upstreaming Remove HelloVerify countermeasure changes to upstream.
We should try to resynchronize our dependency wit...As of https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249, we have finished upstreaming Remove HelloVerify countermeasure changes to upstream.
We should try to resynchronize our dependency with upstream.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249Upstreaming Remove HelloVerify countermeasure2023-03-03T11:45:36ZshelikhooUpstreaming Remove HelloVerify countermeasureWe have already released a version of snowflake with [Remove HelloVerify](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/134) [Orig](https://gitlab.torproject.org/tpo/anti-censorship/plu...We have already released a version of snowflake with [Remove HelloVerify](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/134) [Orig](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/131) countermeasure against Russia's censorship of snowflake. However, as we are currently applying the changes as a series of patch in the forked repo, this situation isn't ideal if that means we need to constantly rebase and maintain this fork.
Thus, we are currently seeking to upstream this change.
Changes to be upstreamed:
1. [DTLS](https://github.com/xiaokangwang/dtls/tree/dev-skiphelloverify) -> [Github Pull Request](https://github.com/pion/dtls/pull/513)
2. [WebRTC](https://github.com/xiaokangwang/webrtc/tree/dev-skiphelloverify) -> [Github Pull Request](https://github.com/pion/webrtc/pull/2407)
See Also: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/637shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40246Restart snowflake-server on snowflake-01 with num-turbotunnel=42023-07-18T00:47:29ZDavid Fifielddcf@torproject.orgRestart snowflake-server on snowflake-01 with num-turbotunnel=4We are hitting a performance ceiling at about 475 MiB/s TX. The CPUs are not fully saturated: they are averaging about 87%. Currently we have `num-turbotunnel=2`. I want to try increasing this to `num-turbotunnel=4` to see if the KCP sta...We are hitting a performance ceiling at about 475 MiB/s TX. The CPUs are not fully saturated: they are averaging about 87%. Currently we have `num-turbotunnel=2`. I want to try increasing this to `num-turbotunnel=4` to see if the KCP state machines are again a bottleneck.
Cf. #40200/!119 which effectively changed from `num-turbotunnel=1` to `num-turbotunnel=2`.
/cc @linus
![snowflake-01 bandwidth at eno1](/uploads/e50170475883f71f3d3306118dcbd2cd/snowflake-01-bw-20230107.png)David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40229Proxy log scrubbing misses URL-encoded IPv6 addresses2022-11-28T20:58:21ZDavid Fifielddcf@torproject.orgProxy log scrubbing misses URL-encoded IPv6 addressesThe log scrubbing patterns (tpo/anti-censorship/pluggable-transports/snowflake#21304, tpo/anti-censorship/pluggable-transports/snowflake#40115)
miss IPv6 addresses in URLs, where `:` is encoded as `%3A` or `%3a`.
URLs like these may be l...The log scrubbing patterns (tpo/anti-censorship/pluggable-transports/snowflake#21304, tpo/anti-censorship/pluggable-transports/snowflake#40115)
miss IPv6 addresses in URLs, where `:` is encoded as `%3A` or `%3a`.
URLs like these may be logged in the case of HTTP errors.
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/merge_requests/55#note_2851695
> `error dialing relay: wss://snowflake.torproject.net/?client_ip=2001%3Adb8%3A4000%3A%3A1234 = dial tcp: lookup snowflake.torproject.net: no such host`https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40223Spread snowflake-01 bridges' tor traffic over several IP addresses2024-01-22T15:19:37ZRoger DingledineSpread snowflake-01 bridges' tor traffic over several IP addressesWe discussed a few days ago how 12 super active snowflake back-end bridges on one IP address could trigger the "too many connections plus too many circuits from one IP address" anti-ddos defenses at Tor relays.
I asked Linus if we can g...We discussed a few days ago how 12 super active snowflake back-end bridges on one IP address could trigger the "too many connections plus too many circuits from one IP address" anti-ddos defenses at Tor relays.
I asked Linus if we can get a few more IP addresses for snowflake-01, and he thinks it sounds doable.
(They don't even need to be the sort of addresses that can receive incoming connections. So they could in theory be outbound natted or something. If that's easier -- I suspect it does not make it easier. :)
So step one is that @Linus gets those addresses and adds them to the computer and says here what they are. I think 3 or 4 or 6 total addresses would be good, but even 2 would be a lot more than 1.
And then step two is that @dcf or somebody goes in to the torrc's of the bridges and configures each of them to use the right outbound IP address. This is done by setting the "outboundbindaddress" line in their torrc.
(And I guess step zero, which can happen at any point, is that somebody notices this is a poor idea and jumps in to explain why.)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/40214standalone proxy: no connections since 2022/10/032022-10-15T14:33:26ZBeckersstandalone proxy: no connections since 2022/10/03I am running snowflake as an standalone proxy. It worked quite well until 2022/10/03 (according to the log file). Since then I get zero connections. Part of my logfile around a daily system restart:
```
2022/10/14 01:07:20 In the last 3...I am running snowflake as an standalone proxy. It worked quite well until 2022/10/03 (according to the log file). Since then I get zero connections. Part of my logfile around a daily system restart:
```
2022/10/14 01:07:20 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/10/14 01:37:20 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/10/14 01:49:27 error polling broker: read tcp [scrubbed]->[scrubbed]: read: connection reset by peer
2022/10/14 01:49:27 Error reading broker response: unexpected end of JSON input
2022/10/14 01:49:27 body:
2022/10/14 01:49:27 bad offer from broker
2022/10/14 02:00:18 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/10/14 02:00:18 starting
2022/10/14 02:00:18 WebRTC: Created offer
2022/10/14 02:00:18 WebRTC: Set local description
2022/10/14 02:00:18 Offer: {"type":"offer","sdp":"v=0\r\no=- 6893084309929587048 1665712818 IN IP4 [scrubbed]\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 BF:6A:76:02:37:8A:96:A4:6C:16:12:16:F5:40:86:65:F7:06:85:92:9D:3E:D7:8C:85:60:85:85:54:5C:37:ED\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:nhTnpZRAsoeUmxTh\r\na=ice-pwd:RLJbOGidLOUkKOLjDPXTUpWDbrRmWIgn\r\na=candidate:4056006514 1 udp 2130706431 [scrubbed] 43420 typ host\r\na=candidate:4056006514 2 udp 2130706431 [scrubbed] 43420 typ host\r\na=candidate:1367571592 1 udp 1694498815 [scrubbed] 43757 typ srflx raddr [scrubbed] rport 43757\r\na=candidate:1367571592 2 udp 1694498815 [scrubbed] 43757 typ srflx raddr [scrubbed] rport 43757\r\na=candidate:1309294897 1 udp 2130706431 [scrubbed] 43290 typ host\r\na=candidate:1309294897 2 udp 2130706431 [scrubbed] 43290 typ host\r\na=end-of-candidates\r\n"}
2022/10/14 02:00:44 NAT Type measurement: unknown -> restricted = restricted
2022/10/14 02:00:44 NAT type: restricted
2022/10/14 02:00:44 WebRTC: Created offer
2022/10/14 02:00:44 WebRTC: Set local description
2022/10/14 02:00:44 Offer: {"type":"offer","sdp":"v=0\r\no=- 1174260446418312236 1665712844 IN IP4 [scrubbed]\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 71:98:09:F4:C4:3F:FB:78:58:26:0E:A8:E3:25:4F:E7:36:F4:E1:96:55:40:9E:8A:F2:8C:EC:53:04:7D:5F:E1\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:YQHqUMIrLPzrDWPO\r\na=ice-pwd:KVyewBeBGOZfJJXmHKTJBNxwjVadqxkj\r\na=candidate:4056006514 1 udp 2130706431 [scrubbed] 40071 typ host\r\na=candidate:4056006514 2 udp 2130706431 [scrubbed] 40071 typ host\r\na=candidate:1367571592 1 udp 1694498815 [scrubbed] 50127 typ srflx raddr [scrubbed] rport 50127\r\na=candidate:1367571592 2 udp 1694498815 [scrubbed] 50127 typ srflx raddr [scrubbed] rport 50127\r\na=candidate:1309294897 1 udp 2130706431 [scrubbed] 55970 typ host\r\na=candidate:1309294897 2 udp 2130706431 [scrubbed] 55970 typ host\r\na=end-of-candidates\r\n"}
2022/10/14 02:01:41 NAT Type measurement: restricted -> restricted = restricted
2022/10/14 02:30:50 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/10/14 03:00:50 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
```
The planned restart takes place at 02:00 GMT. I don't know whether the error at 01:49 has any meaning. Broker seems to be 37.218.245.111 (greenhost.nl).https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40207Sudden reduction in snowflake-01 bridge bandwidth, 2022-10-04 17:152024-01-22T15:19:37ZDavid Fifielddcf@torproject.orgSudden reduction in snowflake-01 bridge bandwidth, 2022-10-04 17:15At around 2022-10-04 17:15 (about 2.75 hours ago), bandwidth on the bridge suddenly dropped
from about 3.2/2.4 Gbps TX/RX to about 1.0/0.8 Gbps TX/RX.
![snowflake-01 bandwidth on eno1](/uploads/96531ead7639867efd60f00881131ff8/snowflake...At around 2022-10-04 17:15 (about 2.75 hours ago), bandwidth on the bridge suddenly dropped
from about 3.2/2.4 Gbps TX/RX to about 1.0/0.8 Gbps TX/RX.
![snowflake-01 bandwidth on eno1](/uploads/96531ead7639867efd60f00881131ff8/snowflake-procnetdev-bw-20221006.png)
There is normally a nightly drop in usage, but this drop is several hours too early for that. It's also unusually flat.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40205Remove GOMAXPROCS=1 in the next deployment2022-10-25T16:34:16ZshelikhooRemove GOMAXPROCS=1 in the next deploymentWe should consider removing this unnecessary setting in the next deployment.
```
[6:12:21 pm] <dcf1> shelikhoo: it is also likely that GOMAXPROCS=1 can be removed from the run script. That was an experiment 2 years ago that turned out no...We should consider removing this unnecessary setting in the next deployment.
```
[6:12:21 pm] <dcf1> shelikhoo: it is also likely that GOMAXPROCS=1 can be removed from the run script. That was an experiment 2 years ago that turned out not to have an effect: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/32576#note_2594746
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40194Perform more regular dependency updates2023-07-04T14:27:43ZCecylia BocovichPerform more regular dependency updatesDependency updates happen in an adhoc way when we think of it or if there's a CVE we know about. I'd like to look into doing this more regularly, perhaps with the help of bots. I'd also like to revisit the pion dependency update process ...Dependency updates happen in an adhoc way when we think of it or if there's a CVE we know about. I'd like to look into doing this more regularly, perhaps with the help of bots. I'd also like to revisit the pion dependency update process for browser builds because the script at https://gitlab.torproject.org/-/snippets/145 needs hacks every time and the process still takes ages.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40184fixed unit for bandwidth logging2022-11-11T14:38:01Zinvokedfixed unit for bandwidth loggingCurrently, the proxy logs bandwidth in changing units as the bandwidth scales up (KB->MB->GB). It might be preferable for the proxy operators to have a fixed unit instead. The problems associated with the way it currently works is:
1....Currently, the proxy logs bandwidth in changing units as the bandwidth scales up (KB->MB->GB). It might be preferable for the proxy operators to have a fixed unit instead. The problems associated with the way it currently works is:
1. If the proxy operator wants to scrape the logs for bandwidth data for use in other programs, the unit keeps changing.
2. Units like GB can cause the values of 1 or 2 to be far less meaningful when the proxy won't see bandwidth in the GB range consistently.
I would suggest fixing the values to KB unit.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40174Update description in Snowflake extension pages on Firefox and Chrome2022-09-23T14:50:34ZrayaUpdate description in Snowflake extension pages on Firefox and ChromeThere was a discussion in the Tor IRC channel that the description in the Snowflake extension Chrome webstore and Firefox add-ons page does not clearly distinguish between censored/uncensored users:
- https://addons.mozilla.org/en-GB/fir...There was a discussion in the Tor IRC channel that the description in the Snowflake extension Chrome webstore and Firefox add-ons page does not clearly distinguish between censored/uncensored users:
- https://addons.mozilla.org/en-GB/firefox/addon/torproject-snowflake/
- https://chrome.google.com/webstore/detail/snowflake/mafpmfcccpbjnhfhjnllmmalhifmlcie
Opening the issue to say that I could work on updating the description in the next hour if the priority is high!
cc: @arma @gus @shelikhoo @meskiohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40161Snowflake Broker IP Change Rate Data HMAC Key Used the default value2023-07-29T18:04:14ZshelikhooSnowflake Broker IP Change Rate Data HMAC Key Used the default valueThis is an issue discovered in the https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40151 's configuration that the `ip-count-mask` used the default value, and make the counting result unsuitable ...This is an issue discovered in the https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40151 's configuration that the `ip-count-mask` used the default value, and make the counting result unsuitable for publishing.
I will deploy it again tomorrow with a randomly generated HMAC key. The collected unsalted IP count data will be retained and used for internal research only. It is not useless either, since it has collected data for over a month, and could be used for validation of this feature.shelikhooshelikhoo2022-08-03https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40146Avoid double NAT check on standalone proxy startup2022-05-30T14:29:17ZCecylia BocovichAvoid double NAT check on standalone proxy startupWhen go standalone proxies are first starting up, they perform two NAT probe checks in quick succession. The first is done by calling `checkNATType` directly from `Start` at [line 562](https://gitlab.torproject.org/tpo/anti-censorship/pl...When go standalone proxies are first starting up, they perform two NAT probe checks in quick succession. The first is done by calling `checkNATType` directly from `Start` at [line 562](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/ae5a71e6e58e664311e3a12f9adb48ed439df4a5/proxy/lib/snowflake.go#L562), and second as a part of the period `NatRetestTask` started at [line 577](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/ae5a71e6e58e664311e3a12f9adb48ed439df4a5/proxy/lib/snowflake.go#L577).
It's not much, but cutting down these double tests will reduce some of the load at the probe service.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/40122Set up a second snowflake bridge site2023-01-08T18:03:25ZDavid Fifielddcf@torproject.orgSet up a second snowflake bridge siteAt #28651, the plan is to run more than one snowflake bridge site. Each bridge site will have one instance of snowflake-server, speaking to a group of tor instances that all have the same identity keys. The identity keys in different bri...At #28651, the plan is to run more than one snowflake bridge site. Each bridge site will have one instance of snowflake-server, speaking to a group of tor instances that all have the same identity keys. The identity keys in different bridge sites will be different. Until now, we have had only one bridge site, and have kept the tor identity keys the same through server migrations (#40091, #40095, #40110, #40111). This issue is to set up a second bridge site, with its own, independent identity keys.
- [x] get access to the server hardware
- [x] decide on a bridge nickname
- [x] install bridge software ([installation guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide))
- [x] set up user accounts https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40091#note_2768855
- [x] point a domain name at the server https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28651#note_2787394
- [x] disable plain SSH access
/cc @shelikhooDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40110Move bridge to an interim faster server2022-05-17T00:24:17ZDavid Fifielddcf@torproject.orgMove bridge to an interim faster serverBackground: [\[tor-project\] More resources required for Snowflake bridge](https://forum.torproject.net/t/tor-project-more-resources-required-for-snowflake-bridge/2353)
I have or have been offered access to a faster server for the snowf...Background: [\[tor-project\] More resources required for Snowflake bridge](https://forum.torproject.net/t/tor-project-more-resources-required-for-snowflake-bridge/2353)
I have or have been offered access to a faster server for the snowflake bridge. I anticipate being able to change DNS and start using the faster server on Wednesday, 2022-03-16.
The current situation is: I have control right now of a suitable *paid* server, and I have an offer of a suitable *free* server that I am supposed to get control of on Tuesday, 2022-03-15. I will prefer to switch to the free server, but if there are any unforeseen problems with that deal, the paid server will be ready as a backup.
I expect to have to move the bridge *again*, to a more permanent home, but not before 2022-03-21 (#40111). The purpose of the migration in this ticket is to improve service until that other server is ready, and to mitigate any possible delays.
- [x] install new bridge ([installation guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide)), try 8 tor instances to start
- [x] copy user accounts https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40091#note_2768855
- [x] copy identity and onion keys from existing bridge
- [x] copy HTTPS TLS keys and certificates from existing bridge
- [x] test tor bootstrap on new bridge using local broker and proxy, and /etc/hosts domain name record https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40095#note_2773365
- [x] make DNS for snowflake.torproject.net point to the new bridge tpo/tpa/team#40664
- [x] monitor for a day, be ready to switch DNS back if connections fail
Cc @artDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40108standalone snowflake operators want a way to bind a specific outbound address2023-05-06T12:48:00ZRoger Dingledinestandalone snowflake operators want a way to bind a specific outbound addressThis is similar to Tor's ```OutboundBindAddress``` config option: if you're running headless snowflake on a server with multiple IP addresses, you want a way to control which IP address your outgoing connections will come from.
Tricks c...This is similar to Tor's ```OutboundBindAddress``` config option: if you're running headless snowflake on a server with multiple IP addresses, you want a way to control which IP address your outgoing connections will come from.
Tricks can be done with routing and iptables and etc, but those are OS-specific, require messing with stuff at the root level, etc. Maybe it is a two-line patch to let snowflake call bind() on the outbound connection socket?itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40106proxy-go support for IGD2024-02-20T07:58:00ZJillproxy-go support for IGDI tried using the proxy-go in two setup, one on a laptop behind NAT, the other on a server with its own restrictive firewall.
In both cases the NAT type was detected as "restricted". My understanding is that at most one end of the conne...I tried using the proxy-go in two setup, one on a laptop behind NAT, the other on a server with its own restrictive firewall.
In both cases the NAT type was detected as "restricted". My understanding is that at most one end of the connection can be restricted,
so a restricted proxy can't talk to a restricted client. Getting an unrestricted NAT is better as it's compatible with more clients.
To that effect, proxy-go could use [IGD](https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protocol) to ask the NAT to create a dynamic
port forwarding so it is effectively unrestricted. This would help with the laptop situation (assuming the router doing NAT supports IGD,
which mine does), and using something like [miniupnp](https://miniupnp.tuxfamily.org/), it would also be possible to dynamically open ports
on a local, restrictive, firewall.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40091Set up a Snowflake bridge staging server2022-04-06T05:00:23ZDavid Fifielddcf@torproject.orgSet up a Snowflake bridge staging serverThe goals of this issue are:
1. Share practical experience setting up a snowflake bridge.
2. Write a [Snowflake Bridge Installation Guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-I...The goals of this issue are:
1. Share practical experience setting up a snowflake bridge.
2. Write a [Snowflake Bridge Installation Guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Bridge-Installation-Guide), like the existing [Snowflake Broker Installation Guide](https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival-Guides/Snowflake-Broker-Installation-Guide).
3. Install an [experimental load balancing configuration](https://lists.torproject.org/pipermail/tor-relays/2022-January/020183.html) in an attempt to increase the capacity of the bridge.
If the load balancing configuration works, we can then apply it to the production bridge. (Or change DNS so as to swap production and staging.)
We talked about scaling the snowflake bridge and load balancing ideas at the [2022-01-06 team meeting](http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-01-06-15.59.html).
<details>
<summary>Meeting notes</summary>
* Scaling Snowflake bridge
* Already increased from 4 to 8 CPUs
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40085
* We should profile snowflake-server to reduce its CPU use
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40086
* But dcf feels that the bottleneck is not the snowflake-server process (which is multithreaded and can use multiple CPU cores), but the tor process (which can only use 1 CPU core and is already constantly at 100%). See https://lists.torproject.org/pipermail/tor-relays/2021-December/020156.html
* It turns out that it is possible to run multiple instances of tor with the same identity keys (hence the same fingerprint), either on the same host or on different hosts: https://lists.torproject.org/pipermail/tor-relays/2021-December/020157.html. Multiple instances of tor is a way of scaling tor beyond 1 CPU core, with snowflake-server distributing traffic over the available instances: https://lists.torproject.org/pipermail/tor-relays/2021-December/020182.html
* With another shim (similar to moat-shim) you can keep ExtORPort metrics reporting in the load-balanced configuration:
* https://gitlab.torproject.org/dcf/extor-static-cookie
* https://lists.torproject.org/pipermail/tor-relays/2022-January/020183.html
* Though I'm not sure, if Metrics gets multiple descriptors per day with the same fingerprint, whether it will sum all of them, or only keep one of them
* dcf has a bridge running now (with obfs4proxy, not snowflake-server) with this extor-static-cookie + load balancing configuration
* https://metrics.torproject.org/rs.html#details/07B9C6D7BE9685E83FA8C7A4FEB34CAD6CB77503
* Though I have not tested Roger's caveat about DEFAULT_ONION_KEY_LIFETIME_DAYS yet https://lists.torproject.org/pipermail/tor-relays/2022-January/020196.html
* We could apply this same thing to the snowflake bridge. But it is kind of a big configuration change: we need to stop snowflake-server being managed by tor, and instead run it independently (i.e., using runit or systemd) and have it talk to the tor instances' static ExtORPorts through a load balancer. It would be best to do this on a staging server separate from production first.
* we tentatively plan to do this next tuesday, 2022-01-11. dcf will be in touch and have a host ready for installation.
* Once the tor bottleneck is removed, though, we are not too far from the next likely bottleneck, which is total CPU of the host, shared between tor and snowflake-server. It might be time to think about migrating to different hosting for the snowflake bridge. Or we can experiment with running snowflake-server on one host, and N instances of tor on another (preferably nearby) host.
</details>Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & TibetDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org