- tor-relays - lists.torproject.org

Re: [tor-relays] Proposal: Restrict ContactInfo to Mandatory Email Address
by denny.obreham＠a-n-o-n-y-m-e.net 31 Oct '23

31 Oct '23

I've been thinking long and hard about this problem and I'm not sure if an email address - validated or not - is the best way to achieve the initial goals. What are the goals of having this validated email address? 1- Inform the operator; 2- Make sure the operator will read the info; 3- Identify the operator. I'll keep #1 for last as this is the only truly needed goal from my point of view. Identifying the operator ID to make further decisions on how to share the traffic may be kind of useless. There are either _good_ operators and you have no real reason to divert traffic from these relays or there are _bad_ operators and they will try to hide that fact by creating multiple identities. Your validated IDs are still useless to you as identifying _bad_relay operators. About validating an email address to make sure the operator will read the info, it is still not a guarantee that it will happen in the future. If an operator does not want to - or cannot - read his/her emails, you cannot do anything about it. Except maybe revalidating the email address regularly which is, first, annoying and, second, what are going to do if a _good_ relay operator doesn't revalidate his/her email address? Shut down all of his/her relays? You might shoot yourself in the foot going with such an attitude. So there is no real point in validating an email. It will just turn out to be more red tape to go through. About point #1, you want to inform the relay operator. Do you need a two-way communication method for that? * How about putting the message to the operator on the _metrics.torproject.org_ relay page? * Would there be any reason for the messages not to be public? * If, somehow, a response - or an exchange - may be needed, why not put a general contact email address for answers, comments, etc. with, for example, the message ID as the subject? If the message is really personal, the message can be as simple as "Contact us at torproject(a)example.org ASAP." * Why not put an RSS feed to be able to fetch those messages automatically and regularly? * That way, you can also contact multiple operators based on their country, platform, etc. with the same message as well. This would be something similar to _weather.torproject.org_ but much simpler and without a need for any kind of registration. Are you sure all operators will follow, read, and act upon your messages? Not less than by sending an email. Much better than NOT having a valid email address at all. A _bad_ operator will be a _bad_ operator no matter what.

2 1

Next Tor Relay Operator online Meetup - Saturday, October 21 @ 19 UTC
by gus 23 Oct '23

23 Oct '23

Hello, The next Tor relay operator meetup will happen this Saturday, October 21 @ 19 UTC. Where: BBB - https://tor.meet.coop/gus-og0-x74-dzn No need for a registration or anything else, just use the room-link above. We will open the room 10 minutes before so you can test your mic setup. Note: BBB requires a browser that supports webRTC such as Firefox, Safari, or Chromium/Chrome. Agenda ------ https://gitlab.torproject.org/tpo/community/relays/-/issues/77 [Expected meeting duration: 60 to 90 minutes] - Announcements: - WebTunnel PT is available on Tor Browser 13 - (Update) Tor on Universities - Meta-proposal for new relay operator policies: https://gitlab.torproject.org/tpo/community/policies/-/blob/master/001-comm… - [Discussion] ContactInfo proposal Everyone is free to bring up additional questions or topics at the meeting itself. Please share with your friends, social media and other mailing lists! cheers, Gus -- The Tor Project Community Team Lead

1 2

PSA: Exit nodes on 0.4.7.x might see less traffic
by Georg Koppen 17 Oct '23

17 Oct '23

Hello everyone! As you might have noticed, Tor Browser 13 got released last week[1] which ships for the first time a Tor 0.4.8.x version (0.4.8.7) to our stable Tor Browser users. One of the main features in the 0.4.8.x series is Conflux, which allows traffic-splitting to improve Tor performance.[2] Given that we assume Tor Browser users are a large fraction of our overall Tor users and 0.4.8.7 deployed by Tor Browser results in pre-built Conflux circuits, there is a chance that exit nodes on 0.4.7.x might see less traffic over time. An easy way to avoid or fix that problem is an upgrade to the 0.4.8.x series. Georg [1] https://blog.torproject.org/new-release-tor-browser-130/ [2] https://gitlab.torproject.org/tpo/core/torspec/-/blob/288c5134ddb737e321cf3…

1 0

Relay Bandwidth Limit
by Dan 16 Oct '23

16 Oct '23

Hi all, I’ve been running my first relay for a few weeks now. The VPS provider I chose provides 5TB of bandwidth per month so I have set AccountingMax to “5 TB” and AccountingStart to

6 7

snowflake prometheus metrics listen address
by Fran 03 Oct '23

03 Oct '23

Hey there, snowflake v2.6.1 offers a prometheus metrics endpoint `-metrics`.[1] Unfortunately I am unable to figure out how to let it listen to non-localhost address: tcp LISTEN 0 4096 127.0.0.1:9999 0.0.0.0:* users:(("snowflake",pid=402248,fd=6)) Any ideas? Thansk! f. [1] https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…

2 2

Does Tor itself estimate how it can run as quota-utilizing as possible?
by telekobold 01 Oct '23

01 Oct '23

Hello together, today I apparently discovered an interesting feature of Tor I wasn't aware of: I'm running two relays at a large provider's data center having 20TB/month free outgoing traffic for each relay. However, this quota is often exhausted before the end of a month. In order to provide the Tor project with some bandwidth all the time, I configured "AccountingMax 20 TB" and "AccountingStart month 1 00:00" and, for the last few months, I used to switch off one of the relays on the first of a month and turn it on again a few days after the beginning of the month, so that one of the two relays is running all the time. I also connected the two relays using the "MyFamily" flag. Until last month, each of the relays simply continued to run after the end of the month. Today, however, I wondered why one of the relays shut itself down apparently which did not change after a restart. A look into /var/log/tor/notices.log provided the following entries: Oct 01 16:58:29.000 [notice] Configured hibernation. This interval began at 2023-10-01 00:00:00; the scheduled wake-up time is 2023-10-05 06:06:25; we expect to exhaust our quota for this interval around 2023-10-29 04:23:25; the next interval begins at 2023-11-01 00:00:00 (all times local) [...] Oct 01 16:58:49.000 [notice] Commencing hibernation. We will wake up at 2023-10-05 06:06:25 local time. Oct 01 16:58:49.000 [notice] Going dormant. Blowing away remaining connections. So apparently Tor learned from my behavior and calculated itself when to turn itself off and on again in order to use as much quota as possible based on the bandwidth used and/or some other metrics so I don't have to do this manually in future? Kind regards telekobold

2 2

Bridge with iat-mode=2 very slow
by Split 28 Sep '23

28 Sep '23

Hello everyone! I run the obfs4 bridge, in the parameters I specify to use iat-modr=2. As a result, the bridge is VERY, VERY SLOW. Connection speed is on average 100 kb/sec. When I remove the iat-mode=2 parameter, the speed becomes 8-10 times higher. I checked the processor load, it is at 3%, the problem is unlikely to be with the processor, the RAM load is at 20%. I can't figure out if this is expected behavior or if the speed drop is too significant. Please tell me, is this the normal maximum speed of the bridge with iat-mode=2 or can it be increased somehow?

3 2

Tor Weather : Node-Flag [Guard] Alert
by denny.obreham＠a-n-o-n-y-m-e.net 27 Sep '23

27 Sep '23

I received the following message from Tor Weather. According to Tor Metrics, this exit relay still has no Guard flag. Another - slightly more recent - exit relay (25FC41154DCB2CAE3ABD74A8DFCD5B90D2CFFD57) is on the same server and IP, and still has the Guard flag (although with 0% guard probability). Should I do something with this info? Denny On 09/26/2023 06:31 PM weather(a)torproject.org wrote .. > > > Hi, > > We have detected that the node - 3B85067588C3F017D5CCF7D8F65B5881B7D4C97C associated > with your subscription has lost the Guard flag > for more than 1hr(s). This may impact the performance of your service. > > Thank You!

2 1

Grafana dashboards
by Toralf Förster 16 Sep '23

16 Sep '23

Yesterday I stumbled together 2-3 dashboards [1] for Tor relay(s), Tor Snowflake(s) and the DDoS solution [2]. Feedback is welcome. [1] https://github.com/toralf/torutils/tree/main/dashboards [2] https://github.com/toralf/torutils/tree/main -- Toralf

1 0

Metrics
by BridgeOverStyx 08 Sep '23

08 Sep '23

My bridge styxVortex is up and running. I know this because the Nyx monitor shows activity. However, a search of metrics.torproject.org shows it down. It has been in this state for at least a month. Do you have any suggestions of what could be the possible cause of this? I am using pfblockerng on my network, but the machine that is running Tor bridge is not filtered by it. I do have a couple of TOR feed enabled in pfblockerng but only incoming traffic is filtered. I have no idea how the bridge stats are passed to metrics.torproject.org so it is very challenging for me to tamp down on the cause. Any suggestion, at this point, will be helpful. Sent with [Proton Mail](https://proton.me/) secure email.

6 9

Quick bugfix sharing regarding obfs4 malfunctioning
by telekobold 07 Sep '23

07 Sep '23

Hi, I just want to share some quick bugfix with you (sorry if this is obvious to you or has been written somewhere else). Suddenly, I got the following error messages on my two bridges running on Debian 11 appearing in the logs (in /var/log/tor/notices.log and in the nyx output) every second until a restart: <timestamp> [warn] Managed proxy "/usr/bin/obfs4proxy" process terminated with status code 65280 <timestamp> [warn] Server managed proxy encountered a method error. (obfs4 listen tcp 0.0.0.0:443: bind: permission denied) <timestamp> [warn] Managed proxy '/usr/bin/obfs4proxy' was spawned successfully, but it didn't launch any pluggable transport listeners! When restarting the corresponding bridge, in the startup process the second and the third of the above warning messages again appeared in the logs. So obfs4 was suddenly not usable any more. Port 443 is not blocked in the bridge's firewalls. A bit research reveled that apparently, an automatic update set the systemd setting "NoNewPrivileges=no" in /lib/systemd/system/tor(a)default.service and tor@.service [1] back to yes, which caused the above issue. After setting it back and restarting, everything works fine now and instead of the warning messages mentioned above, the following message appears in the log again: <timestamp> [notice] Registered server transport 'obfs4' at '[::]:443' (Several places recommend to set the obfs4 port to 443 to get around restrictive firewalls, so I didn't want to set it to something else). Kind regards telekobold [1] http://xmrhfasfg5suueegrnc4gsgyi2tyclcy5oz7f5drnrodmdtob6t2ioyd.onion/relay…

3 2

(Last call) Bridges running obsolete Tor version (0.4.5.x) to be removed soon
by gus 05 Sep '23

05 Sep '23

Hi bridge operators, Serge, the Bridge Authority is about to update their Tor version to 0.4.8.5 and it will reject bridges running the Tor version 0.4.5.x. Please upgrade your bridge if you're running an outdated version (0.4.5.x) ASAP. List of outdated bridges: https://metrics.torproject.org/rs.html#search/type:bridge%20version:0.4.5%20 Thanks for helping censored users to bypass censorship! cheers, Gus -- The Tor Project Community Team Lead

2 1

relayor v23.2.0 is released
by nusenu 28 Aug '23

28 Aug '23

Hi, relayor v23.2.0 is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… This release includes new prometheus alert rules so you do not forget to renew your relay certificates before they expire. This feature requires tor version 0.4.8 though which is unfortunately not yet available on deb.torproject.org stable repos. It also includes rules that alert you if your exit relay has an unhealthy DNS timeout fraction or if your relay is dropping onionskins for at least 15 minutes. Changelog: https://github.com/nusenu/ansible-relayor/releases/tag/v23.2.0 kind regards, nusenu -- https://nusenu.github.io

1 0

Exit Relays: What is your DNS timeout rate?
by nusenu 26 Aug '23

26 Aug '23

Hi, the upcoming relayor release will contain new prometheus alert rules that should help operators detect/mitigate/prevent some common operational issues. One of these rules will alert on high DNS timeout rates [1] on exit relays that should be investigated and resolved to improve the Tor Browser experience for users. To define the default alert threshold it would be relevant to know current timeout rates by multiple exit operators. So if you feel up to it you can send me (off-list) your current timeout rates (30 day graph): If you run tor exits with relayor and MetricsPort enabled you can use these Prometheus queries: timeout percentage by server: (sum by (instance)(rate(tor_relay_exit_dns_error_total{reason="tor_timeout"}[15m])))/(sum by (instance)(rate(tor_relay_exit_dns_query_total[15m])))*100 DNS query rate: sum by (instance)(rate(tor_relay_exit_dns_query_total[15m])) If you run exits without relayor you can use these queries: (sum by (job)(rate(tor_relay_exit_dns_error_total{reason="tor_timeout"}[15m])))/(sum by (job)(rate(tor_relay_exit_dns_query_total[15m])))*100 sum(rate(tor_relay_exit_dns_query_total[15m])) kind regards, nusenu [1] https://github.com/nusenu/ansible-relayor/commit/9b6937563ec0b41e6abb0217ed… -- https://nusenu.github.io

1 0

Wrong "first seen" flag for bridges at metrics.torproject.org
by telekobold 23 Aug '23

23 Aug '23

Hi together, I have an issue regarding the "first seen" flag at metrics.torproject.org: It is definitely wrong for my two bridges - both dates are much too close in the past. For one of the bridges, it seems to correspond to the last signing key renewal, for the other bridge, it seems to correspond to the penultimate signing key renewal. Has anyone observed similar behavior for its relay? (I found it meaningful to first ask here before creating an issue at [*]). [*] https://gitlab.torproject.org/hiro/onionoo/-/issues Kind regards, telekobold

3 2

Tor-Bridge
by tor＠pqpera.xyz 19 Aug '23

19 Aug '23

Possible compression bomb; abandoning stream. <- Happened to my server for 2h straight. Should I take any measures against that? Bridge is obsf4 with fingerprint: 2EA91C1415C421424BB478A55790E655627DE366.

2 1

Tor Relay in Kubernetes cluster
by Daniel Nikoloski 18 Aug '23

18 Aug '23

Hi all, Is anyone running Tor relay in k8s cluster? I am trying for a few days but It does not come alive. My servers are not behind a firewall, should be and are accessible, I run two bare-metal servers in Contabo. 1 master 1 node. Docker image and helm chart that use; https://gitlab.com/nikoloskid/tor-server The logs I get; > Aug 05 21:04:55.000 [notice] Now checking whether IPv4 ORPort 38.242.233.101:32150 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) > Aug 05 21:24:45.000 [warn] Your server has not managed to confirm reachability for its ORPort(s) at 38.242.233.101:32150. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports > > , address, /etc/hosts file, etc. When i try telnet it is open to the internet > telnet 38.242.233.101 32150 > Trying 38.242.233.101... > Connected to 38.242.233.101. > Escape character is '^]'. You can see the service here; https://gitlab.com/nikoloskid/tor-server/-/raw/helm-chart-tor-relay/tor-ser… /etc/tor/torrc; > Nickname icebergk8s > Address 38.242.233.101 > ContactInfo nikoloskid(a)pm.me > RelayBandwidthRate 3.5MB > RelayBandwidthBurst 5MB > MaxAdvertisedBandwidth 5MB > ORPort 9001 NoAdvertise IPv4Only > ORPort 32150 NoListen IPv4Only > SocksPort 0 > ExitPolicy reject *:* > User debian-tor > DataDirectory /var/lib/tor Lep pozdrav / Best Regards, Daniel Nikoloski

2 1

Tor Relay Operator meetup @ CCCamp 2023 - Saturday 19th @ 7pm
by gus 17 Aug '23

17 Aug '23

Hello, The Tor Relay Operator Meetup - Chaos Communication Camp-2023[1] will happen at Bornhack (Cold North Village)[2] on Saturday, August 19th at 7pm (local time). After the meetup, we invite everyone to stay and have beer and drinks at Bornhack. Please spread the message. We have Tor stickers for you! :) Gus [1] https://events.ccc.de/camp/2023/infos/ [2] Coordinates: 53.0314175, 13.3065457 https://map.events.ccc.de/camp/2023/map/#20/53.03143/13.3066 -- The Tor Project Community Team Lead

2 4

WebTunnel: What ASNs/networks work best?
by tor-home at encryptfirst.com 17 Aug '23

17 Aug '23

When running a WebTunnel bridge, what types of IPs are better for serving requests? My background is with self-hosted home-lab type of setups. There are a number of different ways for homelabs to accept inbound https connections. A few examples: - Forward a port on a home router. - Rent a cloud VM/VPS and tunnel a port from the VPS's IP. - Have a CDN tunnel/forward requests. - VPN hybrid solutions like Tailscale Funnel. Are any of these better than others for hosting a WebTunnel bridge? Should cloud provider IPs be preferred over residential IPs, for example, considering that is where most web servers are hosted? Are large CDNs preferred over individual cloud VMs? Is it better to use a different IP for WebTunnel than the IP that runs the OR port (i.e. host OR port on home IP and WebTunnel from a cloud-based IP)? I'm mainly asking to determine which way helps the broadest number of Tor users. And which is less likely to be blocked in the future. What are the best practices? PS: Thanks for the webtunnel-bridge Docker image and the documentation on how to run it. It was very helpful and made setup easy.

4 4

Running an exit relay in Italy
by Eldalië 17 Aug '23

17 Aug '23

Hello there and thanks everyone for your answers to my message about middle relay blocking. Reading them I feel trying to solve the blacklisting of my IP would be overkilling. Since I have a chance to get a cheap VPS, I will try to migrate the relay on it. And since the relay would be on a dedicated IP, I'm thinking about making it an exit. Of course I must consider the law, and I'd like to read some references and listen about experiences from other operators before seeking professional (expensive, I guess) legal advice. My concerns are the following, but I would appreciate any other thoughts as well. The relay would be in Italy so Italian and EU laws apply. 1. Would I bear any responsibility for the use of the relay? I'm aware of the "mere conduit" concept (that is applied in the EU too) but Italy may have some crappy additional law I'm not aware of. 2. Would I be subject to any data retention or data monitoring obligation? 3. Would I be subject to any user identification obligation? 4. Would I risk the police knocking on my door even if the relay runs on a datacenter and not on my home network? Thanks, Eldalië -- Eldalië My private key is attached. Please, use it and provide me yours!

2 1

(EVENT) Tor Relay Operator Meetup - June 24, 2023 @ 18.00 UTC
by gus 10 Aug '23

10 Aug '23

Hello, The next Tor Relay Operator Meetup will happen on June 24, 2023, at 18.00 UTC. We're working on the agenda here: https://pad.riseup.net/p/tor-relay-op-meetup-june-keep onionsite: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor… Feel free to add other topics to the agenda. WHERE Room link: https://tor.meet.coop/gus-og0-x74-dzn Registration No need for a registration or anything else, just use the room-link above. We will open the room 10 minutes before so you can test your mic setup. Please share with your friends, social media and other mailing lists! cheers, Gus -- The Tor Project Community Team Lead

5 7

short conntrack DDoS attack
by Toralf Förster 09 Aug '23

09 Aug '23

Few days ago the throughput of my Tor relay went down to nearly zero for about 3 minutes. It turned out that the reason (maybe) was a change here in my iptables rules. Especially I switched these 2 lines: iptables -A INPUT -m conntrack --ctstate INVALID -j DROP iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT and run then few hours later into problems. And switched back ofc. An explanation for the dropdown was given in [1]. Given that the explanation is right: How is the Tor application harmed if an attacker mangles packets so that the state of them are INVALID for the conntrack module but they do pass the RELATED,ESTABLISHED rule ? [1] https://forums.gentoo.org/viewtopic-p-8798034.html -- Toralf

2 1

Re: [tor-relays] Middle relay IP blocking
by torserver 08 Aug '23

08 Aug '23

Roger, I had the same problem with 3 financial websites blocking my IP address while running a middle relay. Exactly 5 days after stopping the relay these sites can be reached again. They probably use the same mechanism, visible in the TPRB Firefox plug-in. I run my home relay on a low energy consuming Raspberry Pi. Why is there no perfectly detailed instruction to install a relay on the Raspberry? With its built-in VNC it can be managed by SSH and remote desktop perfectly. Then there is no need for data congestion on a few cheap providers. One Watt power consumption only costs 3 Euros a year. Snowflake almost uses no data with a few occasional users. I 'd like to use my 100 Megabits more efficient. Regards, me. > Date: Tue, 8 Aug 2023 02:32:03 -0400 > From: Roger Dingledine <arma(a)torproject.org> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Middle relay IP blocking > Message-ID: <ZNHhY1rj8rQAId0y(a)nogrod.csail.mit.edu> > Content-Type: text/plain; charset=us-ascii > > On Mon, Aug 07, 2023 at 11:28:32PM +0300, s7r wrote: > > While all the above is true, a thing to remember is to make sure we don't > > end up all renting too many VPS'es or dedicated servers in the same places / > > same AS numbers - we need network diversity, it is a very important factor, > > more AS numbers, more providers, more physical locations, etc. So, running > > at home is super good and recommended from this perspective, provides us > > with the diversity we need, however not being to login to online banking to > > pay an electricity bill because of a middle relay is also way too annoying.. > > however who can afford the hassle should definitely run a middle relay or > > bridge at home > > Yes, exactly this. If you are interested in running a non-exit relay at > home, and you can tolerate the hassles from occasionally finding that > some service doesn't want to hear from you, then you are definitely > helping the diversity of the Tor network. > > Having the Tor traffic concentrated at a few cheapo providers like Hetzner > and OVH is not only scary in the sense that too much traffic goes through > too few cables, but it's also scary because it increases the appeal for > somebody to attack those few companies, either by breaking into their > infrastructure to watch traffic or through more traditional insider > threats like getting an employee there to help them monitor traffic. > > The internet already has uncomfortably many bottlenecks -- too few > undersea cables, too few Content Distribution Networks (CDNs), too few > app stores, etc. > > > (even Exit relay, I do run an Exit relay at my office place > > and I had one police visit in like 8 years or so). > > Follow this advice only with great caution. :) Many people happily > run their exit relay from their home, but it only takes one fresh new > cybercrime detective (trying to make a name for himself by kicking down > a door at 7am, and with no idea what Tor is) to ruin your day. > > --Roger > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ------------------------------ > > End of tor-relays Digest, Vol 151, Issue 9 > ******************************************

2 2

Middle relay IP blocking
by Eldalië 08 Aug '23

08 Aug '23

Hello there! I've been running for over 1.5 year a middle relay on an IP address I also use to browse, withous issues. However it's now some weeks since many websites that always refused tor traffic started to also refuse normal traffic from my IP. I suppose this is related to the relay, because I don't run any other "suspect" service on this IP and when I change it the problem is gone for a few hours. My guess is that some widely used black list started including middle relay IPs, but I have no proofs. Has anyone had similar experiences? Any thoughts on this? Thanks, Eldalië -- Eldalië My private key is attached. Please, use it and provide me yours!

12 15

Help Turkmens to bypass Internet censorship: run an obfs4 bridge!
by gus 02 Aug '23

02 Aug '23

Dear Relay operators community, The parliamentary elections in Turkmenistan are coming up very soon on March 26th[1], and the Turkmen government has tightened internet censorship and restrictions even more. In the last few months, the Anti-censorship community has learned that different pluggable transports, like Snowflake, and entire IP ranges, have been blocked in the country. Therefore, running a bridge on popular hosting providers like Hetzner, Digital Ocean, Linode, and AWS won't help as these providers' IP ranges are completely blocked in Turkmenistan. Recently, we learned from the Anti-censorship community[2] and via Tor user support channels that Tor bridges running on residential connections were working fine. Although they were blocked after some days or a week, these bridges received a lot of users and were very important to keep Turkmens connected. How to help Turkmens to access the Internet =========================================== You can help Turkmens to access the free and open internet by running an obfs4 Tor bridge! But here's the trick: you need to run it on a residential connection -- you won't need a static IPv4 --, and it would ideally be run on more robust hardware than just a Raspberry Pi (although that can help, we have found they can get overloaded). You can set up an obfs4 bridge by following our official guide: https://community.torproject.org/relay/setup/bridge/ After you setup a new bridge, you can share your bridge line with the Tor support team at frontdesk(a)torproject.org, and we will share it with users. A complete bridge line is composed of: IP:OBFS4_PORT FINGERPRINT cert=obfs4-certificate iat-mode=0 Check this documentation to learn how to share your bridge line: https://community.torproject.org/relay/setup/bridge/post-install/ Just sharing your bridge fingerprint is not the best, but it's fine. You can read more about censorship against Tor in Turkmenistan here: - https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… - Snowflake blocked: https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/iss… Thank you for your support in helping to keep the internet free and open for everyone. Gus [1] https://en.wikipedia.org/wiki/2023_Turkmen_parliamentary_election [2] https://ntc.party/c/internet-censorship-all-around-the-world/turkmenistan/17 https://github.com/net4people/bbs/issues/80 -- The Tor Project Community Team Lead

7 24