Re: [tor-relays] We need much more bridges with obfs4 and iat-mode set to 1 or 2..barely can't find any.
I can dedicate 2 more IP’s from my network to this. You just want it to be obfs4 and iat-mode set to 2? Thanks, John C. > On Aug 24, 2022, at 2:35 AM, elise.tora...@web.de wrote: > > > As in the title, it took me over an hour to find one - for my security > requirements, the timing and sometimes, packet size obfuscation, is very > important. > > Now this might sound a bit like sarcasm, but I also think that we should > harden the https://bridges.torproject.org page, just a captcha and not > delivering new bridges to the same IP is a bit weak, in my opinion. > > Perhaps extend that block to an entire /16 range, or require some > computational power to be used up (could be easily implemented in JavaScript) > first. > > The last suggestion would also eliminate bots that scrape bridge addresses > using plaintext clients entirely, at least until someone builds a chromium / > (insert arbitrary browser engine here) bot. > > I know this is a cat and mouse game, but the bridge page should be as secure > as possible. > > For example: I wouldn't mind waiting 5-15 minutes to get a list of 3 bridges > (optionally, with a button that says, iat-mode non-zero only, but we need to > harden more before implementing something like that), some government > agencies might be thrown off by this, along with the fact that they also only > have limited IP ranges. > > Thoughts? > ___ > 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] IPV6 address keeps changing every 2-3 days
Are you sure you are setting a private auto generated address that Ubuntu changes so that you can’t be tracked? Thanks, John C. > On Jan 19, 2022, at 1:49 AM, Quentin Campbell wrote: > > Hi, > > I'm running a non-exit relay on a home British Telecom broadband connection > (FTTC, 20Mb up/80Mb down). > > Its IP addresses (IPV4 & IPV6) are allocated dynamically. > > The IPV4 address can remain the same for weeks. However the IPV6 address > seems less stable and lasts no more than 2 or 3 days before changing. > > A consquence of this is that Tor Metrics (atlas) shows a lot of downtime for > the node. > > When I see that the node is down I restart the (UBUNTU) NetworkManager > although the host should pick up the new address eventually without doing > that? > > I would like to run a stable node with as little downtime as possible. Any > suggestions on how I might improve things; in particular can I automate the > checking and restart of the network/TOR whenever the IPV6 address changes? Do > I really need to do this? > > On that last point, I thought that TOR nodes handled more gracefully the > issue of dynamic address changes? Is there any source of info on this for > dynamic IPV6 addresses? > > Thanks, > > Quentin > > > ___ > 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] DNS Timeouts - I think the threshold for overload needs raising
Update your version of tor this is an old issue that has been fixed in the latest version. Thanks, John C. > On Jan 16, 2022, at 4:17 AM, AMuse wrote: > > > Hi all! > > I'm operating a TOR Exit on dedicated hardware. The load average is low > (0.07) and the network load is fine (120Mb/sec out of a 1Gb/sec link). > Connections aren't being dropped, and for all I can see things are fine. > > However, on the TOR Metrics relay search, my exit consistently shows as > "Overloaded" due to DNS failures. > > From my logs, I never go above 2% in DNS failures and from the debugging I've > done so far it looks like most of the failures are in IPv6 lookups not > returning an record because the destination site has no configured. > > Could whoever runs the "Overloaded" flag consider upping the overload limit > to 2% or so? Or, can we tune out ipv6 and ipv4 failures separately maybe? > > This was never an issue until I configured my relay for v6. > > > > === > > Jan 15 19:57:45.000 [notice] General overload -> DNS timeouts (65) fraction > 1.0619% is above threshold of 1.% > Jan 15 20:07:45.000 [notice] General overload -> DNS timeouts (67) fraction > 1.0124% is above threshold of 1.% > Jan 15 20:17:45.000 [notice] General overload -> DNS timeouts (71) fraction > 1.1275% is above threshold of 1.% > Jan 15 20:27:45.000 [notice] General overload -> DNS timeouts (94) fraction > 1.4003% is above threshold of 1.% > Jan 15 20:37:45.000 [notice] General overload -> DNS timeouts (72) fraction > 1.2000% is above threshold of 1.% > Jan 15 20:47:45.000 [notice] General overload -> DNS timeouts (75) fraction > 1.2517% is above threshold of 1.% > Jan 15 20:57:45.000 [notice] General overload -> DNS timeouts (70) fraction > 1.1605% is above threshold of 1.% > Jan 15 21:07:45.000 [notice] General overload -> DNS timeouts (92) fraction > 1.6028% is above threshold of 1.% > Jan 15 21:17:45.000 [notice] General overload -> DNS timeouts (73) fraction > 1.3290% is above threshold of 1.% > Jan 15 21:27:45.000 [notice] General overload -> DNS timeouts (73) fraction > 1.2907% is above threshold of 1.% > Jan 15 21:37:45.000 [notice] General overload -> DNS timeouts (65) fraction > 1.0095% is above threshold of 1.% > Jan 15 21:47:45.000 [notice] General overload -> DNS timeouts (83) fraction > 1.2635% is above threshold of 1.% > > ___ > 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] General overload -> DNS timeouts
Well, I have to say thanks to the update to tor 0.4.6.9 the DNS overload issue is gone. My consensus Weight went down sightly due to the constant overload flag. Lets see if time will help heal that. Good work so far. Thanks, John C. On 2021-12-21 07:39 AM, nusenu wrote: bobby stickel: It would be nice if we could make the DNS time out percentage threshold higher in our config file so Tor isn't reporting our exit relays has overloaded if you run debian and use deb.torproject.org packages, running apt update && apt upgrade should be your solution now since the stable repo has been updated to tor 0.4.6.9 and the experimental repo contains 0.4.7.3-alpha which also includes your desired change. kind regards, nusenu 0xB77A70C2.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] General overload -> DNS timeouts
I agree its kinda pointless if you know the issue already... Thanks, John C. On 2021-12-16 08:41 AM, nusenu wrote: To stop confusing operators it would make sense to remove the "This relay is overloaded since" banner from Relay Search for all tor versions prior to 0.4.6.9 and 0.4.7.3-alpha, no? kind regards, nusenu 0xB77A70C2.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] General overload -> DNS timeouts
Hello all, I would have to agree on this it appears that the DNS failure timeout is too low. I have more then enough bandwidth to host tor exit nodes, and my own unbound full recursive relay and yet i still get the timeout message 1-1.5%. Sometimes even weird amounts such as 40-50%. I have been working with a few people on this issue and nothing we have tried has fixed this. The other thing is that all other servers i run have no issue with DNS timeouts. It appears to only be a TOR issue. I would even say that some DNS queries that TOR makes are to taken down sites, fake sites or non-existent domains. Thanks, John C. +1 (216) XXX- On 2021-11-08 06:25 PM, Anders Trier Olesen wrote: Hi Ibex There's some discussion about this issue on #tor-relays. First of all, I actually don't think there's any problem with your Exit node. IMO 1.5% is expected and the current threshold is just too low (or the timeout too low). We're hosting some fairly high capacity exit nodes (around 100mbit/s each), generating about 100 DNS queries/sec in total. We're also seeing around 1.5% failed DNS queries. Here's what I think is going on: For some queries (1.5%?), the authoritative DNS servers for the requested domain are not responding. Recursive DNS resolvers are by default more patient than the Tor software. Eventually the recursive resolver will return a 'SERVFAIL' to Tor, but by then, Tor has already given up, and counts it as a timeout. One example of a domain that is currently (2021-11-08T23:40+01:00) failing to resolve because of its authoritative DNS servers being down is mzfgbh.com [2]. Try running `dig +trace +additional mzfgbh.com [2]` (for some reason, dig ignores the 'additional' section of one of the answers. Essentially the problem is that this query (and a few others) times out: `dig mzfgbh.com [2] @1.1.1.20 [3]`). On a related note, when this metric was introduced, we were seeing around 5-6% failed queries. The recursive DNS resolver we were using was hosted on the same IP as a guard node. Apparently many authoritative DNS servers block traffic from all Tor relays! The most extreme example of this I found, is that the authoritative DNS servers for the entire .by ccTLD (Belarus) are blocking DNS requests from guard and exit nodes. This resulted in all .by queries timing out! By moving our recursive DNS resolver to an IP not used by any Tor relays, the DNS timeouts fraction reported by Tor dropped from 5-6% to 1.5%. The Tor relay guide should recommend running your recursive resolver (unbound) on a different IP than your exit: https://community.torproject.org/relay/setup/exit/ - Anders Trier Olesen On Sat, Nov 6, 2021 at 5:53 PM Intrepid Ibex via tor-relays wrote: Hi everybody, I am new to tor (as server operator) and try to support the network by operating an exit node. Machine is running Ubuntu 20.04 - Tor 0.4.6.8. nyx is giving me a notive every 10 minutes or so: [NOTICE] General overload -> DNS timeouts (6) fraction 1.4742% is above threshold of 1.% DNS on this machine however works perfectly. I told my tor browser to use my specific exit node, everything works fine. Node is running since 4 days now. Load is as expected. Thanks in advance for any help! Ibex -- Sent using MsgSafe.io [1]'s Free Plan Private, encrypted, online communication For everyone. www.msgsafe.io [1] ___ 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 Links: -- [1] https:/www.msgsafe.io/?utm_source=msgsafeutm_medium=emailutm_campaign=freemailsignature [2] http://mzfgbh.com [3] http://1.1.1.20___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Updating from Ubuntu 20.04 using apt-secure
Peter, Thanks for the response that did the trick and got the system updated fully. Thanks, John Csuti +1 (216) 633-1279 On 2021-10-11 03:41 AM, Peter Gerber wrote: Hi, unfortunately, there is some software that wasn't well prepared for the expiration of the Let's Encrypt root certificate [1 [1]]. Ubuntu ships a fix/workaround [2 [2]] for the issue. Just update Ubuntu first, then try to update Tor again. Peter [1]: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ [2]: https://changelogs.ubuntu.com/changelogs/pool/main/c/ca-certificates/ca-certificates_20210119~20.04.2/changelog John Csuti via tor-relays: Hello all, I recently went to update and upgrade my system and found that the certificate for deb.torproject.org is expired and no longer trusted? Is anyone else having this issue and is there a way to fix this. I also added the repo to a fresh install of ubuntu 20.04 and got the same error. Error Err:5 https://deb.torproject.org/torproject.org focal Release Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 95.216.163.36 443] Thanks, John Csuti +1 (216) 633-1279 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Links: -- [1] https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ [2] https://changelogs.ubuntu.com/changelogs/pool/main/c/ca-certificates/ca-certificates_20210119~20.04.2/changelog 0x148EEF26.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Updating from Ubuntu 20.04 using apt-secure
Hello all, I recently went to update and upgrade my system and found that the certificate for deb.torproject.org is expired and no longer trusted? Is anyone else having this issue and is there a way to fix this. I also added the repo to a fresh install of ubuntu 20.04 and got the same error. Error Err:5 https://deb.torproject.org/torproject.org focal Release Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 95.216.163.36 443] Thanks, John Csuti +1 (216) 633-1279 0x148EEF26.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Restarting Tor
Hello, I cant comment on how long a relay needs to be down before you loose flags could be a day or longer. As for needing to upgrade and reboot just go ahead and do it. The network will keep your current flags through the reboot and upgrade. Being down for both a reboot and or a upgrade is expected and encouraged. Thanks, John Csuti +1 (216) 633-1279 On 2021-10-09 11:07 PM, sysmanager7 via tor-relays wrote: Greetings All, I have three relays that are in need of an upgrade and reboot. What is the best way to restart these relays without loosing flags or time? Secondly how long can a relay be down before flags are dropped? Thank you for any help! Sysop Sent with ProtonMail [1] Secure Email. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Links: -- [1] https://protonmail.com/ 0x148EEF26.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor automatic restart
Hello, First i would recommend updating your tor version then worrying about your issue. Your current tor version is not recommended by the directory authority's. Thanks, John Csuti +1 (216) 633-1279 On 2021-10-09 06:40 PM, Keifer Bly wrote: Hi, So my relay at https://metrics.torproject.org/rs.html#details/79E3B585803DE805CCBC00C1EF36B1E74372861D Seems to periodically go down once a month or so. I am wondering, is there a way configure tor (via the torrc file) to restart automatically once a month? Thank you. --Keifer ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays 0x148EEF26.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
