[tor-relays] Storing ed25519_master_id_secret_key[_encrypted] on a smartcard?
Dear fellow relay operators, currently, I'm operating a Tor relay (Middle/Guard) and a Tor Bridge. Offline keys [1],[2] are a good way to secure a Tor relay, but I'm wondering if there is a standard way or something like a hacking guide how to store your ed25519_master_id_secret_key[_encrypted] on a smartcard or hardware token like a Nitrokey or Yubikey? This would even be more secure than storing it on a "normal" USB device. Unfortunately I have not found much about this on the internet. Kind regards telekobold [1] https://support.torproject.org/relay-operators/offline-ed25519/ [2] https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorRelaySecurity/OfflineKeys ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Storing ed25519_master_id_secret_key[_encrypted] on a smartcard?
After being encouraged in today's relay operators meetup to follow up on this: Anyone who has experiences with that? On 21.02.23 13:18, telekobold wrote: > Dear fellow relay operators, > > currently, I'm operating a Tor relay (Middle/Guard) and a Tor Bridge. > > Offline keys [1],[2] are a good way to secure a Tor relay, but I'm > wondering if there is a standard way or something like a hacking guide > how to store your ed25519_master_id_secret_key[_encrypted] on a > smartcard or hardware token like a Nitrokey or Yubikey? This would even > be more secure than storing it on a "normal" USB device. > > Unfortunately I have not found much about this on the internet. > > Kind regards > telekobold > > [1] https://support.torproject.org/relay-operators/offline-ed25519/ > [2] > https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorRelaySecurity/OfflineKeys > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new exit relay
Hi, please also note the corresponding blogpost from arma (Roger Dingeldine): https://blog.torproject.org/lifecycle-of-a-new-relay/ Kind regards telekobold On 10.04.23 07:14, Sandro Auerbach wrote: > As long as your configuration is correct, it still has to go through the > warm-up phase like any relay. > You don't have a stable flag yet either.So just let it run for a week > and just watch it. > > > Sandro > > > > Am 06.04.23 um 11:50 schrieb Linux-Hus Oni via tor-relays: >> Hi to all, i have setup a new tor exit relay with name TorGate, but there >> are only a few kb trafic on this? >> the flags are exit,running,v2dir,valid and its also messured. >> there are no warns or errors in the tor console >> any ideas why? >> regards Lin >> >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Configuring key expiration warning messages?
Hi everyone, I'm using OfflineMasterKey 1 for my Tor bridge, hosting and renewing the long-term identity key on a Tails USB stick. I observed that Tor starts printing warning messages to /var/log/tor/notices.log 24 hours before the intermediate key expires. My question is if there is a flag that could be set in the torrc file to start printing these warning message more than 24 hours before the expiration time, possibly even with outputting the exact expiration time? If there isn't such an option, does anyone happen to have a script ready for this (before I start trying to implement something like this myself)? Kind regards telekobold ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Question regarding bandwidth ratio on bridges.torproject.org and a few further, small, (probably related) questions
Hello together, I'm operating two Tor bridges. When calling bridges.torproject.org, for one of the bridges (set up in March, 2023), there are three outputs: - obfs4: functional - a bandwidth ratio - a "last tested" entry. But for my second bridge (set up at the beginning of June 2023), bridges.torproject.org does not output a bandwidth ratio. What does this missing bandwidth ratio output mean, since everything else seems to be normal? When starting nyx on the relays, I see connections there (even more on the bridge with the missing bandwidth ratio output), I can connect to both bridges using the Bridge's IP addresses and ORPorts via Tor browser, and metrics.torproject.org also outputs an advertised bandwidth, which is even much higher (4.87 MiB/s at the moment) than for my other bridge (1.43MiB/s at the momemt) for which bridges.torproject.org outputs a bandwidth ratio. The bridges run on virtual servers at the same hoster, but in two different countries. Nothing else runs on these virtual servers. I am honestly not quite sure to what extent the fingerprint of the bridge is information worth protecting, or whether only the port and IP address need to be protected. By the way, I also don't understand why my two bridges don't have a higher advertised bandwidth - currently, it's 4.87MiB/s for one and 1.43MiB/s for the other relay. I never got the fast flag for either bridge yet, in contrast to my two "normal" relays. On both servers, at least 1.6GiB/s is available, and a monthly data throughput of several terabytes. As a further issue, nyx doesn't output (in constrast to my two other relays) - not sure if this is a known issue. And, as a last issue, I didn't specify a distribution mechanism for my bridge, in the hope that the most suitable mechanism will be selected automatically. Initially, for one of my bridges (the one for which bridges.torproject.org outputs a bandwidth ratio) the bridge was assigned distribution mechanism "Moat". But suddenly, "None" is displayed under distribution mechanisms at metrics.torproject.org, which means that apparently the bridge is no longer distributed. What could be the reason that the distribution mechanism suddenly changed? Kind regards telekobold ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Wrong "first seen" flag for bridges at metrics.torproject.org
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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Help Turkmens to bypass Internet censorship: run an obfs4 bridge!
Hi, just a question out of interest: If there is such a massive blocking of Tor in Turkmenistan, how can it be that there seem to have been measured between 1500 and 1 direct connections with Tor from Turkmenistan this year [1]? The curve has had a very sharp drop to almost zero recently, but I would have expected it to be close to zero all along given the reports. The number of clients directly connected to Tor seems to be even comparable to the number of clients connected via bridges for the last months [2]. Kind regards telekobold [1] https://metrics.torproject.org/userstats-relay-country.html?start=2023-01-01&end=2023-07-22&country=tm [2] https://metrics.torproject.org/userstats-bridge-country.html?start=2023-01-01&end=2023-07-22&country=tm On 21.07.23 18:07, gus wrote: Hi, New update: In the last few weeks, internal political conflicts and other events[1] in Turkmenistan have led to another wave of censorship on Tor and anti-censorship tools. Tor bridges have been one of the few free alternatives for people in Turkmenistan to connect with the world and access the open Internet. If you have access to an IP range that has never seen the light of day, a stable residential connection, or access to your university network, you can help thousands of people connect to the internet in Turkmenistan. Tor bridges running on residential connections, on dynamic IPv4 address, or on unblocked IP ranges are effective, but are regularly discovered and blocked by censors, thus making us to call for new bridges. These bridges must run on specific obfs4 ports: 80, 8080, or 443. See below the example of torrc for your bridge. If it's your first time running a bridge, please follow our official guide: <https://community.torproject.org/relay/setup/bridge/>. Finding an IP range that is unblocked-in the country is not easy. However, bridges in universities and IP ranges in US have been of great help to people in Turkmenistan. Please note that it's not possible to run IPv6-only bridges and Turkmenistan has a very small adoption of IPv6. If you run a bridge to help people in Turkmenistan, send your bridge line to frontd...@torproject.org. We will share your bridge with people that really need it! A bridge line is composed of: IP:OBFS4_PORT FINGERPRINT cert=obfs4-certificate iat-mode=0 If you need help to build your bridge line, please check the official guide: https://community.torproject.org/relay/setup/bridge/post-install/ ## Other Pluggable Transports - Snowflake has been blocked in the country since 2021: - STUN servers are running on blocked IP ranges - When we found an available STUN server, it didn't find a proxy to match (probably because of the TM's IP range rules). For more information, see this ticket[2]. - Meek[3] (domain fronting) is one of the few techniques that consistently works, but with reduced speed. While there is a dedicated bridge for TM, its cost is high. - Conjure[4] was successfully tested, but more development hours are still needed for its maintenance and stabilization. Currently it is only available on Tor Browser Alpha and some other Tor powered apps. - WebTunnel[5] could potentially work, but like obfs4 bridges, it depends on whether the website is hosted on an IP range that is not blocked in Turkmenistan. ## Research and other resources If you would like to learn more about censorship in Turkmenistan, ntc.party is a great resource (posts in Russian): https://ntc.party/c/internet-censorship-all-around-the-world/turkmenistan/17 And this paper (2023) about measuring Internet censorship in TM: "Measuring and Evading Turkmenistan's Internet Censorship: A Case Study in Large-Scale Measurements of a Low-Penetration Country" (Sadia Nourin, Van Tran, Xi Jiang, Kevin Bock, Nick Feamster, Nguyen Phong Hoang, Dave Levin) 2023-04-17 https://arxiv.org/abs/2304.04835 https://tmc.np-tokumei.net/ ## Tor metrics You can follow a rough estimate of Tor usage in Turkmenistan here: - https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-04-21&end=2023-07-20&country=tm - https://metrics.torproject.org/userstats-relay-country.html?start=2023-04-21&end=2023-07-20&country=tm&events=off ## torrc example BridgeRelay 1 ORPort 127.0.0.1:auto AssumeReachable 1 ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:8080 ExtORPort auto Nickname helptm ContactInfo Log notice file /var/log/tor/notices.log # If you set BridgeDistribution none, please remember to email # your bridge line to us: frontd...@torproject.org BridgeDistribution none Thank you, Gus Notes [1] https://www.rferl.org/a/turkmenistan-top-officials-fired/32507072.html https://www.reuters.com/world/asia-pacific/turkmenistan-opens-futuristic-city-dedicated-leader-2023-06-29/ [2] https://gitlab.torproject.org/tpo/anti-censorship/censorsh
Re: [tor-relays] Help Turkmens to bypass Internet censorship: run an obfs4 bridge!
Hi Gus, thank you for the clarification. Kind regards telekobold On 22.07.23 17:12, gus wrote: Hi, Great question. First, it is important to highlight that sometimes censorship is not implemented uniformly across all ISPs in a country. For example, see Tor Metrics in Russia: - https://metrics.torproject.org/userstats-relay-country.html?start=2023-04-23&end=2023-07-22&country=ru&events=off - https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-04-23&end=2023-07-22&country=ru And sometimes you'll find some interesting metrics anomalies, e.g., in China: - Vanilla Tor connections spikes: https://metrics.torproject.org/userstats-relay-country.html?start=2023-04-23&end=2023-07-22&country=cn&events=off - Bridge users: https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-04-23&end=2023-07-22&country=cn Second, in Turkmenistan case, it appears that one ISP (AGTS) had different censorship rules compared to their main ISP, Turkmentelecom. As a result, AGTS clients were able to use tools like tor-relay-scanner[1] to find unblocked Tor relays and use them as Tor "vanilla OR bridges" to bypass the block. But, this workaround was blocked in AGTS/Turkmenistan last week and it is no longer effective. Gus [1] https://github.com/ValdikSS/tor-relay-scanner On Sat, Jul 22, 2023 at 03:47:18PM +0200, telekobold wrote: Hi, just a question out of interest: If there is such a massive blocking of Tor in Turkmenistan, how can it be that there seem to have been measured between 1500 and 1 direct connections with Tor from Turkmenistan this year [1]? The curve has had a very sharp drop to almost zero recently, but I would have expected it to be close to zero all along given the reports. The number of clients directly connected to Tor seems to be even comparable to the number of clients connected via bridges for the last months [2]. Kind regards telekobold [1] https://metrics.torproject.org/userstats-relay-country.html?start=2023-01-01&end=2023-07-22&country=tm [2] https://metrics.torproject.org/userstats-bridge-country.html?start=2023-01-01&end=2023-07-22&country=tm On 21.07.23 18:07, gus wrote: Hi, New update: In the last few weeks, internal political conflicts and other events[1] in Turkmenistan have led to another wave of censorship on Tor and anti-censorship tools. Tor bridges have been one of the few free alternatives for people in Turkmenistan to connect with the world and access the open Internet. If you have access to an IP range that has never seen the light of day, a stable residential connection, or access to your university network, you can help thousands of people connect to the internet in Turkmenistan. Tor bridges running on residential connections, on dynamic IPv4 address, or on unblocked IP ranges are effective, but are regularly discovered and blocked by censors, thus making us to call for new bridges. These bridges must run on specific obfs4 ports: 80, 8080, or 443. See below the example of torrc for your bridge. If it's your first time running a bridge, please follow our official guide: <https://community.torproject.org/relay/setup/bridge/>. Finding an IP range that is unblocked-in the country is not easy. However, bridges in universities and IP ranges in US have been of great help to people in Turkmenistan. Please note that it's not possible to run IPv6-only bridges and Turkmenistan has a very small adoption of IPv6. If you run a bridge to help people in Turkmenistan, send your bridge line to frontd...@torproject.org. We will share your bridge with people that really need it! A bridge line is composed of: IP:OBFS4_PORT FINGERPRINT cert=obfs4-certificate iat-mode=0 If you need help to build your bridge line, please check the official guide: https://community.torproject.org/relay/setup/bridge/post-install/ ## Other Pluggable Transports - Snowflake has been blocked in the country since 2021: - STUN servers are running on blocked IP ranges - When we found an available STUN server, it didn't find a proxy to match (probably because of the TM's IP range rules). For more information, see this ticket[2]. - Meek[3] (domain fronting) is one of the few techniques that consistently works, but with reduced speed. While there is a dedicated bridge for TM, its cost is high. - Conjure[4] was successfully tested, but more development hours are still needed for its maintenance and stabilization. Currently it is only available on Tor Browser Alpha and some other Tor powered apps. - WebTunnel[5] could potentially work, but like obfs4 bridges, it depends on whether the website is hosted on an IP range that is not blocked in Turkmenistan. ## Research and other resources If you would like to learn more about censorship in Turkmenistan, ntc.party is a great resource (posts in Russian): https://ntc.party/c/internet-censorshi
Re: [tor-relays] Middle relay IP blocking
Hi, On 03.08.23 14:22, Logforme wrote: My "solution" for now is to use my phone's internet sharing when I have to contact these sites. Since it only is a few sites which I contact rarely this works, but as more and more sites outsource their security to third parties I expect this to be a growing problem. Eventually I might no longer be able to run a relay. instead of turning down your relay, you could change it to a cloud hoster. I e.g. would suggest the German provider Hetzner [*] - you have 20TB/month free traffic for only a few euros. Since the IP address of your relay is publicly known anyway, it also doesn't matter as much as with a bridge if the relay is running at a cloud provider (e.g. regarding the situation in Turkmenistan). The disadvantage is, of course, less diversity in the number of networks in which the relays are distributed. Kind regards telekobold [*] https://www.hetzner.com/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Meetup @ CCCamp 2023
Hi, On 26.06.23 23:44, gus wrote: - Tor Relay Operators meetup @ CCCamp 2023. CCCamp (https://events.ccc.de/camp/2023/infos/) is taking place near Berlin, Germany, in August. Ping gus or other tor people if you want to help. unfortunately, I couldn't find any information about the planned meetup in the Fahrplan [*]. Is there already more detailed information about where and when? Kind regards telekobold [*] https://events.ccc.de/camp/2023/hub/camp23/en/fahrplan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Metrics
Hi, On 06.09.23 09:25, gus wrote: Have you tried to connect to your own bridge and see if it works? Here is how you build your obfs4 bridge line (note: it's your bridge fingerprint and not your hashed bridge fingerprint): https://community.torproject.org/relay/setup/bridge/post-install/ there seems to be a mismatch between the description linked above and the Tor browser UI to manually add a Tor bridge: If one starts the Tor browser, click on "Configure Tor connections" and then on "Add a Bridge Manually" (seems to be the only possibility to test your own Bridge directly in the Tor browser), there is only the option to provide the bridge's IP address and the obfs4 port, but not, as mentioned in the description linked above the fingerprint and the obfs4 certificate. When I try to add the fingerprint and the obfs4 certificate of my bridges, no connection is established. So, where is the advantage on additionally providing the fingerprint and the obfs4 certificate when connecting to Tor (I can imagine that it has something to do with authenticity)? And how can one do that using the Tor software respectively the Tor browser bundle? Kind regards telekobold ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Metrics
Hi gus, On 06.09.23 21:27, gus wrote: If you add just IP:ORPort (**ORPort** and not the OBFS4 Port) you have a "vanilla" Tor bridge: a bridge that doesn't obfuscate your Tor traffic. So it may not work in countries/ISPs doing DPI. To use your own obfs4 bridge, you need to build the "complete bridge line"[1]. cheers, Gus [1] https://gitlab.torproject.org/tpo/web/manual/-/issues/130 thank you for the clarification! To be honest, I indeed confused "ORPort" and "obfs4port" for a moment. Kind regards telekobold ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Quick bugfix sharing regarding obfs4 malfunctioning
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: [warn] Managed proxy "/usr/bin/obfs4proxy" process terminated with status code 65280 [warn] Server managed proxy encountered a method error. (obfs4 listen tcp 0.0.0.0:443: bind: permission denied) [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@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: [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/setup/bridge/debian-ubuntu/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Metrics
On 07.09.23 12:43, Anonforpeace via tor-relays wrote: What is the "complete" bridge line? Bridge obfs4 : cert= iat-mode=0 where PORT is the obfs4 port, not the ORPort. (When using IPv6, ADDRESS> must be in []). See also https://community.torproject.org/relay/setup/bridge/post-install/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Does Tor itself estimate how it can run as quota-utilizing as possible?
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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Does Tor itself estimate how it can run as quota-utilizing as possible?
Hi, thank you for your answer. But for me, it seems like your explanation at least does not fully apply in my case: One of my relays reaches its quota every month before the end of the month, but it restarts automatically at the beginning of a month using the settings below, and it did so also today. The behavior below, however, I observed with the other relay, which to my knowledge has *not* reached its quota - i only turned it on on the 16th of September. Another look to my log files: Sep 30 18:51:56.000 [notice] Heartbeat: Tor's uptime is 10 days 12:00 hours, with 76581 circuits open. I've sent 10328.97 GB and received 10137.37 GB. I've received 317665 connections on IPv4 and 39595 on IPv6. I've made 256147 connections with IPv4 and 74327 with IPv6. Sep 30 18:51:56.000 [notice] While not bootstrapping, fetched this many bytes: 257413413 (server descriptor fetch); 7200 (server descriptor upload); 13167379 (consensus network-status fetch); 3664081 (microdescriptor fetch) Sep 30 18:51:56.000 [notice] Heartbeat: Accounting enabled. Sent: 12375.74 GB, Received: 12185.16 GB, Used: 12375.77 GB / 20480.00 GB, Rule: max. The current accounting interval ends on 2023-10-01 00:00:00, in 5:08 hours. [...] Oct 01 00:00:00.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 00:00:01.000 [notice] Commencing hibernation. We will wake up at 2023-10-05 06:06:25 local time. Oct 01 00:00:01.000 [notice] Going dormant. Blowing away remaining connections. Oct 01 00:00:01.000 [notice] Delaying directory fetches: We are hibernating or shutting down. Oct 01 00:00:14.000 [notice] Received reload signal (hup). Reloading config and resetting internal state. I also don't understand the difference between the "I've sent/received" and the "Sent:/Received:" lines which differ in their values by approx. 2TB each. More confusingly, after restarting the relay an hour ago for other maintenance, I got the following warning messages (there were no warn messages in the logs before October 01, 16:58): #:/var/log/tor# cat notices.log | grep warn Oct 01 16:58:49.000 [warn] parse error: Malformed object: missing object end line Oct 01 16:58:49.000 [warn] Unparseable microdescriptor found in download or generated string Oct 01 18:09:09.000 [warn] Problem bootstrapping. Stuck at 10% (conn_done): Connected to a relay. (No route to host; NOROUTE; count 1; recommendation warn; host 453D69BB809FC59ED0CAD5D8399C27BC06DEB424 at 109.250.99.118:9001) Oct 01 18:09:09.000 [warn] Problem bootstrapping. Stuck at 14% (handshake): Handshaking with a relay. (No route to host; NOROUTE; count 2; recommendation warn; host 13DB6CA2FCEFAEFD7551633BDDA215B32BC6E806 at 91.248.123.129:8443) Oct 01 18:09:09.000 [warn] 1 connections have failed: Oct 01 18:09:09.000 [warn] 1 connections died in state connect()ing with SSL state (No SSL object) Oct 01 18:09:11.000 [warn] Bad element "$C86F2844ED28274D15164E5897" while parsing a node family. Oct 01 18:09:11.000 [warn] Bad element "$F8C37E0A09713ABB2BF07FF11EFDDA08" while parsing a node family. Oct 01 18:09:11.000 [warn] parse error: Malformed object: missing object end line Oct 01 18:09:11.000 [warn] Unparseable microdescriptor found in download or generated string Oct 01 18:09:11.000 [warn] Bad element "$F62DF76750" while parsing a node family. Oct 01 18:09:11.000 [warn] Bad element "$86A" while parsing a node family. Kind regards telekobold On 01.10.23 20:16, trinity pointard wrote: Hi, When using AccountingMax, tor tries to guess how long in will take for it to use its quotas, and will decide deliberately to hibernate for some time at the start of the period. It does that so not every relay is working at its max capacity on the first of the month, and only the unmetered ones are left at the end of the month. What it does isn't always perfect, it can end up wasting some bandwidth if the relay starts too late to use its quota, or cause too many relays to be out of quota before the end of the month, so that there is less capacity at the end than at the start, but it works well enough. Also your relay didn't learn from your behavior, this is something every relay with AccountingMax does if it managed to use its full quota before. It's very nice of you to think of that and try to make your relay the most useful possible over time, but sadly it wasn't worth the trouble. Regards, trinity-1866a On Sun, 1 Oct 2023 at 19:54, telekobold wrote: 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 fr
[tor-relays] Tor relay operator meetups
Hi, will there be a Tor relay operators meetup @37C3 [*]? Also, there were apparently no meetups in November and December this year? Kind regards telekobold [*] https://events.ccc.de/congress/2023/infos/startpage.html ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Directory authorities not giving weight to a relay
On June 3, 2024 9:20:38 AM GMT+02:00, "Frank Lý via tor-relays" wrote: > In addition, the contact information provided in the `torrc` does not match > the email address you used to participate in the `tor-relays` mailing list. For all what I know, this shouldn't play a role. I'm also using different mail addresses in the contact info fields of my relays and on this mailing list for about one and a half year. Kind regards telekobold ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Archive key from deb.torproject.org was renewed!
Hi boldsuck, thank you for your messages and the explanations. To be honest, I wasn't aware that the GPG key has to be updated manually every two years. However, I still have a few comprehension questions: On 16.07.24 14:03, boldsuck wrote: wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null What exactly is the purpose of "gpg --dearmor" and of "tee" here? Why isn't is enough to just type wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc > /usr/share/keyrings/tor-archive-keyring.gpg ? I compared the output with and without the "gpg --dearmor" using diff, it is exactly the same. And the only effect of tee is that the binary output is also printed to the terminal. There is even something that is interpreted as a line break at the end of the binary .gpg file so that the terminal tries to execute "1;2c" which leads to an error. However, with the shortened command, everything also works without errors. >> apt-key -list /etc/apt/trusted.gpg.d/deb.torproject.org-keyring.gpg [...] > Sorry, above is the key that is installed by the package deb.torproject.org-keyring. > gpg --show-keys /usr/share/keyrings/tor-archive-keyring.gpg shows you the one imported via wget. On my relays (installed "the standard way" using the manuals at the torproject.org website), both commands output the same GPG key with the fingerprint A3C4 F0F9 79CA A22C DBA8 F512 EE8C BC9E 886D DD89 So, there seems to be no other Tor-related GPG key installed by the package deb.torproject.org-keyring, just the GPG key manually installed via the above wget command. And finally, it would be nice if one could check the fingerprint of this key on future physical Tor relay operators meetups like the one at the Chaos Communication Camp. I'm not even sure if wget does any background check based on a hierarchical certificate check of the TLS certificate of torproject.org. If the TLS connection would be somehow corrupted at the moment where one executed the wget command an attacker could corrupt the whole relay, according to my understanding. Or do I have an error in my thinking here? Kind regards telekobold ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
