Anti-censorship issueshttps://gitlab.torproject.org/groups/tpo/anti-censorship/-/issues2024-03-05T18:23:24Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40112High CPU load on idle proxies2024-03-05T18:23:24ZPeter GerberHigh CPU load on idle proxiesI've been running Snowflake proxies for some time now and I'm seeing rather high CPU load even when proxies are idle.
I'm seeing CPU usage similar to this on all my proxies:
```
systemctl status tor-snowflake
● tor-snowflake.service - ...I've been running Snowflake proxies for some time now and I'm seeing rather high CPU load even when proxies are idle.
I'm seeing CPU usage similar to this on all my proxies:
```
systemctl status tor-snowflake
● tor-snowflake.service - Tor Snowflake bridge
Loaded: loaded (/etc/systemd/system/tor-snowflake.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2022-03-12 11:18:37 CET; 1 day 5h ago
Main PID: 3242240 (tor-snowflake)
IP: 1.5G in, 1.5G out
Tasks: 9 (limit: 19046)
Memory: 55.6M
CPU: 7h 59min 35.486s
CGroup: /system.slice/tor-snowflake.service
└─3242240 /usr/local/bin/tor-snowflake
```
This corresponds to about a **~28% CPU load at an average speed of 15 kiB/s**.
I looked at the CPU load over the timespan of a few days. I see a CPU load of around 30% even with no traffic whatsoever. Thus, I suspect there are CPU cycles wasted somewhere.
OS: Debian 11 "bullseye"
Version: 19e9e384154adc6251579dc6843f11f53cbd0146https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40105Make the snowflake deb more accessible to Debian stable users2024-01-28T01:38:34ZRoger DingledineMake the snowflake deb more accessible to Debian stable usersWe made a Snowflake deb in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/19409 and it is apparently now in Debian sid: <br>
https://tracker.debian.org/pkg/snowflake
Yay!
These versions are on...We made a Snowflake deb in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/19409 and it is apparently now in Debian sid: <br>
https://tracker.debian.org/pkg/snowflake
Yay!
These versions are only in sid, right? Do we have a path in mind for normal Debian users to be able to install this deb? In particular, either a debian backports repository, or our deb.torproject.org repo.
(We have a policy that we only take things from Debian for our deb.tpo repo, but I think we would be following that policy here, since that deb *is* in Debian, it's just only in sid.)meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/32Bridgestrap should recognize and report obfs4 version incompatibility2023-01-24T18:56:18ZRoger DingledineBridgestrap should recognize and report obfs4 version incompatibilityWith the recent obfs4 bug where sometimes it fails to handshake (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804), we're going to want all the obfs4 bridges to upgrade to the new obfs4proxy version that we're ge...With the recent obfs4 bug where sometimes it fails to handshake (https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40804), we're going to want all the obfs4 bridges to upgrade to the new obfs4proxy version that we're getting into Debian. Once it's in Debian (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/obfs4/-/issues/33736) and we're doing our push to get bridge operators to upgrade, we're going to want a scalable way to recognize which bridges haven't upgraded, and tell their operators. Bridgestrap is already almost this tool.
Here are some plausible steps for getting there. Feel free to adjust this recipe in the face of reality or better ideas. :)
* [ ] Upgrade bridgestrap's obfs4proxy to the new one. That way it will start having reachability issues with *old* (unupgraded) obfs4proxies, rather than the current situation where it has reachability issues with new (upgraded) ones.
* [ ] Teach bridgestrap to recognize when it has learned that a given tested bridge is unupgraded. We recognize it because Tor gives us the ```Proxy Client: unable to connect OR connection (handshaking (proxy)) [...] RSA_ID=xxx``` complaint.
(To start, we can just listen to the WARN controller events and look for the string -- the RSA_ID param tells us which bridge had the problem. The better answer though is to involve the network team and see if they can give us some sort of more specific event, because the "manual string comparison" approach is brittle: if somebody changes the log message format, suddenly bridgestrap quietly breaks. Maybe a good enough compromise, in a world where C-Tor is freezing and Arti is the future, is to get a big comment added to that line in C-Tor saying that bridgestrap relies on that format and please check with bridgestrap before changing it.)
(We should also realize that the old version detection will be probabilistic, because sometimes the handshake will go fine and not send the WARN. That's ok, and imo bridgestrap's detection at this stage shouldn't try to get any smarter than "this time it worked" or "this time it flagged it as old".)
(In an ideal world we would have implemented https://gitlab.torproject.org/tpo/core/tor/-/issues/11101 in the past, and we wouldn't need to do these extra active measurement tests, and we could just look at the bridge's extrainfo descriptor to learn its obfs4 version. But we don't live in that world yet, so we should use this ticket as motivation to get that one done, but treat the two tickets separately.)
* [ ] When a test flags the bridge as old, we should report this info in our findings. I think based on the discussion in https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/21 we should be able to annotate (via a new line, or a new field on the main line, or etc) a bridge as "pre-0.0.12" or something like that in the file that bridgestrap exports to metrics.
* [ ] After that, we'll also want to change the bridges.torproject.org/status= output to not just say whether we found the bridge reachable, but also to call it out as old if we found it to be old.
(We could simply report the most recent result, so sometimes the page says you're ok when actually you're not; or we could try to do something smarter like "if any of the past k tests failed then we need to tell you" -- in which case we would want to include enough timestamps that the operator doesn't get confused when they upgrade but bridgestrap still complains to them -- talk to dgoulet and geko for their recent experience on reporting relay overload statuses to relay operators.)
* [ ] Once we get to this point, we'll want to open a ticket for relay-search to do some similar notification mechanism on the bridge's status page. It will face the same question of how best to communicate with the human operator (do I look at the latest k results, which timestamps should I specify to be clear, etc).
* [ ] After that, we'll also want to open a ticket for the network health community folks to start tracking the fraction of bridges that have / haven't upgraded. They can do this on their own by looking at bridgestrap's output file. Then they could run a campaign to get people to upgrade, or whatever they think is smartest at the time.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/45Proposal: Push Notification Based Signaling Channel2022-01-10T18:54:43ZshelikhooProposal: Push Notification Based Signaling ChannelProposal: Push Notification Based Signaling Channel
Modern [Operating Systems](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194...Proposal: Push Notification Based Signaling Channel
Modern [Operating Systems](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html#//apple_ref/doc/uid/TP40008194-CH8-SW1) and [Browsers](https://caniuse.com/push-api) support push notifications that can include data in their payload. This provides a uni-directional communication channel from the client to the server if the client does not have a push receiver running, or a bidirectional communication channel if the client has a push receiver running.
As we have seen in recent block [happened](https://gitlab.torproject.org/tpo/community/support/-/issues/40050) in Russia, even with domain fronting, adversaries are able to block fronting domains without significant consequence as in the case of [meek-azure](https://ntc.party/t/ooni-reports-of-tor-blocking-in-certain-isps-since-2021-12-01/1477/3). We might want to diversify our signalling channels to prevent blocking
## Advantages
### Collateral Damage Maximization
These pushing channels have no substitutions and offer a functionality that is observable to users. Once the pushing service is blocked, all apps(with servers hosted in the region) and websites will be influenced.
### Asymmetrical
When WebPush is used, a single codebase that interacts with a browser in a standardized way can be used on all browsers. The adversary will need to block a significant amount of service while we don't need to do anything vendor-specific.
### Plausible Fingerprint
For a push notification sender, it is expected to interact with applications that send requests from a non-browser environment. For push receivers, the proxy software won't interact with push service directly, thus no chance of being recognized for fingerprint.
## Disadvantages
### Special Environment for Receiver
Push notification receiver requires a running operating system or browser. This means it would be difficult to ship it with the client. The message from server to client may need an alternative channel such as to reply with source address forging.
### Special Setup Requirement
iOS-based push notification requires an Apple Developer account. This is not required by Web Push in most cases.https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/42Proposal: Support for Dynamic IP obfs4 bridges with unattended proxy informat...2024-02-27T19:00:35ZshelikhooProposal: Support for Dynamic IP obfs4 bridges with unattended proxy information update(aka "Subscription")
### Context
Currently, Tor [encourages](https://blog.torproject.org/run-a-bridge-campaign/) obfs4 bridges with a static address. This reduces the interruption to the users as users won't need to request new bridges frequently, which nee...
### Context
Currently, Tor [encourages](https://blog.torproject.org/run-a-bridge-campaign/) obfs4 bridges with a static address. This reduces the interruption to the users as users won't need to request new bridges frequently, which need to be done manually. However, this also allows censors to block bridges by IP, thus resulting in bridges consistently in an inaccessible state for some users.
### Proposal
Support obfs4 bridges with a dynamic IP address by allowing users to perform an unattended update of the bridge IP address. When the user retrieves an obfs4 bridge with a dynamic IP, the user will also receive a ticket. This ticket will then allow the user to receive an updated IP address of that bridge without completing a captcha or any manual interaction. The tor browser will do that on behalf of the user during connecting process. So, the user experience will not be impacted when the bridge operator rotates the IP address.
The operator of the obfs4 bridge can then switch to a new IP when the bridge is blocked. This process can be automated if we have an API to detect blocks.
### Additional Backgrounds
The concept of subscription(unattended proxy information update) is a feature supported by almost all Chinese anti-censorship tools. Here are some relevant discussions & screenshots.
An example of this will be [Shadowsockets SIP008](https://github.com/shadowsocks/shadowsocks-org/issues/89), which is currently supported by [Outline](https://github.com/Jigsaw-Code/outline-client/issues/891) and many other clients like [SagerNet](https://sagernet.org/). (Conflict of Interest Declared)
Here is a screenshot of the configuration screen for a "subscription" in SagerNet.
![unnamed](/uploads/34aa938764f18abff98b6133a46fe8a4/unnamed.jpg)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/issues/32Add 'Number of users your Snowflake has helped so far' feature in the extension2022-03-01T17:47:16ZShakilAdd 'Number of users your Snowflake has helped so far' feature in the extensionCurrently, it has 'Number of users your Snowflake has helped circumvent censorship in the last 24 hours'. I really love watching the number grow from 0 to 10-15 every day. If it is possible to see all the people I have helped so far, tha...Currently, it has 'Number of users your Snowflake has helped circumvent censorship in the last 24 hours'. I really love watching the number grow from 0 to 10-15 every day. If it is possible to see all the people I have helped so far, that would be even more encouraging.https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/53GetTor IPFS Provider2022-10-05T13:39:21ZTracGetTor IPFS ProviderI think IPFS could be a good provider by having support for downloading from multiple sources and while the clients don't work through Tor, there are many public gateways.
When attempting to find a list of public gateways, I found https...I think IPFS could be a good provider by having support for downloading from multiple sources and while the clients don't work through Tor, there are many public gateways.
When attempting to find a list of public gateways, I found https://github.com/ipfs/public-gateway-checker/blob/master/gateways.json .
I am not sure how the procedure could be automated, but manually it would work by installing ipfs, creating a folder for requested content, "ipfs add -r directory/" and going to https://example.com/ipfs/HASH (which was given by the previous command) to download it. Alternatively for single file "ipfs add -w file" so a directory is created for it preserving the filename instead of changing it to the hash when downloading.
Volunteers could also host the content by using "ipfs pin add HASH" possibly reducing server load.
**Trac**:
**Username**: Mkaysihttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40003Task 1.2: Grow contacts in key regions2022-03-01T15:57:23ZGabagaba@torproject.orgTask 1.2: Grow contacts in key regionsGrow and maintain contacts in key regions who can help us interpret results when we see or hear about potential blocking events.
Key regions defined in https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40007...Grow and maintain contacts in key regions who can help us interpret results when we see or hear about potential blocking events.
Key regions defined in https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40007
- [ ] find a way to track contacts and events in a private way and share it with @tpo/anti-censorship team
@gus I'm adding this ticket here as there is not really a place in @tpo/community to do it.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibethttps://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/25594Broker: investigate non-domain-fronting secure client / proxy registrations2024-02-27T18:55:26ZArlo BreaultBroker: investigate non-domain-fronting secure client / proxy registrations> Pasting discussion from email,
>
>> in the Flashproxy case, registration wasn't
>> bidi, and I think they imagined using insecure
>> channels to register like OSSes. In Snowflake,
>> the client is making TLS connections with the
>> bro...> Pasting discussion from email,
>
>> in the Flashproxy case, registration wasn't
>> bidi, and I think they imagined using insecure
>> channels to register like OSSes. In Snowflake,
>> the client is making TLS connections with the
>> broker, which amounts to the same thing as
>> encrypting the payload with the facilitator's
>> public key.
>
> Also,
>
>> There's also the case where an adversary DOSes the facilitator with a
>> bunch of fake client or proxy registrations and things like that.
>
> This is now legacy/trac#25593
>
>> Also, there is the potential that in the future we might need some
>> sort of non-domain-fronting rendezvous. It seems that right now we
>> have an ecosystem of tools growing that assumes domain-fronting will
>> always be available & effective. May be worth considering how to
>> prepare for regions where this might not work as well in the future.
>
> So this ticket should probably be for that.
\\ Migrated from https://github.com/keroserene/snowflake/issues/13
Ideas that have been proposed or done:
* #25985 AMP cache
* #25874 DNS
* #26151 Amazon SQSDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25591Pass STUN information from Broker to WebRTC Client2023-08-02T00:02:28ZArlo BreaultPass STUN information from Broker to WebRTC Client> The clients may be in filtered regions where common ICE servers may be unavailable.
>
> May need to revise the Configuration interface of go-webrtc while figuring this part out.
\\ Migrated from https://github.com/keroserene/snowflake...> The clients may be in filtered regions where common ICE servers may be unavailable.
>
> May need to revise the Configuration interface of go-webrtc while figuring this part out.
\\ Migrated from https://github.com/keroserene/snowflake/issues/3
We had some discussion [in a recent meeting](http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-12-05-18.00.log.html) about the original intent of this ticket.
I think to address the need of "default STUN servers are blocked for the client", it would be more interesting to pursue ways in which NAT punching information for the client could be sent over the domain-fronted connection to the broker. Some discussion on legacy/trac#30579 laid out reasons why a more private way of getting ICE candidates is desirable.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/22945End-to-end confidentiality for Snowflake client registrations2022-11-15T18:04:35ZDavid Fifielddcf@torproject.orgEnd-to-end confidentiality for Snowflake client registrationsClient requests sent to the /client broker endpoint use TLS to the front domain, and TLS from the front to the broker, but the fronting service itself (e.g. App Engine) can inspect them in plaintext. The fronting service unavoidably gets...Client requests sent to the /client broker endpoint use TLS to the front domain, and TLS from the front to the broker, but the fronting service itself (e.g. App Engine) can inspect them in plaintext. The fronting service unavoidably gets to learn the IP addresses of clients, but we could encrypt the additional metadata that appears in the registration messages.
I was thinking of giving the broker a private key and wrapping client registrations in a [NaCl box](https://godoc.org/golang.org/x/crypto/nacl/box).
This is roughly how it worked in flash proxy. The facilitator had a private RSA key, and client registration methods were encrypted before being posted to the facilitator.
https://gitweb.torproject.org/flashproxy.git/tree/facilitator/facilitator.cgi?id=1.4#n60
The actual key material was isolated into a facilitator-reg-daemon process that was separated from the web server and facilitator CGI:
https://gitweb.torproject.org/flashproxy.git/tree/facilitator/facilitator-reg-daemon?id=1.4David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/138Snowflake not available in Firefox Addon site2024-03-27T17:56:16ZcypherpunksSnowflake not available in Firefox Addon siteSnowflake is not on the addon site from firefox anymore.
https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/
the link from the guide https://snowflake.torproject.org/
is directing to the addon site from firefox, it wou...Snowflake is not on the addon site from firefox anymore.
https://addons.mozilla.org/en-US/firefox/addon/torproject-snowflake/
the link from the guide https://snowflake.torproject.org/
is directing to the addon site from firefox, it would be nice if you could download the addon directly from the tor projecthttps://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/197Add HTTPS distributor to the staging server2024-03-26T17:41:00Zmeskiomeskio@torproject.orgAdd HTTPS distributor to the staging servermeskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40354Extract reusable parts to a shared library2024-03-26T10:41:06Zmeskiomeskio@torproject.orgExtract reusable parts to a shared library[RoundCounter](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/broker/prometheus.go?ref_type=heads) is a useful wrapper on top of prometheus to round metrics to 8. We want to use it in other p...[RoundCounter](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/broker/prometheus.go?ref_type=heads) is a useful wrapper on top of prometheus to round metrics to 8. We want to use it in other projects like rdsys.
Another useful piece for other projects is [safelog](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tree/main/common/safelog?ref_type=heads) that is already being imported by bridgestrap and conjure. Maybe we want to be able to import it without snowflake.
We could bundle both into a single library as this might make it easier to add other pieces in the future and each extra library makes it harder to package software to distros.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40353Rename Container Image Tag for containers built from main branch to nightly2024-03-25T15:21:37ZshelikhooRename Container Image Tag for containers built from main branch to nightlyThe current container image tag for container images built from main branch is latest, which is typically expected to the most recent stable release, instead of the unstable main branch build result. The tag should be renamed to `nightly...The current container image tag for container images built from main branch is latest, which is typically expected to the most recent stable release, instead of the unstable main branch build result. The tag should be renamed to `nightly` as [discussed](https://lists.torproject.org/pipermail/tor-project/2024-March/003787.html) in the during the weekly meeting.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/conjure/-/issues/40Can't connect to phantoms acquired from CDN77 domain front2024-03-24T18:39:43ZCecylia BocovichCan't connect to phantoms acquired from CDN77 domain frontConjure works just fine with the fastly front and by contacting the registration server directly, but any connections through CDN77 fail. If I recall correctly, Conjure does a check to see whether the originating IP to the phantom matche...Conjure works just fine with the fastly front and by contacting the registration server directly, but any connections through CDN77 fail. If I recall correctly, Conjure does a check to see whether the originating IP to the phantom matches the IP address of the client registration. So either CDN77 is doing something unexpected with the `X-Forwarded-For` header, or the station needs to be told to check for it from CDN77 addresses.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40352Use unreliable and unordered WebRTC data channels2024-03-21T20:15:25ZDavid Fifielddcf@torproject.orgUse unreliable and unordered WebRTC data channels@shelikhoo:
Actually here are some observation from me related to https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40243:
Snowflake is currently using network resource in a so suboptimal way I ...@shelikhoo:
Actually here are some observation from me related to https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40243:
Snowflake is currently using network resource in a so suboptimal way I think it would make sense to also consider make protocol level change on how kcp is interacting with webrtc before considering to add forward error correction. This would be in the form of enabling unreliable mode of webrtc and make necessary change to get it to work.
Right now, kcp packets are sent in webrtc data channel in a reliable way that deliver all packets in order and retransmit any lost message repeatedly. However, kcp also retransmit its packet itself, which as a result, queue all those retransmitted packets somewhere, like in webrtc's buffer.
This means lost packets are required to be retransmitted more than once in different protocol, and retransmit & timeout get compounded. More retransmit result in more lost packets and more retransmission, which eventually lead to [connection melt down](https://openvpn.net/faq/what-is-tcp-meltdown/) <- please read.
back pressure like the one introduced in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/144 only move the problem, and block kcp's send in unexpected way, as kcp don't expect send to block as it is usually over udp.
See also: https://lists.torproject.org/pipermail/anti-censorship-team/2023-March/000286.html
(@dcf split this issue off from #40251 to separate the analysis of speed in China from the proposed remedy.)shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/35"Managed proxy at '/usr/local/sbin/webtunnel-server' failed the configuration...2024-03-25T11:21:06ZGus"Managed proxy at '/usr/local/sbin/webtunnel-server' failed the configuration protocol and will be destroyed."A bridge operator reported that their WebTunnel bridge stopped to work and found this message in their logs:"Managed proxy at '/usr/local/sbin/webtunnel-server' failed the configuration protocol and will be destroyed".
After restarting ...A bridge operator reported that their WebTunnel bridge stopped to work and found this message in their logs:"Managed proxy at '/usr/local/sbin/webtunnel-server' failed the configuration protocol and will be destroyed".
After restarting Tor, the bridge went back, but today it stopped again. Any ideas on why the webtunnel-server has crashed? Which logs they should provide for further analysis?shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40349Upgrade snowflake broker machine from Debian 102024-03-19T16:23:25ZCecylia BocovichUpgrade snowflake broker machine from Debian 10Looks like Debian 10 will not be supported by the LTS team after this June: https://wiki.debian.org/LTSLooks like Debian 10 will not be supported by the LTS team after this June: https://wiki.debian.org/LTS