- tor-relays - lists.torproject.org

Is there a way to update obfs4 using chocklatey?
by Keifer Bly 16 Jul '23

16 Jul '23

Hi, So on Windows, it is possible to install the tor relay software using Chocolatey https://chocolatey.org/. Once it is installed, tor can be installed by using choco install tor and updated using choco upgrade tor in Windows powershell. But I am wondering, is there a way to install and update obfs4 in Chocolatey? Thanks. --Keifer

1 0

Question regarding bandwidth ratio on bridges.torproject.org and a few further, small, (probably related) questions
by telekobold 06 Jul '23

06 Jul '23

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

2 1

Invitation to Participate in Tor Update Survey - University of Edinburgh Research Project
by Meitong Wang 05 Jul '23

05 Jul '23

Dear Relay Operators, My name is Meitong, and I am a Master's student at the University of Edinburgh, currently being supervised by Tariq Elahi. I am working on a project to understand Tor Relay Operators and further improve Tor security. I am writing to invite you to participate in a survey as part of a research project conducted by the University of Edinburgh. The purpose of this survey is to gather valuable insights and feedback from relay operators regarding the Tor network's update process. The overall goal of this survey is to understand the experiences, challenges, and perspectives of relay operators when it comes to Tor relay updates. Your input will contribute to improving the update design and addressing any issues that may arise. I want to assure you that your participation in this survey is completely anonymous. Your responses will be treated with strict confidentiality and will only be used for research purposes. To access the survey, please click on the following link: https://cryptpad.fr/form/#/2/form/view/dvbbDORTjeztLzosbOuGVaRheI-FBjFh6xPQ… The survey will be open until July 23, 2023. Your participation is highly appreciated and will be valuable in shaping the future updates of Tor. Please note that this study has been approved by the UoE Informatics Research Ethics Process, with the project reference number: 775342. To provide you with more information about the survey and its purpose, I have attached the Participant Information Form. This document explains the study's background, procedures, and your rights as a participant. I kindly request that you review it before deciding whether to participate. If you have any questions or concerns about the survey or the research project, please feel free to reach out to me. I would be more than happy to provide further clarification. Thank you in advance for your time and valuable contribution. We eagerly await your response! Best regards, Meitong Wang & Tariq Elahi The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336.

1 0

Security implications of disabling onion key rotation?
by David Fifield 05 Jul '23

05 Jul '23

Linus Nordberg and I have had a paper accepted to FOCI 2023 on the special pluggable transports configuration used on the Snowflake bridges. That design was first hashed out on this mailing list last year. https://forum.torproject.net/t/tor-relays-how-to-reduce-tor-cpu-load-on-a-s… https://github.com/net4people/bbs/issues/103 https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Survival%20G… There is a draft of the paper here: https://www.bamsoftware.com/papers/pt-bridge-hiperf/pt-bridge-hiperf.202303… https://www.bamsoftware.com/papers/pt-bridge-hiperf/pt-bridge-hiperf.202303… A question that more than one reviewer asked is, what are the security implications of disabling onion key rotation as we do? (Section 3.2 in the draft.) It's a good question and one we'd like to address in the final draft. What are the risks of not rotating onion keys? My understanding is that rotation is meant to enhance forward security; i.e., limit how far back in time past recorded connections can be attacked in the case of key compromise. https://spec.torproject.org/tor-design Section 4 says: Short-term keys are rotated periodically and independently, to limit the impact of key compromise. Do the considerations differ when using ntor keys versus TAP keys?

3 5

Instructions for setting up an Obfs4 bridge on windows
by tor 03 Jul '23

03 Jul '23

Hi, I'm attempting to follow the instructions for setting up a obfs4 bridge on Windows. In my instance, it is Windows 10. The instructions say to copy out the obfs4proxy.exe from: C:\Users\<user>\Desktop\Tor Browser\Browser\TorBrowser\Tor\PluggableTransports However, there is no obfs4 file in this location or anywhere else within the tor browser bundle. In this location, there are only a snowflake exe and a lyrebird exe. I also checked the tor expert bundle and there is no obfs4 exe there. Any suggestions as to where I may find the obfs4 exe for Windows? -matt

2 1

(Announcement) WebTunnel, a new pluggable transport for bridges, now available for deployment
by Shelikhoo 30 Jun '23

30 Jun '23

Dear Tor relay operators, We're excited to announce WebTunnel, a new bridge pluggable transport (PT) for the Tor ecosystem. It is a censor resistant proxy that try to imitate HTTPS traffic, based on HTTPT(https://www.usenix.org/conference/foci20/presentation/frolov) research. We are currently operating a trial soft launch for WebTunnel, and encouragebridge operators to setup WebTunnel bridges to discover issues within theimplementation of this newpluggable transport. How it works ------------ When connecting to a WebTunnel Bridge, the client send a http 1.1 upgrade request to the load balancer over an encrypted connection, like how WebSocket works. Thus, from an observator’s point of view, this process looks like a real websocket connection to the real website. If one ever try to connect to the fronting website, then what will be presented will be that fronting website. Without the full URL including the path, which the censor don’t know, it is very difficult to tell if a website hosts a WebTunnel by probing the HTTPS port. Technical requirements ---------------------- To set up a WebTunnel Bridge, you will need a self-hosted website,a domain under your control,a configurable load balancer, static IPv4, and environment to setup Tor Bridge to setup a WebTunnel Bridge. Docker or other container runtime is recommended to streamline setup process, but is not required. The setup guide is available here: _https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/web… <https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt…> How to test and report issues ----------------------------- You can test the WebTunnel bridge by using themost recent version of Tor Browser Alpha(https://www.torproject.org/download/alpha/). Currently, WebTunnel is only distributed over the HTTPSdistributor(torrc setting:'BridgeDistribution https'). You can report issues on the Tor Project GitLab Anti-censorship group: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webt…. Given that this new PT is only available now on Tor Browser Alpha, relay operators should not expect significant usage or a large number of users at the moment. Please let us know if you encountered any difficulty with WebTunnel setup. Thanks for your contribution to the Tor ecosystem.

3 2

8 relays pers IP address are allowed from now (end of June 2023) on
by Georg Koppen 30 Jun '23

30 Jun '23

Hi! You might recall that Tor has been restricting the possible amount of Tor relays per IP address to 2, mainly for Sybil prevention reasons.[1] We bumped that limit to 4 earlier this year[2] to make better use of available resources and considered back then bumping that limit further to 8 relays per IP address. I've good news for everyone looking forward to raising that limit further: after an investigation into the effects of allowing 4 relays per IP address[3] we think it is overall beneficial for the network and our users to raise it further to 8. This change (by having set `AuthDirMaxServersPerAddr 8` on a majority of them) is in effect since a couple of hours and you can run more than 4 relays per IP address now. This is not meant to be a permanent change, though, but only a stopgap solution to work around missing multithreading support in Tor until relays in Arti will be available and deployed (which is still some years away from now). For more details, information and discussion see: tor#40744.[4] Thanks to everyone who helped making this change happen, Georg [1] https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/109-no… [2] https://lists.torproject.org/pipermail/tor-relays/2023-February/020999.html [3] https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/51 [4] https://gitlab.torproject.org/tpo/core/tor/-/issues/40744

1 0

Process for new policies and proposals for the Tor relay operator community (001-community-relay-operator-process.md)
by gus 27 Jun '23

27 Jun '23

Hi, Last Saturday, during the Tor Relay Operator meetup, I briefly talked about the meta proposal that defines the process of submitting proposals to the relay operator community. The document is open for community feedback, and you can comment directly on the ticket: https://gitlab.torproject.org/tpo/community/policies/-/issues/2. I'm also sharing the full text below. Gus ``` Filename: 001-community-relay-operator-process.md Title: Process for new policies and proposals for the Tor relay operator community Author: gus - gus(a)torproject.org Created: 2023-05-22 Status: Meta ## Overview This document outlines the process for submitting policies to the Tor relay operator community, explains how proposals are approved, and clarifies the relationship between Tor Community proposals and the Tor Project. This is an informational document. ## Motivation In the past, our approach to organizing the Tor relay operator community was highly informal and relied heavily on the informal dynamics between relay operators, Directory Authorities, and The Tor Project staff. Through discussions and interactions in meetups and similar events, operators would collaboratively determine the best practices for managing Tor relays while ensuring the well-being of Tor users. However, as the Tor Community expands and its members become less interconnected, there is now a necessity to establish a well-defined process for presenting and evaluating proposals and policies to the relay operator community. It's important to note that these proposals are distinct from the Tor proposals governed by torspec. The proposals in tor spec primarily focus on technical specifications and protocols at the core of the Tor network. They cover areas such as the Tor protocol, directory authorities, circuit construction, and encryption mechanisms. The proposals in this document, on the other hand, are specifically tailored to the relay operator community and address operational, policy, and community-related aspects. While both types of proposals aim to improve the Tor network, they serve different purposes and operate within their respective scopes. It's part of the scope of these proposals addressing topics like: - Security measures to combat malicious relays and attacks against the Tor network like DDoS - Expectations for relays operators and operational policies - Sustainability and operators incentivisation - Guidelines for conducting investigations to identify and remove malicious actors from the Tor network - Initiatives related to relay operator governance and community building There might be corner cases where proposals impacting the relay operator community would contain torspec material if approved. In that case it is fine to submit a proposal within this community proposal process first and a corresponding torspec on later one if the proposal got approved. ## How new proposals get added, approved and implemented The process of adding, approving, and implementing new proposals for the relay operator community follows a specific workflow as described below. Here is an overview of the steps involved: Summary of the stages: Draft & Full Proposal -> Policy -> Implementation The current proposal editors are the Tor Project Community and Network Health Team leads, who can reject or accept full proposals. The criteria for evaluation of proposals for relay operators are stated on the document ["Combating Malicious Relays - Evaluation criteria for solutions"](https://nc.torproject.net/s/bLWAjC8FJ8KKCGQ). ### 1. Draft, consensus, and full proposal To submit a proposal, open directly a new issue in the Tor Project GitLab [Community/Policies repository](https://gitlab.torproject.org/tpo/community/policies). A proposal should have a properly formatted (see below) draft. Once an idea moves to this stage, the Tor Community should discuss and improve it until we've reached consensus that it's a good idea and that it's detailed enough to implement. The official request for changes, suggestions and improvements of the proposal must happen in the GitLab comment section so that the author can directly receive the feedback. To submit a new update of the proposal, the author should add a comment with the new alternative text in the appropriate ticket. Additionally, the author must update the issue description to indicate the availability of a new version of the proposal. This ensures that the proposal is properly documented. ### 2. Policy and implementation Once the full proposal has reached a consensus and its final version was approved by the proposal editors, they will officially create a merge request and add the approved proposal. When this happens, we incorporate it into the Relay Operator policies directory and implement the proposal. This process ensures that proposals undergo thorough discussion and consensus-building, helping maintain the integrity of The Tor Project's policies and operations. ## Observations Unlike RFCs (Request for Comments), Tor relay operator community proposals can evolve over time while retaining the same number until they are ultimately accepted or rejected. The entire history of each proposal will be archived in the Tor Community Policies repository. It's still okay to make small changes directly to your proposal once it's finalized if it's cosmetic changes and no substantial change is required. This document reflects the current contributors' _intent_, not a permanent promise to always use this process in the future. Technical Tor spec proposals are out of the scope of this document and must follow the process described on [Tor specification](https://gitlab.torproject.org/tpo/core/torspec/). If consensus cannot be reached among the Tor relay operators community during the proposal review process, a Voting process involving Core contributors can be initiated. The decision to proceed with a voting process is at the discretion of the proposal editors. They are responsible for determining whether a voting process is necessary to resolve the impasse. In such cases, the voting process must follow the [Voting policy](https://gitlab.torproject.org/tpo/community/policies/-/blob/master/…. ## Responsibilities and roles of proposal editors The proposal editors play a crucial role in the evaluation and approval of proposals within the Tor relay operator community. Their responsibilities include: ### 1. Reviewing and evaluating proposals The proposal editors evaluate each submitted proposal to assess its feasibility, adherence to community policies, and potential impact on the Tor network and its users. ### 2. Facilitating discussions and building consensus The proposal editors actively participate in discussions related to proposals, engaging with the Tor relay operator community to understand different perspectives and build consensus. They facilitate constructive dialogue, encouraging community members to provide feedback, suggest improvements, and address concerns raised during the proposal review process. ### 3. Determining proposal status The proposal editors are responsible for assigning appropriate proposal statuses. They evaluate the progress and quality of proposals, assigning statuses such as "Draft," "Open," "Needs-Revision," "Accepted," "Finished," "Closed," "Rejected," "Dead," "Meta," or "Reserve." The proposal editors maintain the proposal status throughout the review process until a final decision is reached. ### 4. Maintaining proposal integrity and documentation The proposal editors ensure the integrity and accuracy of proposals within the Tor Community/Policies repository. They review proposals for adherence to formatting guidelines and make necessary adjustments to maintain consistency. ## Proposals made by proposal editors When proposal editors intend to submit their own proposals, they must follow the standard process outlined in the "How new proposals get added, approved and implemented" section of this document. However, when it comes to merging their own proposals, the proposal editors should not unilaterally merge their own proposals without proper evaluation and consensus from the Tor relay operator community. The proposal editors have the responsibility to maintain the integrity and fairness of the proposal review process. To avoid conflicts of interest and ensure transparency, full proposals made by proposal editors must be sponsored by two other Tor core contributors. ## What should go in a proposal Every proposal must have a header containing these fields: * Filename * Title * Author * Created * Status The body of the proposal should start with an Overview section explaining what the proposal's about, what it does, and about what state it's in. After the Overview, the proposal becomes more free-form. Depending on its length and complexity, the proposal can break into sections as appropriate, or follow a short discursive format. Every proposal should contain at least the following information before it is "ACCEPTED", though the information does not need to be in sections with these names. Motivation: What problem is the proposal trying to solve? Why does this problem matter? If several approaches are possible, why take this one? Security implications: What effects the proposed changes might have on anonymity, how well understood these effects are, and so on. Implementation: If the proposal will be tricky to implement by the Tor Community, the document can contain some discussion of how to go about making it work. ## How to format proposals Proposals must be written in Markdown. ## Proposal status Draft: This isn't a complete proposal yet; there are definite missing pieces. Please don't add any new proposals with this status. Open: A proposal under discussion. Needs-Revision: The idea for the proposal is a good one, but the proposal as it stands has serious problems that keep it from being accepted. See comments in the ticket for details. Accepted: The proposal is complete, and we intend to implement it. After this point, substantive changes to the proposal should be avoided, and regarded as a sign of the process having failed somewhere. Finished: The proposal has been accepted and implemented. After this point, the proposal should not be changed. Closed: The proposal has been accepted, implemented, and merged into the main policies documents. The proposal should not be changed after this point. Rejected: We're not going to implement the proposal as described here, though we might do some other version. See comments in the ticket for details. The proposal should not be changed after this point; to bring up some other version of the idea, write a new proposal. Dead: The proposal hasn't been touched in a long time, and it doesn't look like anybody is going to complete it soon. It can become "Open" again if it gets a new proponent. Meta: This is not a proposal, but a document about proposals. Reserve: This proposal is not something we're currently planning to implement, but we might want to resurrect it some day if we decide to do something like what it proposes. Obsolete: This proposal was flawed and has been superseded by another proposal. See comments in the document for details. The proposal editors maintain the correct status of proposals, based on rough consensus and their own discretion. ## Proposal numbering Numbers 000-099 are reserved for special and meta-proposals. 100 and up are used for actual proposals. Numbers aren't recycled. ``` -- The Tor Project Community Team Lead

1 0

Re: [tor-relays] Comcast blocks ALL traffic with tor relays
by Livingood, Jason 18 Jun '23

18 Jun '23

>As to the blog post you mention… Your statements are very generic: now you talk about "not blocking tor", but tor is not just one webpage, one server, a monolithic entity. I would appreciate details: If your customer has "advanced security" activated, can he connect to any ORPort of any tor middle relay? Fair enough. That post was in any case from 2014 and the questions are different today (I just used it as an example that we’re not against Tor). Honestly, I’m a little surprised that someone running a Tor exit node would not be using their own cable modem and running their own router (whether open source a la Openwrt or commercial). If someone wants to do stuff like run a Tor exit node or run a MASQUE relay or whatever, I’d recommend they turn off Advanced Security and manage their routing & firewall rules themselves. >Sorry if I am a bit repetitive, but https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security<https://urldefense.com/v3/__https:/www.xfinity.com/support/articles/using-x…> mentions "Blocks remote access to smart devices from known dangerous sources.". What do you mean by dangerous sources, and does it include tor relays or exits? It may be down to the fact that “unknown” users connect to the relay/exit and that the average consumer user of the Advanced Security service does not want that. I suspect if someone wants this, it’s best to toggle Advanced Security off. > I don't know whether this customer has "Advanced security" turned on, I just assume he has. Do you want me to send you privately more details (my IP and this peer's IP)? Sure – I am happy to look at that confidentially. But it could be a wide range of other things – even basic things like someone’s router timing out external connections after X minutes, etc. > So you remind me of an old joke: who should I believe, you, or my eyes? Sorry, I choose my eyes. I am talking here about direction from my node to Comcast. It is still possible that you don't block connections from Comcast to relays, I have contradictory evidence about this point. So if your "not blocking tor" means "not preventing our customer from connecting to some tor relays", this could be true. Alternatively, given the large size of our network, if we were in fact blocking this, then I’d expect to see this list filled with complaints and social media sites (Twitter<https://twitter.com/search?q=comcast%20tor&src=typed_query&f=top>, Reddit, etc.) filled with complaints. But what I see now is a single report. That said, I routinely look at such reports when they seem at odds with our network policies so as to be certain there’s not some misconfiguration or bug someplace. Jason

3 2

Comcast blocks ALL traffic with tor relays
by xmrk2 16 Jun '23

16 Jun '23

I'd like to raise awareness of the Comcast blocking. As stated in subject, I believe Comcast blocks all traffic between its customers and public tor relay nodes. That is, the blocking is not limited to tor-related traffic, all other services / ports on the tor relay are blocked. Background: I am running a lightning node, lightning is a layer 2 protocol to scale Bitcoin. Lightning nodes need to be connected to each other ideally 24/7. I was contacted by the operator of another Lightning node, complaining that he cannot connect to my node. He is Comcast customer, I am not. I was also running a tor relay on the same public IPv4 address. I am pretty sure that the blocking is done by Comcast and is triggered by being in public list of tor relays. The blocking disappeared after I stopped my tor relay and restarted my router (thus getting a new external IPv4 address). After 1 day, I relaunched the tor relay, and the blocking reappeared a few hours later. It was also confirmed by the said operator of the lightning node, who said there were various rounds of blocking tor, customers complaining and Comcast lifting the block for some time, only to reinstate the blocking later. Comcast thus discourages me and similar people from running tor relays, or at least forces me to run tor in bridge mode. So this is an insidious attack on tor. Note that Bitcoin is not particularly relevant, Comcast is blocking tor nodes, not bitcoin nodes. So even if you hate Bitcoin, note that the same problem could arise even if Bitcoin never existed: e.g. a self-hosted web server, whose owner wants to donate his free capacity to tor by running tor relay. By doing this, he prevents any Comcast customers from accessing his web server, and this consequence is not obvious at all. Any ideas on how to combat this? I was thinking about including some false positives in tor relay list. Imagine including some Google servers' IP addresses - Comcast customers suddenly cannot connect to Google, unless Comcast stops this blocking... or simply whitelists Google. But those false positives sound ugly and a bit malicious, not sure it is a good idea. I already wrote about this publicly, and also wrote a mail to EFF. Hope I am not spamming, I feel this is quite important issue and am a bit frustrated by the lack of attention it gets.

9 11

[Important] A call for more long running bridges, especially with OBFS IAT-Mode set to 1 or 2.
by George Hartley 16 Jun '23

16 Jun '23

Hello dear relay and bridge hosts, recently a paper was published, describing a traffic confirmation attack called DeepCorr, which works against Tor users and as such, also hidden services. The attack allegedly had success rates of up to 96% percent. It is being worked on and listed here as a separate ticket: https://forum.torproject.net/t/tor-dev-critical-deepcorr-traffic-confirmati… Until mitigations have been merged into the Tor codebase, I kindly ask you, the driving force behind the network, to set up more bridges with "iat-mode" enabled and set to "1" or "2" - the paper stated that it was significantly harder to launch successful attacks against clients using OBFS4 bridges with timing obfuscation enabled, which is what "iat-mode" really is. In a nutshell, the measure of IAT is the average (or the arithmetic mean) between network packets arriving at a host over a period of time, of the times between packets arriving at a host over a period of time, which you can also call latency. For security reasons such as defeating DPI and similar network analysis techniques, OBFS4, while at the same time encrypting and making your traffic look like regular TLS traffic, it also offers to try and obfuscate the IAT and packet size by inserting random padding bytes. For you guys or girls with programming skills or the ability to read and understand code, here is the responsible code: https://github.com/Yawning/obfs4/blob/40245c4a1cf221395c59d1f4bf27412704535… I vote for a fair 50 / 50 distribution of bridges with "iat-mode=1" and "iat-mode=2", even though while IAT mode 2, also called the "paranoid" mode by the author of the code above, may be more effective. Dear clients, you can already enable timing-obfuscation in one way, by editing your bridge-line and setting iat-mode from "0" to either "1" or "2" - please be aware that this will only enable timing-obfuscation in one way, the bridge needs to support it too to get packet timing obfuscated in both ways. Dear bridge operators, all it takes is a simple tor configuration file change: ServerTransportOptions obfs4 iat-mode=1 or ServerTransportOptions obfs4 iat-mode=2 Your bridge key will very likely stay the same, although I do not have the infrastructure to try this out right now. It is and has been very hard to find reliable OBFS4 bridges which also support timing obfuscation, for over a year now - please consider changing your bridge configuration in order to possibly help clients and hidden services evade timing related attacks such as DeepCorr. Yours truly, George Hartley

2 2

AROI not getting verified
by chani 14 Jun '23

14 Jun '23

Hey all, I'm running a relay and wanted to get AROI setup. I tried to debug it now for quite some time, but I just cant get it to get verified. I checked that my contact info matches the well known file, and if the well known file is reachable. I also cant find anyone except myself, querying the well known file on my webserver for the last few days. Am I missing something? relay fingerprint: CA1D49840F37E0C9D5F1770A5F033D80EB6AF369

3 3

Re: [tor-relays] Do they use their own modem/router?
by Livingood, Jason 14 Jun '23

14 Jun '23

This thread mentions “Advanced Security” and you can learn more about that at https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security. This feature can only be used with a leased Xfinity gateway like the XB7 or XB8. There are a great many cable modems that customers can and do buy in retail stores that do not have such features – like the Arris S33 cable modem. So, a customer that has Advanced Security has in essence (1) chosen to use an XB gateway rather than buy their own modem & router in retail and manage it themselves, and (2) turned on Advanced Security. If the customer in question that is using Advanced Security wishes to turn it off, they can do so in the Xfinity app (or turn the modem into ‘bridge mode’ and use their own router, or use their own modem). I’m happy to help answer other questions. Jason Livingood Technology Policy, Product & Standards Comcast

2 1

Re: [tor-relays] Comcast blocks ALL traffic with tor relays
by Livingood, Jason 14 Jun '23

14 Jun '23

Hi – Dropping into this thread from Comcast to say that we DO NOT BLOCK Tor. Feel free to refer back to my 2014 blog statement on this at https://corporate.comcast.com/comcast-voices/setting-the-record-straight-on…. Jason Livingood Technology Policy, Product & Standards Comcast

2 1

Re: [tor-relays] Do they use their own modem/router?
by Livingood, Jason 14 Jun '23

14 Jun '23

BTW, feel free to refer back to my 2014 blog statement on this at https://corporate.comcast.com/comcast-voices/setting-the-record-straight-on…. Jason From: tor-relays <tor-relays-bounces(a)lists.torproject.org> on behalf of "Livingood, Jason via tor-relays" <tor-relays(a)lists.torproject.org> Reply-To: "tor-relays(a)lists.torproject.org" <tor-relays(a)lists.torproject.org> Date: Wednesday, June 14, 2023 at 14:43 To: "tor-relays(a)lists.torproject.org" <tor-relays(a)lists.torproject.org> Cc: Jason Livingood <Jason_Livingood(a)comcast.com> Subject: Re: [tor-relays] Do they use their own modem/router? This thread mentions “Advanced Security” and you can learn more about that at https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security<https://urldefense.com/v3/__https:/www.xfinity.com/support/articles/using-x…>. This feature can only be used with a leased Xfinity gateway like the XB7 or XB8. There are a great many cable modems that customers can and do buy in retail stores that do not have such features – like the Arris S33 cable modem. So, a customer that has Advanced Security has in essence (1) chosen to use an XB gateway rather than buy their own modem & router in retail and manage it themselves, and (2) turned on Advanced Security. If the customer in question that is using Advanced Security wishes to turn it off, they can do so in the Xfinity app (or turn the modem into ‘bridge mode’ and use their own router, or use their own modem). I’m happy to help answer other questions. Jason Livingood Technology Policy, Product & Standards Comcast

1 0

Do they use their own modem/router?
by xmrk2 13 Jun '23

13 Jun '23

Got a question from [seeess at riseup.net](mailto:seeess@riseup.net) > I had a question about the "advanced security" and the two users you tested with. Do either of them use their own customer provided modem, or are they both using a Comcast-provided modem/router? Is "Advanced Security" something that is configured locally on their networking equipment (like a Comcast-provided modem/router) or is it cloud based? You mention "in his Comcast router" but I wanted to double-check if it was specifically a Comcast-provided piece of hardware. CCB says: "It is configured in the cloud. There's a limited amount of things I can do with my router, most of the settings are done through their app. So like... things like my port forwarding, I can't actually do in my router, I have to go through the app, which I can access remotely or on a different network." I think we cannot be sure where the filtering is done (router at customer's premises or inside Comcast network) unless someone tries with custom router. CCA stopped replying me, I can only speculate. He tested our connection with netcat, mentioned using wireguard, so he should be capable of configuring his custom router. But whether he does.... my guess would be as good as yours. ------- Original Message ------- On Sunday, June 11th, 2023 at 1:46 PM, xmrk2 <xmrk2(a)protonmail.com> wrote: > I'd like to raise awareness of the Comcast blocking. > > As stated in subject, I believe Comcast blocks all traffic between its customers and public tor relay nodes. That is, the blocking is not limited to tor-related traffic, all other services / ports on the tor relay are blocked. > > Background: I am running a lightning node, lightning is a layer 2 protocol to scale Bitcoin. Lightning nodes need to be connected to each other ideally 24/7. I was contacted by the operator of another Lightning node, complaining that he cannot connect to my node. He is Comcast customer, I am not. I was also running a tor relay on the same public IPv4 address. > > I am pretty sure that the blocking is done by Comcast and is triggered by being in public list of tor relays. The blocking disappeared after I stopped my tor relay and restarted my router (thus getting a new external IPv4 address). After 1 day, I relaunched the tor relay, and the blocking reappeared a few hours later. It was also confirmed by the said operator of the lightning node, who said there were various rounds of blocking tor, customers complaining and Comcast lifting the block for some time, only to reinstate the blocking later. > > Comcast thus discourages me and similar people from running tor relays, or at least forces me to run tor in bridge mode. So this is an insidious attack on tor. Note that Bitcoin is not particularly relevant, Comcast is blocking tor nodes, not bitcoin nodes. So even if you hate Bitcoin, note that the same problem could arise even if Bitcoin never existed: e.g. a self-hosted web server, whose owner wants to donate his free capacity to tor by running tor relay. By doing this, he prevents any Comcast customers from accessing his web server, and this consequence is not obvious at all. > > Any ideas on how to combat this? I was thinking about including some false positives in tor relay list. Imagine including some Google servers' IP addresses - Comcast customers suddenly cannot connect to Google, unless Comcast stops this blocking... or simply whitelists Google. But those false positives sound ugly and a bit malicious, not sure it is a good idea. > > I already wrote about this publicly, and also wrote a mail to EFF. Hope I am not spamming, I feel this is quite important issue and am a bit frustrated by the lack of attention it gets.

1 0

Re: [tor-relays] Comcast blocks ALL traffic with tor relays - probably firewall configuration; further tests
by xmrk2 13 Jun '23

13 Jun '23

Starting from the most interesting info - another Comcast customer contacted me, lets call him CCB, and the first Comcast customer I mentioned previously will be CCA. CCB claims he had to disable some settings - probably "Advanced Security" - in his Comcast router, because before doing so, nobody was able to connect to his lightning node via IPv4 (clearnet, not tor). He claims to have done this back in July or August. We tested just today, and both sides were able to successfully initiate TCP connection, no blocking here. Importantly, at the same time I was not able to connect to CCA - timeout. Chronology of tests, all times are in CEST. around 18:00 yesterday - I started tor relay (non-exit, ExitPolicy reject *:*) 22:09 - it appeared as online on https://metrics.torproject.org/ . Started testing connection to CCA, using "socat -dd - TCP4:<CCA_ADDR>:<CCA_lightning_port>" every 5 minutes. Connected successfully. 07:07 - last successful connection to CCA 07:12 - first unsuccessful connection to CCA - timeout; all subsequent tests with CCA end with timeout 08:10 - stopped tor relay 13:09 - 13:14 - tests with CCB - both sides can connect 17:54 - still cannot connect to CCA 18:19 - connected to CCA from my mobile phone connection (so from another IP, which is not blacklisted, so we see CCA is not offline) 18:55 - still cannot connect to CCA So port forwarding must be correct on CCA, or I would not be able to connect. Now I think the blocking is real, probably on by default, but Comcast customers can opt-out. Doubts / weaknesses of tests and theory: - only tested with 2 Comcast users - not sure about CCA's firewall settings - I just assume he has "Advanced Security" active - my tests only cover connections from me to Comcast users. Not sure if this "Advanced Security" also blocks connections from Comcast users. On one hand, my lightning channel with CCA was inactive for a month or more, and CCA contacted me because of it. Lightning nodes want and try to connect to all peers they have channel with, automatically - so his node presumably tried to connect to mine. And lightning nodes publish their IP addresses, there are sites which show current IP addresses of lightning nodes, like https://1ml.com/node/030c3f19d742ca294a55c00376b3b355c3c90d61c6b6b39554dbc7… (the link already points to a concrete node). My node should announce its IP addresses. So even if connection from me is blocked, he should initiate connection. Inactive channel means he was not successful, difficult to explain without blocking. OTOH, he claims he can connect to tor, so must be able to connect to at least some tor relay, not necessarily mine. Any volunteer Comcast customers for further testing? Preferably without lightning nodes, because I'd like to test with this "Adv. security" active, and it may interfere with lightning node (or any other use-case which needs high uptime). If my theory is correct, Comcast is slightly less evil than my very first post would suggest. Still evil, because this blocking has little to do with security - maybe blocking exit relays makes some sense, they can be misused to attacks, DDoS etc. But according to Comcast, merely running tor relay makes you a threat. And this so-called security is probably on by default (according to CCB) and "There are definitely popups all over the place telling me to turn it on". So it is probably not apparent that this setting blocks (some? most?) tor relays completely.

1 0

«Possible compression bomb» from Authority?
by Tschador 08 Jun '23

08 Jun '23

Hi there, today I found this warning in the log of my relay (6A7551EEE18F78A9813096E82BF84F740D32B911): Jun 03 04:04:33.000 [warn] Possible compression bomb; abandoning stream. Jun 03 04:04:33.000 [warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 199.58.81.140:80). What does this mean? Regards

4 3

Providing metrics relevant to relay operators
by Georg Koppen 07 Jun '23

07 Jun '23

Hello! I got recently pinged by a large exit operator asking whether we had a website with nice graphs and statistics relevant to relay operators on our project infrastructure (showing e.g. the largest exit operators etc.), but that's currently not the case and we should fix that. There are some third-party tools, like OrNetStats[1], but we think it would be very useful for our relay operators to have relevant information available on the Tor Project website itself. Those third-party projects are a good contribution to the overall ecosystem we have but might e.g. die at some point due to lack of maintenance or move their focus to particular parts of the network while neglecting others, which is fine in general. However, we as a project should make sure our relay operators and we ourselves are not losing important insights into the state of the network and its different relay groups in case anything like that happens. At the end of the day those statistics and graphs should show up on metrics.torproject.org but we are not there yet given the complex nature of that website and our plans to fix that. However, thanks to our efforts of setting up a database containing all the relay descriptors and other network documents and our ongoing Google Summer of Code project for making those accessible with the help of a network status API we can start to experiment with providing those statistics early on via a different venue. I've just filed a ticket tracking that process[2] for those of you who are interested. As always we are very much interested in collaboration and getting feedback from all of you. So, if you have particular statistics and graphs you would like to see on such a website, please speak up! Ideally, this would happen on the above-mentioned Gitlab issue but just replying to this thread or in private is fine as well. Thanks, Georg [1] https://nusenu.github.io/OrNetStats/ [2] https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/4…

1 0

Tor Relay Operator Poll (closes on 2023-05-30)
by nusenu 27 May '23

27 May '23

Hi, want to help shape the future of the Tor network? Here is a poll for you: https://cryptpad.fr/form/#/2/form/view/VE-b3bd-IS1P17Povh0ryIHYhqGqEiA7sJMR… It is open until 2023-05-30. Only operators that did run relays/bridges before 2023-04-01 (and are still running) may participate. An AROI or a relay fingerprint (or hashed bridge fingerprint) is required to participate. This poll happens in the context of working on a network health proposal. The goal of this poll is * to gather input from non-malicious relay operators * to help make pragmatical design decisions for an upcoming network health proposal * to ensure it remains practical to implement for relay operators * to get a feeling on whether it has a chance to see actual real world adoption * to get a feeling on whether relay operators would participate in a web of trust * to get a feeling on what type of rules relay operators would find acceptable In the light of malicious entities this poll has been send to large relay operators a few days ago so they can claim their submission first. Their feedback was also used to improve and extend the poll, if you submitted it already once you can submit it again but ensure to submit the same random string at the end as you did the first time so they can be linked. kind regards, nusenu -- https://nusenu.github.io

2 3

ContactInfo semantics
by nusenu 27 May '23

27 May '23

This is probably of interest to many relay operators: https://gitlab.torproject.org/tpo/community/relays/-/issues/71 > Write proposal to restrict contact information field to email address (and make it mandatory) https://gitlab.torproject.org/tpo/core/arti/-/issues/870 > Restrict contact information field in arti to just allow an email address kind regards, nusenu -- https://nusenu.github.io

1 0

Configuring key expiration warning messages?
by telekobold 22 May '23

22 May '23

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

3 2

Tor Relay Operator Meetup - April 15th, 2023 at 19 UTC
by gus 22 May '23

22 May '23

Hello, The next Tor Relay Operator Meetup will happen on April 15th, 2023, at 19 UTC. We're still working on the agenda, feel free to add your topics and/or questions on the pad: https://pad.riseup.net/p/tor-relay-op-meetup-april-keep onionsite: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor… 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! Gus -- The Tor Project Community Team Lead

2 2

mulitply ipv6 bridge lines for a single bridge
by Toralf Förster 21 May '23

21 May '23

Given that hosters of a VPS often gives a big /48, /56 or /64 ipv6 subnet to a VPS I do wonder if the BridgeLine for ipv6 could benefit from that? With ip6tables -t nat -I PREROUTING -p tcp -j DNAT --to-destination [obfs4 address] /usr/sbin/ip6tables-save > /etc/iptables/rules.v6 all incoming TCPv6 packets would be flow to the bridge address. This idea is implemented in [1]. BTW there I do change the factory default ipv6 address into a random one too. [1] https://github.com/toralf/tor-relays/blob/main/playbooks/roles/setup/tasks/… -- Toralf

1 0

PSA: Tor 0.4.5 reaches end of life (EOL) on 2023-02-15
by Georg Koppen 17 May '23

17 May '23

Hello! In case it affects you as you are still running your relay or bridge on Tor 0.4.5.x: the 0.4.5 series is going EOL on *2023-02-15* (roughly in 3 weeks from now). That's currently still 760 relays, which means roughly 7% of the advertised bandwidth of the network (and 387 bridges, which means roughly 9% of the advertised bridges bandwidth). Please make sure you have upgraded to the 0.4.7.x series by then. Supported releases in general can be found on the network team wiki.[1] Thanks, Georg [1] https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele…

6 8

Re: [tor-relays] MyFamily
by denny.obreham＠a-n-o-n-y-m-e.net 16 May '23

16 May '23

trinity pointard <trinity.pointard(a)gmail.com> wrote .. > . It's not as easy as having a unique ID, you need to make sure a > relay can't spoof being part of a family, that's why it requires a two > way relationship for now, and will probably use some form of signature > in the future. Why not take advantage of the proof entry of ContactInfo? ( https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/#pro… ) All you need to do is to add a file like https://example.com/.well-known/tor-relay/family-rsa-fingerprint.txt (uri-rsa) or DNS TXT record family-fingerprint.example.com (dns-rsa) which would contain one of the relay fingerprints of the family (the same one for all relays). The name is thus unique and you can easily check if the family name and corresponding relay fingerprint are linked to the same relay operator. The only drawback is if the chosen relay for the family name is removed from the network then a new one will have to be chosen and all the MyFamily values changed on every relay. Most likely a very rare event. Heck, a file https://example.com/.well-known/tor-relay/rsa-fingerprint.txt has already the same content as MyFamily. (Which I am guessing is one way "Alleged Family Members" are identified on Tor metrics.) _________________ > For an easy example, let's imagine that we let any relay put itself > into any family. Now suppose the attacker starts three relays A1, A2, > and A3. Then, since nothing stops them, they put A1 into a family > with every relay on the network, except for A2 and A3. Now, any time > a user (randomly) selects A1, they will find that the only other > relays they can use on that circuit are A2 and A3; this will build a > completely attacker-controlled path, they will get no privacy. How can you find a family with every relay on the network? According to the proposal, the largest family has 270 members and, according to Tor metrics, they are about 2000 exit relays. Even assuming an attacker controls A1 and A2, both falsely belonging to two different families with 250 members each (assuming all exit relays), the attacker would just increase his chances of having his A3 exit relay to be selected from 1/2000 to 1/1500. Not nothing, but not a large advantage either. The problem you are describing is actually one that is possible RIGHT NOW with MyFamily. An attacker CAN list all relay fingerprints he can find in its MyFamily except his relays. If he could only list ONE family name, he could only spoof it with the most popular family name used (assuming family name uniqueness is not enforced and more than one relay operator use the same name). But it is impossible that all [good] relay operators use the same family name, even if they would be allowed to select one as simple as "Smith". MyFamily with a single name seems both a very tiny spoofing problem AND an improvement over the current configuration.

2 1

MyFamily
by denny.obreham＠a-n-o-n-y-m-e.net 15 May '23

15 May '23

This has probably been addressed before but why isn't the MyFamily value just a single, unique ID? If I have the relays with the fingerprints "John", "Jane", and "Alice" and I want to add "Bob", wouldn't it be simpler (and more logical) to add the unique MyFamily "Smith" to each torrc file than listing all fingerprints? What do you do when you have 50 relays and want to add or remove a relay? You must modify 50 torrc files and restart all 50 relays? That seems tedious and unnecessary. I'm trying to find a way to automate this process and I can wrap my head around the complexity of the problem, especially with multiple servers. I could just use the fingerprint of my first relay as MyFamily (to ensure uniqueness) and then add it to every other torrc file I create in the future. Even if I remove the first relay from the network, the MyFamily value is still valid as a unique "family" name. I don't know the particular procedure, but even the process of blacklisting relays based on MyFamily, when selecting a relay, seems tedious. For example, the entry relay has 50 family members and the middle relay has 50 other family members, so I have to compare the potential exit relay "first" name to 100 "first" names instead of comparing its "family" name to two "family" names. Is this too complicated to implement or am I missing something? Denny

5 4

Open call for proposals for improving the health of the Tor relay operator community and the Tor network
by gus 11 May '23

11 May '23

Hello, We accomplished a number of things in our fight against malicious relays over the last 2 years[1]. One area we still need to focus on is strengthening our relay operator community. We're therefore currently collecting proposals from you or anyone else interested that could help to impove the health of the Tor relay operator community and, thus, provide our users a more trusted Tor network. We're accepting both new and old proposals, and we're open to any ideas you may have. Although there are various proposals for improving the network and the Tor relay operator community, not all of them are being enforced at the moment. Nevertheless, some proposals that can help on increasing trust have been adopted by a meaningful fraction of the Tor community (e.g. providing valid contact information). Another great example of such proposals is the "Expectations for Relay Operators"[2] document, where we guide relay operators to keep the Tor community and the network safe, healthy, and sustainable. We'd love to hear your proposal on how to make it more difficult for attackers to run relays while keeping it easy for good contributors to join our network. You can share your proposals on this GitLab ticket[3] and our tor-relays mailing list. It is worth noting that at the moment we are only trying to map these proposals to get an overview over the various options available. We're not in the process of approving any of them. If you have any experience, positive or negative, with Sybil-resistance and online abuse mitigation projects, we welcome your opinion as well. Since in this debate we have seen previous bad actors trying to game this process and thus lowering the effectiveness of our defenses, the Tor team will take all measures to stop people acting in bad faith and enforce the Tor Code of Conduct and policies. During the Tor Relay Operator Meetup on Saturday (March 4, 2023 - 19UTC), we will be discussing some of these proposals we've collected so far. Thank you, Gus [1] https://blog.torproject.org/malicious-relays-health-tor-network/ [2] https://gitlab.torproject.org/tpo/community/team/-/wikis/Expectations-for-R… [3] https://gitlab.torproject.org/tpo/community/relays/-/issues/55 -- The Tor Project Community Team Lead

4 11

Re: [tor-relays] For some reason, my bridge is still saying it has no distribution mechanism, despite it is listed as email in my torrc and says it is overloaded?
by Keifer Bly 23 Apr '23

23 Apr '23

Now its more confusing. That tool says the port is not reachable for both port 8080 and 8081. But the notices.log says the port is reachable. And apparently the accountigmax is being reached..... --Keifer On Wed, Apr 19, 2023 at 8:06 AM meskio <meskio(a)torproject.org> wrote: > Quoting Keifer Bly (2023-04-19 16:46:37) > > How to find that? > > https://community.torproject.org/relay/setup/bridge/post-install/ > > > It gave the message its reachable from the outside. > > This message is saying that the ORPort is reachable from outside, but it > doesn't > test for the obfs4 configured port. You can test it yourself if the port > is > reachable using our reachability test: > https://bridges.torproject.org/scan/ > > Or directly configure the bridgeline in Tor Browser and see if it connects > correctly. > > -- > meskio | https://meskio.net/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > My contact info: https://meskio.net/crypto.txt > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Nos vamos a Croatan.

1 1

OpenBSD DoS Mitigation
by null 21 Apr '23

21 Apr '23

Hi all, I'm running a Tor middle/guard relay on OpenBSD. I'm wondering if there are any steps I should take to guard my relay from DoS attacks. My thanks

4 3

For some reason, my bridge is still saying it has no distribution mechanism, despite it is listed as email in my torrc and says it is overloaded?
by Keifer Bly 19 Apr '23

19 Apr '23

Hi, So for my bridge at https://metrics.torproject.org/rs.html#details/4D6E3CA2110FC36D3106C86940A1… Despite my newest torrc, which is here: Nickname gbridge ORPort 8080 SocksPort 0 BridgeRelay 1 PublishServerDescriptor bridge BridgeDistribution email ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 0.0.0.0:8081 ExtOrPort auto Log notice file /var/log/tor/notices.log ExitPolicy reject *:* AccountingMax 50 GB ContactInfo keiferdodderblyyatgmaildoddercom It still says "Bridge Distribution Mechanism: None". However, that's VERY confusing as it is listed in the torrc file to be distributed by email and apparently despite that it is not distributed, it is overloaded somehow? This is confusing to me as why would it say no distribution mechanism when it is in the torrc as email, and how could it be overloaded if it's not being used? Thanks so much all, --Keifer

3 4

Police request regarding relay
by Finn 13 Apr '23

13 Apr '23

Hello everyone, We are hosting multiple relays under our AS 210558 and received an email from a local police station in Germany requesting user data, nothing unusual. The weird thing is, that the relay in question is only a relay and not an exit node since its creation (185.241.208.179) (https://nusenu.github.io/OrNetStats/w/relay/B67C7039B04487854129A66B16F5EE3…) - anyone has an idea how this happens? Best regards

5 6

new exit relay
by Linux-Hus Oni 12 Apr '23

12 Apr '23

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

4 4

Relay Bandwidth
by sysmanager7 03 Apr '23

03 Apr '23

Greetings all! Setting up a new Digital Ocean Tor Relay. DO is giving me 3000 Gig a month. Is there a tutorial that I can use to calculate the bandwidth? I've searched around the web and for some reason people seem to dance around the question. They give examples not relevant to me and zero math showing how the came to their answer. As usual, any help will be appreciated :-) Sysmanager7 Sent with [Proton Mail](https://proton.me/) secure email.

4 3

Re: [tor-relays] Selecting Exit Addresses
by denny.obreham＠a-n-o-n-y-m-e.net 31 Mar '23

31 Mar '23

The second IP is still in "Exit Addresses" with the new configuration ... https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF7D8F65B… torrc: Address 209.141.39.157 OutboundBindAddress 209.141.39.157 ORPort 9001 IPv4Only Denny denny.obreham(a)a-n-o-n-y-m-e.net wrote .. > Thanks Marco. > > First, I had to change my ORPort to 9001 with your proposed configuration because > using 443 caused an error => "Could not bind to 0.0.0.0:443: Address already in > use. Is Tor already running?" > Probably because my other Tor instance (hidden service) is using it. > > Now I'm just waiting for the metrics to update to see if everything is as expected. > > Finally, thanks for the help with IPv6 because I cannot get it to work. Somehow > when I try to check IPv6 availability ( https://community.torproject.org/relay/setup/post-install/ > ), I get "ping6: connect: Network is unreachable". I don't have time to set it > up right now (I already spent hours last week) so I'll get back to you for that. > > Denny > > lists(a)for-privacy.net wrote .. > > Hi denny, > > > > > Hi, > > > > > > I just activated my first exit relay. ( > > > https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF7D8F65B > > > 5881B7D4C97C ) I had the following in my torrc (plus some other things): > > > > I've answered the rest to the list. > > If you want to enable IPv6 at Frantech/BuyVM: > > > > First create one in Stallion from your given subnet. > > This is what my /etc/network/interfaces looks like at Frantech > > > > > > # This file describes the network interfaces available on your system > > # and how to activate them. For more information, see interfaces(5). > > > > source /etc/network/interfaces.d/* > > > > # The loopback network interface > > auto lo > > iface lo inet loopback > > > > # The primary network interface > > allow-hotplug eth0 > > iface eth0 inet static > > address 104.244.73.43/24 > > gateway 104.244.73.1 > > # dns-* options are implemented by the resolvconf package, if installed > > dns-nameservers 127.0.0.1 107.189.0.68 107.189.0.69 > > dns-search for-privacy.net > > > > iface eth0 inet6 static > > address 2605:6400:0030:f78b::2/64 > > up ip -6 route add 2605:6400:0030::1 dev eth0 > > up ip -6 route add default via 2605:6400:0030::1 > > down ip -6 route del default via 2605:6400:0030::1 > > down ip -6 route del 2605:6400:0030::1 dev eth0 > > dns-nameservers ::1 IPv6ns1 IPv6ns2 > > > > > > -- > > ╰_╯ Ciao Marco! > > > > Debian GNU/Linux > > > > It's free software and it gives you freedom!

2 1

Re: [tor-relays] Selecting Exit Addresses
by denny.obreham＠a-n-o-n-y-m-e.net 31 Mar '23

31 Mar '23

OK, finally got a configuration that looks like it works: Address 209.141.39.157 OutboundBindAddress 209.141.39.157 ORPort 209.141.39.157:9001 IPv4Only ORPort XXX.XXX.XXX.XXX:443 NoListen ORPort XXX.XXX.XXX.XXX:9001 NoListen Where XXX.XXX.XXX.XXX is the IP I didn't want to be used by my Tor exit relay. (The IPv4 flag is probably useless, I just didn't think to take it out after adding the IP to the port.) I'll see if abuse reports for my second IP will stop showing up on abuseipdb.com. Unless you find I did something wrong, thanks for helping, Denny denny.obreham(a)a-n-o-n-y-m-e.net wrote .. > The second IP is still in "Exit Addresses" with the new configuration ... https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF7D8F65B… > > torrc: > > Address 209.141.39.157 > OutboundBindAddress 209.141.39.157 > ORPort 9001 IPv4Only > > Denny > > denny.obreham(a)a-n-o-n-y-m-e.net wrote .. > > Thanks Marco. > > > > First, I had to change my ORPort to 9001 with your proposed configuration because > > using 443 caused an error => "Could not bind to 0.0.0.0:443: Address already > in > > use. Is Tor already running?" > > Probably because my other Tor instance (hidden service) is using it. > > > > Now I'm just waiting for the metrics to update to see if everything is as expected. > > > > Finally, thanks for the help with IPv6 because I cannot get it to work. Somehow > > when I try to check IPv6 availability ( https://community.torproject.org/relay/setup/post-install/ > > ), I get "ping6: connect: Network is unreachable". I don't have time to set it > > up right now (I already spent hours last week) so I'll get back to you for that. > > > > Denny > > > > lists(a)for-privacy.net wrote .. > > > Hi denny, > > > > > > > Hi, > > > > > > > > I just activated my first exit relay. ( > > > > https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF7D8F65B > > > > 5881B7D4C97C ) I had the following in my torrc (plus some other things): > > > > > > I've answered the rest to the list. > > > If you want to enable IPv6 at Frantech/BuyVM: > > > > > > First create one in Stallion from your given subnet. > > > This is what my /etc/network/interfaces looks like at Frantech > > > > > > > > > # This file describes the network interfaces available on your system > > > # and how to activate them. For more information, see interfaces(5). > > > > > > source /etc/network/interfaces.d/* > > > > > > # The loopback network interface > > > auto lo > > > iface lo inet loopback > > > > > > # The primary network interface > > > allow-hotplug eth0 > > > iface eth0 inet static > > > address 104.244.73.43/24 > > > gateway 104.244.73.1 > > > # dns-* options are implemented by the resolvconf package, if installed > > > dns-nameservers 127.0.0.1 107.189.0.68 107.189.0.69 > > > dns-search for-privacy.net > > > > > > iface eth0 inet6 static > > > address 2605:6400:0030:f78b::2/64 > > > up ip -6 route add 2605:6400:0030::1 dev eth0 > > > up ip -6 route add default via 2605:6400:0030::1 > > > down ip -6 route del default via 2605:6400:0030::1 > > > down ip -6 route del 2605:6400:0030::1 dev eth0 > > > dns-nameservers ::1 IPv6ns1 IPv6ns2 > > > > > > > > > -- > > > ╰_╯ Ciao Marco! > > > > > > Debian GNU/Linux > > > > > > It's free software and it gives you freedom!

1 0

Re: [tor-relays] Selecting Exit Addresses
by denny.obreham＠a-n-o-n-y-m-e.net 31 Mar '23

31 Mar '23

Thanks Marco. First, I had to change my ORPort to 9001 with your proposed configuration because using 443 caused an error => "Could not bind to 0.0.0.0:443: Address already in use. Is Tor already running?" Probably because my other Tor instance (hidden service) is using it. Now I'm just waiting for the metrics to update to see if everything is as expected. Finally, thanks for the help with IPv6 because I cannot get it to work. Somehow when I try to check IPv6 availability ( https://community.torproject.org/relay/setup/post-install/ ), I get "ping6: connect: Network is unreachable". I don't have time to set it up right now (I already spent hours last week) so I'll get back to you for that. Denny lists(a)for-privacy.net wrote .. > Hi denny, > > > Hi, > > > > I just activated my first exit relay. ( > > https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF7D8F65B > > 5881B7D4C97C ) I had the following in my torrc (plus some other things): > > I've answered the rest to the list. > If you want to enable IPv6 at Frantech/BuyVM: > > First create one in Stallion from your given subnet. > This is what my /etc/network/interfaces looks like at Frantech > > > # This file describes the network interfaces available on your system > # and how to activate them. For more information, see interfaces(5). > > source /etc/network/interfaces.d/* > > # The loopback network interface > auto lo > iface lo inet loopback > > # The primary network interface > allow-hotplug eth0 > iface eth0 inet static > address 104.244.73.43/24 > gateway 104.244.73.1 > # dns-* options are implemented by the resolvconf package, if installed > dns-nameservers 127.0.0.1 107.189.0.68 107.189.0.69 > dns-search for-privacy.net > > iface eth0 inet6 static > address 2605:6400:0030:f78b::2/64 > up ip -6 route add 2605:6400:0030::1 dev eth0 > up ip -6 route add default via 2605:6400:0030::1 > down ip -6 route del default via 2605:6400:0030::1 > down ip -6 route del 2605:6400:0030::1 dev eth0 > dns-nameservers ::1 IPv6ns1 IPv6ns2 > > > -- > ╰_╯ Ciao Marco! > > Debian GNU/Linux > > It's free software and it gives you freedom!

1 0

Selecting Exit Addresses
by denny.obreham＠a-n-o-n-y-m-e.net 31 Mar '23

31 Mar '23

Hi, I just activated my first exit relay. ( https://metrics.torproject.org/rs.html#details/3B85067588C3F017D5CCF7D8F65B… ) I had the following in my torrc (plus some other things): SocksPort 0 ControlPort 9052 ORPort 209.141.39.157:443 I have 2 IPs on my server and I wanted Tor to use 209.141.39.157. I thought setting it with ORPort would suffice. But under "Exit Addresses" in the metrics it was my other IP. So I added the following in my torrc: Address 209.141.39.157 OutboundBindAddress 209.141.39.157 And now I have both IPs in the "Exit Addresses". How can I prevent my exit relay from using the other IP? Note that I have also another instance of Tor running a hidden service that I intended to run on the other IP. Denny

2 2

Launch of new Tor Weather service
by Georg Koppen 31 Mar '23

31 Mar '23

Hello everyone! As indicated on the last relay operator meetup we were close to re-launching the Tor Weather service. Now, after fixing a bunch of last-minute issues and double-checking everything is working we can finally announce that the newly designed Tor Weather service is ready for public usage. Feel free to try it out at https://weather.torproject.org and help improving it! For those not knowing what this service is about: Tor Weather is offering subscriptions to keep track of the well-being of relays. Right now, after registering an account, one can get an e-mail notification in case a relay goes down or loses some flags or goes below a certain amount of observed bandwidth. The idea is to help operators in managing their relays that way and showing them their contribution to our project is much appreciated. There a many more things we can potentially offer subscriptions for, like getting notifications for upcoming relay operator meetups, having earned a Tor t-shirt, new relay requirements, running outdated Tor versions... You can find a current list of ideas in our bug tracker[1]; feel free to add missing ones and pick up issues to work on. This is a free software project after all. :) We see Tor Weather as an investment into our relay operator community and think it will be useful in the future to help growing and strengthening our community, which is very exciting. Finally, I'd like to give a big shout-out to Sarthik Gupta who did all the heavy-lifting and re-wrote Tor Weather during last years' Google Summer of Code and keeps improving it. Additionally, kez from our sysadmin team was invaluable in getting all the different pieces set up and running on our infrastructure. Thanks as well to all the volunteers, like nusenu, who contributed with ideas and feedback over the years which convinced us that Tor Weather is a worthwhile tool to invest time and energy in again. Georg [1] https://gitlab.torproject.org/tpo/network-health/tor-weather/-/issues

2 3

Notification when tor relay goes offline
by Keifer Bly 24 Mar '23

24 Mar '23

2 2

inet_csk_bind_conflict
by Christopher Sheats 21 Mar '23

21 Mar '23

Hello tor-relays, We are using Ubuntu server currently for our exit relays. Occasionally, exit throughput will drop from ~4Gbps down to ~200Mbps and the only observable data point that we have is a significant increase in inet_csk_bind_conflict, as seen via 'perf top', where it will hit 85% [kernel] utilization. A while back we thought we solved with with two /etc/sysctl.conf settings: net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_tw_reuse = 1 However we are still experiencing this problem. Both of our (currently, two) relay servers suffer from the same problem, at the same time. They are AMD Epyc 7402P bare-metal servers each with 96GB RAM, each has 20 exit relays on them. This issue persists after upgrading to 0.4.7.11. Screenshots of perf top are shared here: https://digitalcourage.social/@EmeraldOnion/109440197076214023 Does anyone have experience troubleshooting and/or fixing this problem? Cheers, -- Christopher Sheats (yawnbox) Executive Director Emerald Onion Signal: +1 206.739.3390 Website: https://emeraldonion.org/ Mastodon: https://digitalcourage.social/@EmeraldOnion/

6 20

Next Tor Relay Operator Meetup - March 4, 2023 (19 UTC)
by gus 19 Mar '23

19 Mar '23

Hi, The next Tor Relay Operator Meetup will happen on March 4, 2023, at 19 UTC! We're still working on the agenda, feel free to add your topics and/or questions on the pad: https://pad.riseup.net/p/tor-relay-op-meetup-m4-keep onionsite: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor… 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! Gus -- The Tor Project Community Team Lead

6 7

Confusing bridge signs...
by Keifer Bly 18 Mar '23

18 Mar '23

Hi, So my bridge at https://metrics.torproject.org/rs.html#details/4D6E3CA2110FC36D3106C86940A1… says it has “none “, though the torrc file has it set to be distributed publicly. I'm wondering why the bridge would say that, when it obviously is being used as it's apparently blocked in Russia? I have not personally given the bridge to anyone. Thanks. --Keifer

5 25

export iptables metrics
by Toralf Förster 17 Mar '23

17 Mar '23

I found the time and wrote a Bash script [1] to export iptables and ipset metrics to Prometheus/Grafana. It works at least with [2]. [1] https://github.com/toralf/torutils/blob/main/metrics.sh [2] https://github.com/toralf/torutils#readme -- Toralf

1 0

Too Many Connections
by Jeff Teitel 15 Mar '23

15 Mar '23

My node is overloaded with connections. Conntrack.sh shows count: 65535. By far the majority (50k+) are to/from my own IP. This sometimes makes my node unreachable. And now it is reporting the StaleDesc flag. There is nothing else running on this node (except bind9). I've already set up tor-ddos. What else can I do? -- Jeff Teitel e-Mail: Jeff(a)Teitel.net Mobile: +1-202-271-1238 (he/his)

2 1

Relay requirements
by Sydney 10 Mar '23

10 Mar '23

Newbie here. No network experience but already running 2 TOR instances: 1 TOR service + 1 bridge. I would like to "upgrade" to TOR relays but have a few questions relating to hardware needs. The [TOR-friendly] ISP I'm looking at have these 4 offers available: [1] 1 core @ 3.1GHz 1 GB RAM 10 TB/mo @ 5 Gbps BW [2] 1 core @ 3.1GHz 2 GB RAM10 TB/mo @ 5 Gbps BW [3] 2 core @ 3.1GHz4 GB RAM20 TB/mo @ 5 Gbps BW [4] 3 core @ 3.1GHz 12 GB RAM30 TB/mo @ 5 Gbps BW From [relay requirements](https://community.torproject.org/relay/relays-requirements/), my understanding is that [1] is what is expected for a guard or middle relay and [2] for an exit relay. My preferred choice at the moment is [3] where I would like to have 3 relays (one of each type; 3.5 GB RAM needed). Each relay would be limited to, say, 6.6 TB/mo BW. This would allow me to experiment and get used to the network and its requirements. My questions is about future increase. If I want to increase my offer to the TOR network I could: - Negotiate with my ISP to increase my BW to 30 TB/mo while still running on [3] and increase each BW limit to 10 TB/mo; - Move my 3 relays on [4] and increase each BW limit to 10 TB/mo; - Move my 3 relays on [4], add 2 IP addresses and 6 relays (2 of each type; 10.5 GB RAM needed total), and limit each relay to 3.3 TB/mo. I guess my fundamental question is what is the advantage of running multiple relays of the same type, on the same server? I see some operators running dozens of them, all in the same country, same ISP. Why not just a single relay running with a large capacity? Also, is there a requirement for the number of relays per core? (Maybe this is the answer to my question.) I know my bridge is currently keeping one core of my 2-core server constantly under load. Thank in advance.

3 3

Draft workshop submission "Running a high-performance pluggable transports Tor bridge"
by David Fifield 07 Mar '23

07 Mar '23

Linus Nordberg and I have been working together to run the main Snowflake bridge since April 2022. We are preparing a short paper (4 pages) for the FOCI workshop (https://foci.community/) on the special procedures required to operate a bridge that gets the large volume of traffic that a Snowflake bridge does. This is a draft of the submission: https://www.bamsoftware.com/papers/pt-bridge-hiperf/pt-bridge-hiperf.202303… https://www.bamsoftware.com/papers/pt-bridge-hiperf/pt-bridge-hiperf.202303… I am posting the draft here to see if anyone has feedback or comments. If you do, our submission deadline is 2023-03-15. The main ideas were worked out in a thread on this very list: https://forum.torproject.net/t/tor-relays-how-to-reduce-tor-cpu-load-on-a-s… The core problem is that a single tor process is limited to a single CPU core. The main fix is to run multiple tor processes, and synchronize their identity and onion keys externally. It has been essential to enable scaling in the Snowflake bridge; but the same trick may be useful (minus the pluggable transport part) for other relays that process a much larger amount of traffic than average, such as large exit relays. (Though it's not clear that one exit with 2× the capacity is really any different than 2 exits in the same family.) This is also somewhat related to the current discussion about increasing the limit on the number of relays per IP address, which is a concession to the limited scalability of one tor process: https://bugs.torproject.org/tpo/core/tor/40744 > While this is great in general, it also adds significant complexity > for Tor operators since Tor does not scale well on multi-core CPU's. > In order to effectively use a modern server with a large amount of > threads, you would need to run many Tor relays.

1 0

D5A3882CBDBE4CAD2F9DDA2AB80FE761BEDC3F11 is spoofing my contact info
by lists＠for-privacy.net 06 Mar '23

06 Mar '23

This is _not_ my relay: https://metrics.torproject.org/rs.html#details/D5A3882CBDBE4CAD2F9DDA2AB80F… https://nusenu.github.io/OrNetStats/w/relay/D5A3882CBDBE4CAD2F9DDA2AB80FE76… -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

3 2

Storing ed25519_master_id_secret_key[_encrypted] on a smartcard?
by telekobold 04 Mar '23

04 Mar '23

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/Offl…

1 1

RFC: does a private exit would work?
by Toralf Förster 04 Mar '23

04 Mar '23

tl;dr; restricted access + usage of an exit longer: An exit is sooner or later abused. A reduced exit policy does not prevent that. What about setup a tor exit relay with 'PublishServerDescriptor = 0' ? Having an access line like for bridges would restrict the access. An alternative could be a port knockig + iptables solution. Objections and comments are welcome. -- Toralf

5 5