- tor-relays - lists.torproject.org

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