tor-relays

tor-relays@lists.torproject.org

19 participants
4810 discussions

Re: [tor-relays] Exit relay not in consensus
by denny.obreham＠a-n-o-n-y-m-e.net 03 Oct '24

03 Oct '24

Before my last restart 6 hours ago you get a series of messages like these: ``` Since startup we initiated 0 and received 0 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 81 v3 connections; initiated 0 and received 341 v4 connections; initiated 38535 and received 87986 v5 connections. Heartbeat: DoS mitigation since startup: 0 circuits killed with too many cells, 0 circuits rejected, 0 marked addresses, 0 marked addresses for max queue, 0 same address concurrent connections rejected, 0 connections rejected, 0 single hop clients refused, 0 INTRODUCE2 rejected. Heartbeat: It seems like we are not in the cached consensus. Heartbeat: Tor's uptime is 2 days 18:00 hours, with 185 circuits open. I've sent 41.52 GB and received 55.06 GB. I've received 105529 connections on IPv4 and 0 on IPv6. I've made 46384 connections with IPv4 and 0 with IPv6. While not bootstrapping, fetched this many bytes: 53988798 (server descriptor fetch); 11748 (server descriptor upload); 3201890 (consensus network-status fetch); 548826 (microdescriptor fetch) Circuit handshake stats since last time: 0/0 TAP, 2/2 NTor. ``` After my last restart I have: ``` Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Read configuration file "/etc/tor/torrc". Based on detected system memory, MaxMemInQueues is set to 4440 MB. You can override this by setting MaxMemInQueues by hand. Opening Control listener on 127.0.0.1:9051 Opened Control listener connection (ready) on 127.0.0.1:9051 Opening OR listener on 156.67.111.146:443 Opened OR listener connection (ready) on 156.67.111.146:443 [...] Bootstrapped 5% (conn): Connecting to a relay Opening Control listener on /run/tor/control Opened Control listener connection (ready) on /run/tor/control Self-testing indicates your ORPort 156.67.111.146:443 is reachable from the outside. Excellent. Publishing server descriptor. Bootstrapped 10% (conn_done): Connected to a relay Bootstrapped 14% (handshake): Handshaking with a relay Bootstrapped 15% (handshake_done): Handshake with a relay done Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Bootstrapped 95% (circuit_create): Establishing a Tor circuit Bootstrapped 100% (done): Done Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 1000 buildtimes. Performing bandwidth self-test...done. ``` I can confirm that the IPv6 address is not reachable for an unknown reason. The IPv6 address and flag have been removed from the torrc file to correct the problem and don't appear in the log at restart, as shown above. IPv6 should be completely ignored by the DirAuth. Denny On 2024-10-01 08:06, George Hartley via tor-relays wrote: Hi, looks like the DirAuth's think that your relay is unreachable, and so your descriptor isn't published, so your flags are not updated, this would explain the lack of change in flags. Port 443 on 156.67.111.146 is open for me, can't test IPv6 as I have disabled it through my modem and kernel command line. Can you attach your tor log file? You can also adjust the log verbosity of certain "domains" within Tor like so: [1]https://2019.www.torproject.org/docs/tor-manual.html.en#Log Please let us know what you find. Thanks, George On Tuesday, October 1st, 2024 at 1:40 PM, denny.obreham(a)a-n-o-n-y-m-e.net <denny.obreham(a)a-n-o-n-y-m-e.net> wrote: My exit relay which has been running for months without a problem has not been in the cached consensus for days now. https://consensus-health.torproject.org/consensus-health.html?#7BDDE 0E7607A5F49578768F44CD721793FA2D7AE After investigating, I thought the reason was that the IPv6 wasn't reachable anymore. It happened once before with another relay. Seems to be a problem with my ISP. Anyway, I just remove the ORPort IPv6 address and IPv6Exit flag from the torrc file and everything should return to normal. It has been days and it doesn't. Reloaded and restarted more than once since then. What I don't understand is that the OR IPv6 address and the ReachableIPv6 flag are still listed in the metrics. h ttps://metrics.torproject.org/rs.html#details/7BDDE0E7607A5F49578768 F44CD721793FA2D7AE Any help would be appreciated. _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

5 4

turning off BridgeDB and the future of moat bridges
by meskio 03 Oct '24

03 Oct '24

Hello, tl;rd: moat bridges are not distributed anymore. Don't shut them down as they are still used but don't create new bridges with "BridgeDistribution moat". BridgeDB has being our bridge distribution system since 2007. For years we have being developed a replacement of BridgeDB[0] called rdsys[1]. And finally yesterday we replaced the last distributors missing in rdsys (email, https and moat) and turned off BridgeDB. The only visible difference is that captchas has disappeared from https://bridges.torproject.org and requesting bridges in Tor Browser gives you a static captcha and doesn't even verify if the answer is correct (until we have the time to update TB to don't request the captcha[2]. The mayor difference for bridge operators is that we don't distribute "moat" bridges anymore. We have merged circumvention settings and moat and now is one distributor handing over "settings" bridges. For now we are going to keep the existing "moat" bridges assigned to "moat" and don't distribute them, so users that have one of those bridges can keep using them without risk of censors finding it. New bridges will not be assigned automatically the moat distributor, only existing bridges or bridges with "BridgeDistribution moat" will stay in this distributor. We plan to watch the usage of moat bridges and evaluate moving them to another distributor depending on the usage[3]. Thank you for running bridges. [0] https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/ [1] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/ [2] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42086 [3] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/233 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

3 6

Docker Snowflake Proxy Multiple IPs
by admin＠likogan.dev 02 Oct '24

02 Oct '24

Hello, I'm writing because I want to run a snowflake proxy in a docker container on a server with two IP addresses; the primary public IP I want the snowflake proxy hosted on, and a public anycast IP that's shared between other servers. I'm concerned the snowflake proxy may try listening on the anycast IP, which will cause problems as this IP is shared between a few servers! >From my understanding, a snowflake proxy should use the "host" network option with docker. How can I specify which IP address to use with this option? Thanks, Likogan

2 1

Exit relay not in consensus
by denny.obreham＠a-n-o-n-y-m-e.net 01 Oct '24

01 Oct '24

My exit relay which has been running for months without a problem has not been in the cached consensus for days now. https://consensus-health.torproject.org/consensus-health.html?#7BDDE0E7 607A5F49578768F44CD721793FA2D7AE After investigating, I thought the reason was that the IPv6 wasn't reachable anymore. It happened once before with another relay. Seems to be a problem with my ISP. Anyway, I just remove the ORPort IPv6 address and IPv6Exit flag from the torrc file and everything should return to normal. It has been days and it doesn't. Reloaded and restarted more than once since then. What I don't understand is that the OR IPv6 address and the ReachableIPv6 flag are still listed in the metrics. https://metrics.torproject.org/rs.html#details/7BDDE0E7607A5F49578768F4 4CD721793FA2D7AE Any help would be appreciated.

2 1

relays and CUPS vulnerabilities
by George 30 Sep '24

30 Sep '24

There are some very significant recent CVEs out for CUPS, the unix printing system. https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=cups It's an ideal moment to remind relay operators that a Tor node, relay or bridge, should be a single-purpose internet server. Running alternate internet services is a bad idea. The node should have the minimum packages installed for the purpose of running a node. More packages means more possible vulnerabilities. Needless to say, a CUPS server listening on 631/tcp or 631/udp while providing Tor access is a bad idea. g -- 43C2 85B0 41B6 4AC1 0E02 2767 7092 AEB3 40B0 C804

3 3

Relay disconnect & offline on IP change
by Tor Relay Net Ops 26 Sep '24

26 Sep '24

Greetings fellow relay operators! I'm currently running a tor relay on a dynamic IP Address connection, usually my ISP gives me a new address every day or so- Lately [for the past like week or so- /can't remember when it started happening/], I have to manually restart it when my WAN IP Address changes; to get the relay back online- (systemctl restart tor@default) Is there a way to not manually restart tor (besides running a cron script to do so) Below are my tor configuration: Tor 0.4.8.12 on Linux Debian GNU/Linux 12 (bookworm) /etc/tor/torrc Nickname hadleyJamison ContactInfo url:darrenofficial.com proof:dns-rsa ciissversion:2mailto:tor-relay-netops@darrenofficial.com ORPort 88 IPv4Only ExitRelay 0 SocksPort 0 ControlPort 9051 CookieAuthentication 1 RelayBandwidthRate 69 MBits RelayBandwidthBurst 69 MBits -darren

6 6

Dear OBFS4 bridge operators, please enable timing and packet-size obfuscations to help clients facing timing analysis attacks.
by George Hartley 25 Sep '24

25 Sep '24

Hello Tor community, this e-mail applies to you if you are running an obfs4 (now known under the name lyrebird) bridge or want to do so in the future. Some recent posts on this list has shown that traffic timing analysis can be used to locate a users or onion services guard nodes or bridges. This is not really something new. For bridge users, there is a way to try to protect themselves against this, but your bridge configuration must support it. By enabling iat-mode on your obfs4 /lyrebird bridge, then maybe DPI (Deep Packet Inspection) hardware can sometimes be defeated either entirely, or at least the process of tracking users can be slowed down. OBFS4/Lyrebird support two times of traffic obfuscation: > ServerTransportOptions obfs4 iat-mode=1 This will make your bridge send MTU sized packets, in order to make true packet size analysis harder. There is also what the author of obfs4/Lyrebird called "paranoid mode": > ServerTransportOptions obfs4 iat-mode=2 For each write, a variable length packet will be sent, which will result in both making true packet size and round trip time analysis harder. If your bridge is distributed by BridgeDB, the next time someone receives a batch of bridges with your bridge in it, the bridge-line will have the iat-mode variable set to the one you set on your bridge server. Your bridge will still work even if you enable these defenses and a user chooses to set iat-mode to 0 in his bridge line. There is a small performance penalty for both mode 1 and 2, but nothing very severe. I believe this, along with Vanguards, and so on, is needed to keep users and services somewhat secure. Let me know what you think. - George

5 8

Looking for a ipv4 block and strategy
by Osservatorio Nessuno 24 Sep '24

24 Sep '24

Hi everyone, our organization is working to add more physical nodes, in our little Italy headquarter[1]. We have reached an agreement with one of the available fiber reseller there, where we will pay for L2 transport to a datacenter, where we will buy our uplink separately and announce and route our public IP addresses independently. It is actually a very nice opportunity to remove a point of trust in the chain and get back control to a part of infrastructure that is usually delegated to commercial ISP. Similarly, as this list knows well, by announcing our IPs we will be the direct recipients of any abuse. We have now two options: either look for someone willing to lease a /24 to Tor operators, which is not an easy task since the block reputation will be tainted and depreciate the block. We have found someone willing to, for $119/mo, but it is hard to tell how long that will last. An alternative would be to buy it, for around ~7k$ (~28-31$ per IP, via a broker). We do not have the budget for this now, but an organization member has offered to lease the money and get paid back without interest at a similar rate that a lease would cost (around $1k year). In all phases, the block will be in the org ownership. We have someone who can LIR sponsor at RIPE so we would not have other recurring expenses. Buying is more sustainable in the long-term: in around 6 years we will stop to have to pay the lease. At the same time, we will not have any chances to change those IP ever later, while in a lease, we could eventually move to other blocks. Does anybody in the community have contacts for lease or sale? Is there any foreseeable issue in sticking to the same range for the next ~10 years? Especially at the beginning, it will be unlikely that we will use even 1/4 of them, but given how the fiber infrastructure is built, we can eventually use the same announcements even for other physical locations. Thank you [1] - https://osservatorionessuno.org/blog/2024/07/we-have-a-headquarter-and-it-i…

2 2

Why I do have so often an "8" in my bridge stats?
by Toralf Förster 24 Sep '24

24 Sep '24

Never cared about this before, but isn't the "8" too often here? : $ cat ~/tmp/tor_bridge_stats i10 bridge-ips ru=264,br=16,de=16,us=16,au=8,cl=8,co=8,cz=8,dz=8,eg=8,es=8,fr=8,gb=8,gr=8,hk=8,id=8,in=8,ir=8,it=8,kr=8,lt=8,lv=8,nl=8,ph=8,sa=8,sg=8,tw=8,ua=8,ve=8 i11 bridge-ips ru=152,ir=16,cn=8,cz=8,de=8,gb=8,nl=8,pl=8,tr=8 i12 bridge-ips ru=224,by=8,cn=8,de=8,fr=8,in=8,ir=8,jp=8,nl=8,pl=8,ro=8,us=8 i13 bridge-ips de=8 i14 bridge-ips de=8,fr=8,ru=8 i15 bridge-ips de=8,ru=8 i20 bridge-ips de=8 i21 bridge-ips de=8 i22 bridge-ips ru=96,at=8,de=8,nl=8,pl=8,us=8 i23 bridge-ips ru=904,ir=48,eg=32,de=24,us=24,fr=16,ae=8,at=8,be=8,br=8,by=8,ca=8,co=8,cz=8,dz=8,fi=8,gb=8,gr=8,hk=8,hu=8,im=8,in=8,it=8,jp=8,kz=8,lv=8,ma=8,md=8,mm=8,na=8,ni=8,nl=8,pk=8,pl=8,sa=8,se=8,tm=8,tr=8,tz=8,uz=8,ve=8,ye=8,za=8 i24 bridge-ips de=8 i25 bridge-ips ru=112,ch=8,cn=8,de=8,gh=8,in=8,ir=8,ke=8,mm=8,mu=8,nl=8,tr=8,us=8 i26 bridge-ips de=8 luchs bridge-ips de=8 -- Toralf

2 3

Read/written bytes on a relay differ
by Richie 23 Sep '24

23 Sep '24

Hi everyone, nothing of real concern, but out of curiosity: since some years now i use overhead traffic on my ISP for Tor, with a small home relay burning some 3 to 4 MB/Sec. Usual middle relay plus V2Dir (and HSdir some days after last reboot). Since some weeks now, the read/written bytes differ quite significantly, and i never experieced sth like that for a relevant timespan before. Is this a sign of more "reading directory services" on the relay? (maybe short reqests and verbose replys), some new kind of attack, whatever? direct metrics-Link via https://metrics.torproject.org/rs.html#details/11FC7D9C7D8DF74326B90EC71C10… and screenie attached. Again, no big issue, just curiosity. And if its some kind of bug, i'd be happy to hand over more info. thx to everyone maintaining and running this stuff, Richie

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays