Re: [tor-dev] Proposal XXX: FlashFlow: A Secure Speed Test for Tor (Parent Proposal)

> On 16 May 2020, at 16:05, Mike Perry wrote: > >> On 4/23/20 1:48 PM, Matt Traudt wrote: >> >> 5.4 Other Changes/Investigations/Ideas >> >> - How can FlashFlow data be used in a way that doesn't lead to poor >> load balancing given the following items that lead to non-uniform >> client

Re: [tor-dev] Deprecating Tor Protocol Versions

Hi David, > On 15 May 2020, at 20:53, David Goulet wrote: > > On 15 May (13:58:06), teor wrote: >> >> Nick and I were talking about how we remove legacy features in tor, >> and their corresponding subprotocol versions. >> >> Here is a list of the

[tor-dev] Deprecating Tor Protocol Versions

ends on Relay=2 EXTEND2 cells. So if we were checking EXTEND2 cell support, it would be Relay=2 or Relay=3.) T -- teor -- signature.asc Description: Message signed with OpenPGP _

Re: [tor-dev] Chutney code refactoring

Hi Caitlin, > On 15 May 2020, at 09:59, Nick Mathewson wrote: > > On Thu, May 14, 2020 at 7:04 PM c wrote: >> >>> On Sat, 18 Apr 2020 11:02:03 + >>> c wrote: >>> >>> I came across Node.specialize() which does not seem to be called >>> elsewhere, and I cannot guess at its purpose. >>

Re: [tor-dev] Proposal 320: Removing TAP usage from v2 onion services

Hi Nick, > On 14 May 2020, at 00:09, David Goulet wrote: > > On 11 May (16:47:53), Nick Mathewson wrote: > >> ``` >> Filename: 320-tap-out-again.md >> Title: Removing TAP usage from v2 onion services >> Author: Nick Mathewson >> Created: 11 May 2020 >> Status: Open >> ``` >> >> (This

Re: [tor-dev] Proposal 320: Removing TAP usage from v2 onion services

Hi Nick, > On 12 May 2020, at 06:48, Nick Mathewson wrote: > > ## Migration steps > > First, we implement all of the above, but set it to be disabled by > default. We use torrc fields to selectively enable them for testing > purposes, to make sure they work. Can you expand on the testing

Re: [tor-dev] Proposal 319: RELAY_FRAGMENT cells

Hi Nick, > On 12 May 2020, at 06:47, Nick Mathewson wrote: > > In this proposal, > we allow the following cell types to be fragmented: EXTEND2, EXTENDED2, > INTRODUCE1, INTRODUCE2, RENDEZVOUS. Any party receiving a command that they > believe should not be fragmented should close the circuit.

Re: [tor-dev] Proposal 318: Limit protover values to 0-63

Hi Nick, > On 12 May 2020, at 06:47, Nick Mathewson wrote: > > ``` > Filename: 318-limit-protovers.md > Title: Limit protover values to 0-63. > Author: Nick Mathewson > Created: 11 May 2020 > Status: Open > ``` > > # Limit protover values to 0-63. > > I propose that we no longer accept

Re: [tor-dev] [RFC] Proposal: A First Take at PoW Over Introduction Circuits

Hi tevador, > On 9 May 2020, at 06:43, tevador wrote: >> For our dynamic PoW system to work, we will need to be able to compare PoW >> tokens with each other. To do so we define a function: >>unsigned effort(uint8_t *token) >> which takes as its argument a hash output token, and returns

[tor-dev] Proposal Idea: IPv6-Only Exit Relays

tterns. So there are also some benefits to randomisation. If I get time, I'd like to turn these ideas into a proposal. T -- teor -- ___ tor-dev mailing list tor-dev@lists.torproject

Re: [tor-dev] Tor Relay wont connect to private IP address

Hi Eli, > On 29 Apr 2020, at 07:40, Eli Vakrat wrote: > > So thanks to teor's insightful response yesterday I decided to try to run a > second tor relay (my middle node) on my private network. > > Unfortunately, I can't do it with Chutney because my python client is running > on a windows

Re: [tor-dev] Relay Truncated Cell Example

Hi Eli, >> On 28 Apr 2020, at 11:47, Eli Vakrat wrote: > But then I looked at the debug log of my guard node (remember that my guard > node is on my local machine) and it said that it had received a DESTROY Cell > back from the middle node and was passing on a RELAY_TRUNCATED cell to me: > >

Re: [tor-dev] Proposal 316: FlashFlow: A Secure Speed Test for Tor (Parent Proposal)

Hi Matt, Thanks for the quick response! I've trimmed the conversation to the comments that need further discussion. > On 25 Apr 2020, at 06:46, Matt Traudt wrote: > > On 4/23/20 21:05, teor wrote: >> ... >> >>> - msm_duration [1 byte] >> >> Wha

Re: [tor-dev] Building a privacy-preserving "contact tracing" app

Hi Adrien, > On 22 Apr 2020, at 16:35, Adrien Luxey wrote: > > The French state is making a glosing about the "privacy-preserving", > "anonymous" contact tracing app they are developing with Inria (national > informatics research agency). You can check about the protocol proposal, > ROBERT,

Re: [tor-dev] Proposal XXX: FlashFlow: A Secure Speed Test for Tor (Parent Proposal)

Hi, Thanks for this proposal! I'm looking forward to more secure bandwidth measurements on the Tor network. Overall, this proposal looks good. But I'm particularly concerned about any communication between bandwidth coordinators. Our general principle is that directory authorities should be

Re: [tor-dev] Proposal 315: Updating the list of fields required in directory documents

Hi Nick, This proposal is missing the "bridge" case. Bridges are more complicated, because we have at least 3 kinds of bridges: * bridges distributed by BridgeDB * bridges distributed with apps (such as Tor Browser) * private bridges Bridge option transitions are also more complicated, because

Re: [tor-dev] Fallback Directory Handover

> On 22 Apr 2020, at 12:27, Ian Goldberg wrote: > > On Wed, Apr 22, 2020 at 11:56:54AM +1000, teor wrote: >> a bad fallback guard can continue to manipulate its client's view of >> the network > > This is only true to the extent that the fallback guard can choose w

[tor-dev] Fallback Directory Handover

rds, so transient systems like TAILS won't benefit from this change. T -- teor -- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Chutney tests fail for tor/maint-0.3.5 (bug #33677)

Hi Caitlin, > On 1 Apr 2020, at 18:58, c wrote: > > On Mon, 30 Mar 2020 13:22:21 +1000 > teor wrote: > >> Check for onion service descriptor uploads: >> https://trac.torproject.org/projects/tor/ticket/33609 >> >> Someone else is working on th

Re: [tor-dev] Chutney tests fail for tor/maint-0.3.5 (bug #33677)

Hi, > On 28 Mar 2020, at 21:42, c wrote: > > For the Outreachy.org internship project I decided to take on bug > #33677 [1]. Thanks for applying for Outreachy with us. > I followed steps to run `make test-network-all` both on tor master and > maint-0.3.5 branches, using Chutney master branch.

Re: [tor-dev] Walking onions status update: week 3 notes

Hi Nick, This is from week 3: > On 30 Mar 2020, at 07:16, Nick Mathewson wrote: > >> There's a faster calculation and more efficient encoding for >> Weighted, because there's a common factor in each POS() >> calculation: >> (1 << 32) / total_weight >> >> If we remove that factor, we end up

Re: [tor-dev] Walking onions status update: week 4 notes

Hi Nick, > On 30 Mar 2020, at 09:18, Nick Mathewson wrote: > > Walking Onions: week 4 update > > … > > == Next steps > > In this coming week I plan to try to wrap up section 3 on voting and > section 5 on extending circuits. I'm going to go back to the start > of section 2 and start

Re: [tor-dev] Walking onions status update: week 3 notes

Hi Nick, > On 21 Mar 2020, at 05:38, Nick Mathewson wrote: > > Walking Onions: week 3 update > > As you might recall, the SNIPs need to be nice and small, but they > need to be completely self-contained. The ENDIVE, on the other > hand, needs to be diff-friendly, and compressible. Relays

Re: [tor-dev] Walking Onions status update: week 2 notes

Hi Nick, > On 20 Mar 2020, at 23:01, Nick Mathewson wrote: > > On Wed, Mar 18, 2020 at 11:21 AM teor wrote: >> >>> On 14 Mar 2020, at 14:44, teor wrote: >>> >>>> * As I work, I'm identifying other issues in tor that stand in >>>>

Re: [tor-dev] Walking Onions status update: week 2 notes

Hi Nick, > On 14 Mar 2020, at 14:44, teor wrote: > >> * As I work, I'm identifying other issues in tor that stand in >>the way of a good efficient walking onion implementation that >>will require other follow-up work. This week I ran into a >>ne

Re: [tor-dev] Lets give every circuit its own exit IP?

Hi, > On 8 Mar 2020, at 08:36, nusenu wrote: > > Would it help to write a short proposal to move this forward? Yes, proposals help us know what to implement, when we have time. The proposal can be short, but it needs to describe the feature in enough detail, that a developer could implement

[tor-dev] Auto close old tor GitHub pull requests?

anywhere between 30 and 180 days would work. (Most of our backports happen within 60 days.) For more details, see: https://trac.torproject.org/projects/tor/ticket/33629 T -- teor

Re: [tor-dev] Walking Onions status update: week 2 notes

Hi Nick, I'm interested in following along with Walking Onions, but I might drop out when the relay IPv6 work gets busy. I'm not sure how you'd like feedback, so I'm going to try to put it in emails, or in pull requests. (I made one comment on a git commit in walking-onions-wip, but I'm not

Re: [tor-dev] interested in working on a ticket

Hi Amir, > On 23 Feb 2020, at 10:28, indigo omega wrote: > > I am a new contributor interested in working on ticket 13184: > https://trac.torproject.org/projects/tor/ticket/13184 . > The ticket says that it was assigned 8 months ago, but then deleted? I am > having trouble understanding if

Re: [tor-dev] TOR Browser Circuit Selection of Exit Nodes

Hi, Thanks for your interest in Tor's path selection algorithm. Some of my colleagues are working on "vanguards", which significantly changes path selection. I think this is their latest proposal: https://gitweb.torproject.org/torspec.git/tree/proposals/292-mesh-vanguards.txt I'll let them

[tor-dev] Making Tor's CI Faster

for backports, because each 0.3.5 backport updates 9 branches: * {maint,release}-{0.3.5,0.4.1,0.4.2,0.4.3} and * master. T -- teor -- signature.asc Description: Message signed with OpenPGP

Re: [tor-dev] Proposal 313: Relay IPv6 Statistics

Hi Karsten, Nick, Thanks for your feedback! I've removed the sections without your comments, to keep this email short. > On 10 Feb 2020, at 20:49, Karsten Loesing wrote: > >> On 2020-02-10 07:36, teor wrote: > > I'm including some comments below. > >> Here is a

[tor-dev] Proposal 313: Relay IPv6 Statistics

IPv6 Statistics Author: teor Created: 10-February-2020 Status: Draft Ticket: #33159 0. Abstract We propose that Tor relays (and bridges) should log the number of relays in the consensus that support IPv6 extends, and IPv6 client connections. We also propose that Tor relays (and bridges

Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses

Hi, > On 4 Feb 2020, at 07:17, s7r wrote: > > teor wrote: >> Hi s7r, >> >> Thanks for bringing up IPv6 address privacy extensions. >> >>> On 30 Jan 2020, at 02:19, s7r wrote: >>> >> >> I read RFCs 4941 and 3041, looked at the

Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses

implemented. I'll send another full text to the list when all the reviews are done. I've also responded to your comments below individually: > On 31 Jan 2020, at 08:08, Nick Mathewson wrote: > > On Wed, Jan 29, 2020 at 9:04 AM teor wrote: > > Hello again! This looks like anothe

Re: [tor-dev] Proposal 312: Automatic Relay IPv6 Addresses

Hi s7r, Thanks for bringing up IPv6 address privacy extensions. > On 30 Jan 2020, at 02:19, s7r wrote: > > There is another RFC (older), that is in use by Debian apparently: > RFC3041. https://tools.ietf.org/rfc/rfc3041.txt > > From: >

[tor-dev] Proposal 312: Automatic Relay IPv6 Addresses

/projects/tor/ticket/33073 https://trac.torproject.org/projects/tor/ticket/5940 Please feel free to reply on this list, or via GitHub pull request comments. Filename: 312-relay-auto-ipv6-addr.txt Title: Tor Relays Automatically Find Their IPv6 Address Author: teor Created: 28-January-2020 Status: Draft

Re: [tor-dev] Prop 311: Relay IPv6 Reachability

comments below individually: > On 25 Jan 2020, at 06:09, Nick Mathewson wrote: > > On Fri, Jan 24, 2020 at 1:31 AM teor wrote: >> >> >> Here is an initial draft of Proposal 311: Relay IPv6 Reachability. >> >> This proposal includes: >> * re

[tor-dev] Prop 311: Relay IPv6 Reachability

://trac.torproject.org/projects/tor/ticket/24403 Please feel free to reply on this list, or via GitHub pull request comments. Filename: 311-relay-ipv6-reachability.txt Title: Tor Relay IPv6 Reachability Author: teor Created: 22-January-2020 Status: Draft Ticket: #24404 0. Abstract We propose

Re: [tor-dev] Updates to Prop306: A Tor Implementation of IPv6 Happy Eyeballs

led. This is so we can attempt another entry node. 3.3. Connection Attempt Delays As mentioned in [TEOR-P306-REP], initially, clients should prefer IPv4 by default. The Connection Attempt Delay, or delay between IPv4 and IPv6 connections should be 250 msec. This is to avoid the o

Re: [tor-dev] Updates to Prop306: A Tor Implementation of IPv6 Happy Eyeballs

u please review this proposal? Overall, I think the proposal is too complicated. It doesn't tell us what changes are necessary, important, and optional. So it will be hard to review and implement. I have asked for these changes a few times now, but I can't see them in your pull request: > On

Re: [tor-dev] Onion DoS: Killing rendezvous circuits over the application layer

Hi, There's also another negative we haven't considered: > On 3 Dec 2019, at 00:16, George Kadianakis wrote: > > Negatives: > > a) It's a dirty hotfix that blends the networking layers and might be annoying > to maintain in the long-term. > > b) It only works for HTTP (and without SSL?).

Re: [tor-dev] Practracker regen in #30381

Hi, > On 28 Nov 2019, at 15:43, teor wrote: > >> On 27 Nov 2019, at 22:34, George Kadianakis wrote: >> >> teor writes: >> >>> It looks like you regenerated the whole practracker file in #30381: >>> https://trac.torproject.org/projects/tor/ti

Re: [tor-dev] Practracker regen in #30381

Hi, > On 27 Nov 2019, at 22:34, George Kadianakis wrote: > > teor writes: > >> It looks like you regenerated the whole practracker file in #30381: >> https://trac.torproject.org/projects/tor/ticket/30381 >> https://github.com/torproject/tor/commit/53ac9a9a91a8f2a

Re: [tor-dev] Raising exceptions in add_event_listener() threads (was Re: HSv3 descriptor work in stem)

Hi George, > On 28 Nov 2019, at 02:04, George Kadianakis wrote: > > Hello Damian (and list), > > here is another question about an issue I have encountered while > developing onionbalance v3. > > In particular, I'm fetching HS descriptors using HSFETCH and then adding > an

[tor-dev] Practracker regen in #30381

for the files that we modified. When we do a full regeneration, we lose a whole lot of warnings that tell us where our code quality is getting worse. Do you mind if I revert the unrelated changes? T -- teor

Re: [tor-dev] reproducible builds for Android tor daemon

Hi, > On 12 Sep 2019, at 20:50, Hans-Christoph Steiner > wrote: > > Then that work > will hopefully be extended into sharing tor between apps, e.g. letting > Briar, Tor Browser, etc share the tor SOCKS proxy to other apps that > want to use it. That would happen via Android mechanisms like

Re: [tor-dev] Putting onion services behind a third-party TCP proxy

> On 20 Aug 2019, at 13:31, Pop Chunhapanya wrote: > > Hi Tim, > >> >> TCPProxy protocol host:port >> >> Tor will use the given protocol to make all its OR (SSL) connections through >> a TCP proxy on host:port, rather than connecting directly to servers. You >> may want to set

Re: [tor-dev] TBB Memory Allocator choice fingerprint implications

Hi, > On 18 Aug 2019, at 08:35, Shawn Webb wrote: > > Having the heap implementation selectable at runtime would enable > users to make the determination for themselves, while also making > future integration efforts easier through modularization/abstraction > APIs (I'm making a silly, naive,

Re: [tor-dev] Putting onion services behind a third-party TCP proxy

> On 16 Aug 2019, at 04:52, Pop Chunhapanya wrote: > > Hi Tim, > >> The only protocol supported right now 'haproxy'. This option is only for >> clients. (Default: none) > > I think TCPProxy option is more generic than HTTPSProxy, Socks4Proxy and > Socks5Proxy. Why don't we also allow https,

Re: [tor-dev] [prop305] Introduction Point Behavior

Hi David, > On 15 Aug 2019, at 22:56, David Goulet wrote: > > I'm leaning towards not closing the circuit and falling back on the consensus > parameters. Using the consensus parameters seems like a good thing to do. We can say "valid parameters override the consensus parameters. Invalid

Re: [tor-dev] Putting onion services behind a third-party TCP proxy

Hi Haxxpop, > On 15 Aug 2019, at 16:53, Pop Chunhapanya wrote: > > >>> So I'm thinking putting the tor daemon behind some third party TCP proxy >>> that will protect me from this kind of DDoS attack. >>> >>> What do you think if I want to implement a feature that forward all the >>> onion

Re: [tor-dev] Putting onion services behind a third-party TCP proxy

Hi, > On 15 Aug 2019, at 05:10, Pop Chunhapanya wrote: > > When deploying an onion service, I noticed some problem that the ip address > of my machine that runs tor daemon is exposed to the Tor network which is > vulnerable to the DDoS attack if someone knows my ip address. You can reject

Re: [tor-dev] New Proposal 306: A Tor Implementation of IPv6 Happy Eyeballs

Hi Nick, > On 3 Aug 2019, at 01:25, Nick Mathewson wrote: > >> On Tue, Jun 25, 2019 at 9:24 PM wrote: >> >> Hi tor-dev@ mailing list, >> >> I have a new proposal: A Tor Implementation of IPv6 Happy Eyeballs >> >> This is to implement Tor IPv6 Happy Eyeballs and acts as an alternative >> to

Re: [tor-dev] New Proposal 306: A Tor Implementation of IPv6 Happy Eyeballs

Hi, > On 2 Aug 2019, at 13:02, NOC wrote: > > That would imply that guard relays run at 100% capacity which i can't confirm > for any of my guards. I have run guards at 100% before, but it's not ideal. Generally, Tor load-balances traffic to make sure that clients get consistently good

Re: [tor-dev] New Proposal 306: A Tor Implementation of IPv6 Happy Eyeballs

Hi, > On 2 Aug 2019, at 09:20, NOC wrote: > > I see this staying longer with IPv4 longer than we should also problematic, > we are at the point that there are providers out there who do have more > clients than IPv4 space which results in having them making carrier grade > NAT. Some of them

Re: [tor-dev] New Proposal 306: A Tor Implementation of IPv6 Happy Eyeballs

Hi Neel, > On 30 Jul 2019, at 03:11, Neel Chauhan wrote: > > Just a reminder that this proposal (Prop306) needs to be reviewed: > https://github.com/torproject/torspec/pull/87 I can't find these changes that I requested to the proposal: >> On 14 Jul 2019, at 02:47, teor wr

Re: [tor-dev] New Proposal 306: A Tor Implementation of IPv6 Happy Eyeballs

ed your requested changes and the GitHub PR is here: >https://github.com/torproject/torspec/pull/87 > >Hopefully I have not missed anything. > >Most of these changes you (Iain and Teor) suggested sound good. I'm not > >a huge fan of preferring IPv4 in the case of tunneled IPv6 connec

Re: [tor-dev] resolving DNS TXT records?

allow connections to TCP port 53, so you can do arbitrary DNS queries to any DNS server using those exits. >https://gitweb.torproject.org/torspec.git/tree/proposals/219-expande

Re: [tor-dev] exitmap/RESOLVE control command limitations

dress. >I'm aiming to resolve a hostname and would like to get >the IPv4 and if available the IPv6 address. I don't know how you can reliably get the IPv6 address over SOCKS, when the site has an IPv4 address. Try using the controller RESOLVE command and ADDRMAP event, which supports IPv6:

Re: [tor-dev] New Proposal 306: A Tor Implementation of IPv6 Happy Eyeballs

n this design, Tor will first connect to the preferred address and >> attempt to authenticate. After a 1.5 second delay, Tor will connect >> to the alternate address and try to authenticate. On the first >> successful authenticated connection, we close the other connect

[tor-dev] Changed Network Team Meeting Times

ere is our meeting schedule for July: * Wednesday 3 July 2300 UTC - Changed Day! * Monday 8 July at 1700 UTC * (In-person meeting 12-14 July) * Monday 22 July 1700 UTC * Monday 29 July 1700 UTC T -- teor -- sig

Re: [tor-dev] Per-peer stream isolation for Bitcoin clients

Hi Jeremy, > On 28 Jun 2019, at 06:35, Jeremy Rand wrote: > > 2. Per-peer stream isolation prevents a single exit relay from feeding > the user a chain that's not the longest chain, so it's desirable from a > Bitcoin security point of view. Tor itself uses 3 directory guards to make sure that

Re: [tor-dev] New Proposal 306: A Tor Implementation of IPv6 Happy Eyeballs

k or two for other people to provide feedback on this thread. T >> On 2019-06-25 23:33, teor wrote: >> Hi Neel, >> Thanks for this proposal. >>> On 26 Jun 2019, at 11:15, n...@neelc.org wrote: >>> I have a new proposal: A Tor Implementation of IPv6 Happy Eye

Re: [tor-dev] New Proposal 306: A Tor Implementation of IPv6 Happy Eyeballs

e the connection. In this case, we should cancel all other > >connection timers and in-progress connections. Cancelling the timers is > >so we don't attempt new unnecessary connections when our existing > >connection is successful, pre

Re: [tor-dev] Shortcomings of the pluggable transports specification?

Hi Philipp, > On 13 Jun 2019, at 09:41, Philipp Winter wrote: > > We are working on improving Tor's pluggable transports specification: > > > The goal is to make the spec useful to more people and fix issues that > have accumulated over the years. For

Re: [tor-dev] Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension

Hi, > On 12 Jun 2019, at 22:39, George Kadianakis wrote: > > David Goulet writes: > >> Filename: 305-establish-intro-dos-defense-extention.txt >> Title: ESTABLISH_INTRO Cell DoS Defense Extension >> Author: David Goulet, George Kadianakis >> Created: 06-June-2019 >> Status: Draft >> > >

Re: [tor-dev] Dealing with critical sbws tickets

Hi, > On 4 Jun 2019, at 15:29, juga wrote: > > teor: >> Hi juga, >> >> I read your meeting notes from this week's network team meeting: >> >> juga(offline): >> Week of 05/20 (planned) >> - Add Tor version to the bandwidth file (#30

Re: [tor-dev] Metrics for evaluating sbws vs torflow? (was: Raising AuthDirMaxServersPerAddr to 4)

Hi, > On 4 Jun 2019, at 12:54, Mike Perry wrote: > > teor: >> >> >>> On 4 Jun 2019, at 06:20, Mike Perry wrote: >>> >>> Mike Perry: >>>> teor: >>>>> I have an alternative proposal: >>>>> >

Re: [tor-dev] Raising AuthDirMaxServersPerAddr to 4?

Hi Mike, > On 4 Jun 2019, at 06:20, Mike Perry wrote: > > Mike Perry: >> teor: >>> I have an alternative proposal: >>> >>> Let's deploy sbws to half the bandwidth authorities, wait 2 weeks, and >>> see if exit bandwidths improve. >>

Re: [tor-dev] Raising AuthDirMaxServersPerAddr to 4?

Hi, > On 3 Jun 2019, at 17:48, Roger Dingledine wrote: > >> On Sun, Jun 02, 2019 at 10:43:14PM +1000, teor wrote: >> Let's deploy sbws to half the bandwidth authorities, wait 2 weeks, and >> see if exit bandwidths improve. >> >> We should measure the impact

Re: [tor-dev] Raising AuthDirMaxServersPerAddr to 4?

onsensus straight away. There shouldn't be too many, but let's double-check. T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.

[tor-dev] Detailed relay diagnostics for Re: Raising AuthDirMaxServersPerAddr to 4?

Hi, Here are some detailed diagnostics. My overall conclusion is: there isn't much bandwidth left on that exit. > On Sun, Jun 02, 2019 at 01:30:18PM +1000, teor wrote: >> Which bandwidth authorities are limiting the consensus weight of these >> relays? Where are they locate

Re: [tor-dev] Raising AuthDirMaxServersPerAddr to 4?

Hi, > On 2 Jun 2019, at 18:21, Roger Dingledine wrote: > > On Sun, Jun 02, 2019 at 01:30:18PM +1000, teor wrote: >> Which bandwidth authorities are limiting the consensus weight of these >> relays? Where are they located? > > The one in question is in Sweden: >

Re: [tor-dev] Release: obfs4proxy-0.0.10

Hi, On 5 May 2019, at 07:02, Steve Snyder wrote: > On 5/4/19 12:26 PM, David Fifield wrote: >> On Sat, May 04, 2019 at 03:27:53PM +, Yawning Angel wrote: >>> On 5/3/19 1:48 PM, Steve Snyder wrote: FYI, obfs4proxy no longer recognizes address:port in this form:

Re: [tor-dev] Raising AuthDirMaxServersPerAddr to 4?

Hi, > On 2 Jun 2019, at 13:30, teor wrote: > > On 2 Jun 2019, at 05:22, Roger Dingledine wrote: >> >> I've been talking to a longtime exit relay operator, who is in the >> odd position of having a good 1gbit network connection, but only one >> IP address.

Re: [tor-dev] Raising AuthDirMaxServersPerAddr to 4?

Hi all, > On 2 Jun 2019, at 05:22, Roger Dingledine wrote: > > I've been talking to a longtime exit relay operator, who is in the > odd position of having a good 1gbit network connection, but only one > IP address. > > He used to push an average of 500mbit on his exit relay, but then the >

[tor-dev] Should we allow matrix.org users on tor IRC channels?

Hi all, JeremyRand has asked us to allow matrix.org users on the tor IRC channels on irc.oftc.net. matrix.org users are rejected at the moment, because they are not registered with OFTC. For details, see: https://trac.torproject.org/projects/tor/ticket/30717 T -- teor

Re: [tor-dev] Merger and Mainline Handovers

> On 31 May 2019, at 02:26, Nick Mathewson wrote: > >> On Wed, Apr 17, 2019 at 5:13 AM teor wrote: >> When does 0.4.0 stop being mainline? >> >> It looks like people aren't merging backports to 0.4.0 any more. >> That's probably a good idea: we shoul

Re: [tor-dev] Onion Service - Intropoint DoS Defenses

Hi, > On 30 May 2019, at 23:49, David Goulet wrote: > > Over the normal 3 intro points a service has, it means 150 introduction > per-second are allowed with a burst of 600 in total. Or in other words, 150 > clients can reach the service every second up to a burst of 600 at once. This >

[tor-dev] Next Network Team Meeting Times

schedule after that: * Monday 10 June at 1700 UTC * Monday 17 June at 1700 UTC * Monday 24 June at 1700 UTC We meet in the #tor-meeting channel on irc.oftc.net. T -- teor -- signature.asc Description: Message signed

Re: [tor-dev] TrackTor - GUI Based Implementation for Monitoring Tor

Hi Harsh, > On 12 May 2019, at 20:57, Harsh Gandhi <2015ucp1...@mnit.ac.in> wrote: > > We are under-graduate students from Malaviya National Institute of Technology > currently pursuing Computer Science & Engineering. > > We have developed a GUI Based Tool for monitoring TOR (inspired by

Re: [tor-dev] Network Health Monitoring

Hi, > On 15 May 2019, at 22:40, David Goulet wrote: > >> On 08 May (13:27:31), Iain Learmonth wrote: >> Hi All, >> >> I'm working on #28322 to improve the monitoring of Tor Metrics services, >> but this also has the side effect of monitoring network health. For >> example, we'd like to know

Re: [tor-dev] Proposal 302: Hiding onion service clients using WTF-PAD

> On 21 May 2019, at 00:35, George Kadianakis wrote: > > Tom Ritter writes: > >>> On Thu, 16 May 2019 at 11:20, George Kadianakis >>> wrote: >>>3) Duration of Activity ("DoA") >>> >>> The USENIX paper uses the period of time during which circuits send and >>> receive cells to

Re: [tor-dev] Proposing sbws changes

timezones, only some people were there. I'll try to summarise the meeting discussion as well. Juga wrote some questions in the team meeting pad. I'll try to answer their questions here. >> On 22 Apr 2019, at 14:54, teor wrote: >> >> We finished our first working version of sbws in M

[tor-dev] PrivCount Status

back from leave. I am also happy if Nick wants to clean up this code. See also my previous email about BridgeDB and PrivCount. Maybe we can save ourselves some effort by using PrivCount's obfuscation on BridgeDB's statistics. T -- teor

Re: [tor-dev] Export BridgeDB usage statistics

Hi Philipp, Karsten, > On 24 Apr 2019, at 10:50, Philipp Winter wrote: > > I'm working on , which will make > BridgeDB export usage statistics. I would like these statistics to be > public, privacy-preserving, and -- ideally -- added to Tor Metrics. I >

[tor-dev] Proposing sbws changes

changes into the spec. T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin

Re: [tor-dev] Next Network Team Meeting Time

m in the Iran and I can not attend the meeting The network team meetings are online in the #tor-meeting channel on the irc.oftc.net IRC network. irc.oftc.net supports IRC over Tor. You'll need an IRC application to participate. We rotate times, so that most people can participate at least on

[tor-dev] Next Network Team Meeting Time

Monday 10 June at 1700 UTC T -- teor -- signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Merger and Mainline Handovers

://trac.torproject.org/projects/tor/wiki/user/teor#Backports:0.5daysperweek Here are the backports I will do after I get back from my leave in May: https://trac.torproject.org/projects/tor/wiki/user/teor/HiddenBackports T -- teor

[tor-dev] Next Network Team Meeting Time

) * Monday 29 April at 1700 UTC Daylight saving changed recently, so at least one of these meetings will be at a different local time for you. Our 1700 UTC meeting tracks north american daylight saving time. Our 2300 UTC meeting does not change for daylight saving time. T -- teor

Re: [tor-dev] Docker images for help people to run Tor (teor)

Hi, > On 1 Apr 2019, at 07:55, Alessandro Fiori wrote: > > Hi, > I would like to share with the community some tests I've made for setting up > a "swarm" of Tor relays. > > I setted up 3 exit relays and 3 middle relays on the same IPv4 address, to > make some testing, and the entire swarm

Re: [tor-dev] Docker images for help people to run Tor

Hi, (Please try to reply to the thread, not the digest!) > On 30 Mar 2019, at 11:51, Alessandro Fiori wrote: > > Because the images are built separately, and Containers doesn't have > persistent data by default, i'm testing the launch of a "relay swarm", which > isn't the "Docker Swarm". >

Re: [tor-dev] Docker images for help people to run Tor

Hi, > On 29 Mar 2019, at 08:57, Alessandro Fiori wrote: > > I've decided to release two scripts (I'm releasing for Ubuntu too), for run > an Exit Relay or Hidden Service then, with Docker image. > > If needed, let me know if there would be useful releasing an image of a > Non-Exit-Relay.

Re: [tor-dev] Tor Friendliness Scanner

Hi, > On 17 Mar 2019, at 08:04, Ryan Duff wrote: > >> The way we intended to do this was to send our FF "ground-truth" >> collection through Tor, and specifically through the same exit node as >> TTB uses. This way we can isolate the variable to the differences in the >> browsers, rather than

Re: [tor-dev] Proposal 301: Don't include package fingerprints in consensus documents

> On 14 Mar 2019, at 03:50, Iain Learmonth wrote: > > Signed PGP part > Hi, > >>> On 25/02/2019 23:30, teor wrote: >>>> Looks good to me, let's merge it as an "accepted" proposal? > > This is now proposal 301. > > What is the process

Re: [tor-dev] Updating Proposal 299 (Preferring IPv4 or IPv6 based on IP Version Failure Count)

> On 13 Mar 2019, at 08:44, Neel Chauhan wrote: > > Hi teor, > >> Thanks, I opened a ticket to review and merge it here: >> https://trac.torproject.org/projects/tor/ticket/29687 >> It should get reviewed within a week or two. > > First off, thank you for doi

Re: [tor-dev] Updating Proposal 299 (Preferring IPv4 or IPv6 based on IP Version Failure Count)

> On 7 Mar 2019, at 09:07, Neel Chauhan wrote: > > Hi teor, > > On 2019-03-05 21:12, teor wrote: >> Sure. We usually do torspec changes using GitHub pull requests. >> Can you open a pull request on https://github.com/torproject/torspec ? >> Then lin

Re: [tor-dev] download consensus from mirrors based on frequency options in torrc

Hi, > On 7 Mar 2019, at 22:00, Pouya Miralaee wrote: > > according to these frequency options below, how should i specify that tor > does not or if it has to, only in necessary times downloads consensus from > directory servers and in all other cases, download them from mirrors or >

  1   2   3   4   5   6   7   >