- tor-dev - lists.torproject.org

How does Tor plan to deal with HTTP/3 (HTTP over QUIC)
by neel＠neelc.org 17 Nov '18

17 Nov '18

Hi @tor-dev mailing list, How would Tor deal with HTTP/3 (a.k.a. HTTP over QUIC), considering that Tor is a TCP anonymizer, and HTTP over QUIC (and QUIC itseld) uses UDP? Would we need Tor to support UDP? Just QUIC? Thanks, Neel Chauhan === https://www.neelc.org/

2 1

Empty menu item in Help menu
by scootergrisen 12 Nov '18

12 Nov '18

I tried testing Tor Browser in macOS (VirtualBox) and at the bottom of the Help menu i see a empty menu item. If i remember correct nothing happened if i clicked it.

2 1

Icon misaligned in macOS drag icon dialog
by scootergrisen 12 Nov '18

12 Nov '18

The icon is misaligned in macOS for the installer or whatever it is called.

2 1

network team weekly meeting - nov 12th
by Gaba 12 Nov '18

12 Nov '18

Hi! This week's network team meeting is on Monday at 1800 UTC. Our meetings are held on #tor-meeting on OFTC. cheers, gaba

1 0

A few wtf-pad/prop254 questions
by Nick Mathewson 07 Nov '18

07 Nov '18

Hi! I'm looking over prop254 and I have a few questions or clarification requests that I hope will make things clearer to me. Some of these are probably "wrong questions" that stem from a misunderstanding of the underlying proposal. 1) What does "ito" stand for? Is it documented? 2) How is RTT measurement meant to work? It seems to me from reading section 3.1 that middle if a middle node sees a delay of N ms between getting a cell in the forward direction, and getting a cell in the backward direction, then it will conclude that the RTT is at least N ms. But that doesn't make sense to me -- the latter cell might have been sent in response to a different cell, or sent asynchonously, and not in response to the first cell at all. AFAICT unless we can be reasonably sure that we are seeing a packet that is sent in response to an earlier cell, be sure that we're actually measuring min(rtt). Maybe some pseudocode would help me understand better. 3) In section 3.1, I'm assuming that "cell sent" and "cell received" refer to a cell that we are originating, and a cell that we are receiving, recognizing, and processing: relayed cells don't count. Is that correct? 4) I like that section 3.1.1 specified delays in terms of microseconds, but we should be aware that with current implementation restrictions, microsecond-level precision is unlikely to actually be realistic. I hope that's okay. 5) In section 3.1.1, can we include a formula for the bounds of the n'th bin? 6) In section 3.1.1, why is a uniform distribution used, and not some other distribution? 7) In section 3.1 (I'm not sure where) can we specify how bins are initialized, and how they are refilled (if at all)? 8) For machine negotiation (in section 3.3), I'd suggest that we have the client send a list of acceptable machines in preference order, rather than demanding a particular machine. I think a 16-bit identifier is safer than an 8-bit one. We should reserve an area of the identifier space for experimental use. 9) Can we include an example definition of one of these state machines, with pseudocode included? 10) Should clients (eventually) begin killing circuits if they receive padding from an unexpected place? cheers, -- Nick

3 2

Proposal 298: Putting family lines in canonical form
by Nick Mathewson 31 Oct '18

31 Oct '18

Filename: 298-canonical-families.txt Title: Putting family lines in canonical form Author: Nick Mathewson Created: 31-Oct-2018 Status: Open Target: 0.3.6.x 1. Introduction With ticket #27359, we begin encoding microdescriptor families in memory in a reference-counted form, so that if 10 relays all list the same family, their family only needs to be stored once. For large families, this has the potential to save a lot of RAM -- but only if the families are the same across those relays. Right now, family lines are often encoded in different ways, and placed into consensuses and microdescriptor lines in whatever format the relay reported. This proposal describes an algorithm that authorities should use while voting to place families into a canonical format. This algorithm is forward-compatible, so that new family line formats can be supported in the future. 2. The canonicalizing algorithm To make a the family listed in a router descriptor canonical: For all entries of the form $hexid=name or $hexid~name, remove the =name or ~name portion. Remove all entries of the form $hexid, where hexid is not 40 hexadecimal characters long. If an entry is a valid nickname, put it into lower case. If an entry is a valid $hexid, put it into upper case. If there are any entries, add a single $hexid entry for the relay in question, so that it is a member of its own family. Sort all entries in lexical order. Remove duplicate entries. Note that if an entry is not of the form "nickname", "$hexid", "$hexid=nickname" or "$hexid~nickname", then it will be unchanged: this is what makes the algorithm forward-compatible. 3. When to apply this algorithm We allocate a new consensus method number. When building a consensus using this method or later, before encoding a family entry into a microdescriptor, the authorities should apply the algorithm above. Relay MAY apply this algorithm to their own families before publishing them. Unlike authorities, relays SHOULD warn about unrecognized family items.

1 0

Updates and review on "Proposal 254: Padding Negotiation"
by George Kadianakis 30 Oct '18

30 Oct '18

Hey Mike, I took another look at prop#254 and made some changes of my own in my torspec branch circuitpadding-proposal-updates (see commit ab37543). Let me know if they look right to you. Some of those I had to look into the code to understand, and I hope I got them right. Furthermore, I opened a pull request with a few questions and comments for further improvements and clarifications: https://github.com/torproject/torspec/pull/39 Cheers!

1 0

Re: [tor-dev] obfs4, meek, active probing and the timeline of pluggable transports
by Piyush Kumar Sharma 29 Oct '18

29 Oct '18

Hello all, I have a few specific questions related to the pluggable transports. 1.) I believe that obfs4 stops active probing(the latest problem as brought to notice by Ensafi et al, IMC 2015 and Shinying Cho, FOCI 2018), and hence discovering obfs4 Tor bridges using active probing is not possible. Is that true? If so, then we are good to go and hence we don't need any other pluggable transport to work for us as long as obfs4 is working? 2.) What was the motivation to bring in meek as a pluggable transport, given the fact that obfs4 works great to cover all the existing problems with Tor detection. Was the motivation just the fact that, it will be much easier for the users to use meek than obfs4 or something other than this? 3.) I searched a lot but could not find the timeline in which pluggable transports were built. As in what was developed and deployed first, obfs4 or meek? Regards Piyush IIITD

7 6

Add EVENT message to pt-spec.txt and control-spec.txt
by David Goulet 29 Oct '18

29 Oct '18

Greetings tor-dev! We've been working on improving PT reporting towards Tor so for instance Tor Browser can better inform the user or take actions based on the PT state when connecting to the network. The following ticket summarize it: https://trac.torproject.org/projects/tor/ticket/28180 To achieve this, we are submitting these to torspec.git patches to extend both the pt-spec.txt and control-spec.txt to support such mechanism. This is the first draft. Below is the link to the PT spec patch. It adds the EVENT message that for now is only used, as you will see, for reporting connection status message. However, you should see this EVENT message as extendable to whatever the PT would like to report to Tor that we can think of in the future: https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=ticket2818… The second, is simpler, it is how Tor will send it back to the control port: https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=ticket2818… Please, any questions or feedbacks is very welcome! The main idea here is to keep things simple and extendable. Note that since Tor doesn't implement the PT 2.0 spec yet, we haven't done anything for that spec but after skimming the version 2, I think we can easily move this EVENT message concept if we want it. Cheers! David -- t2Mtu4qBote14xSTFee/xnHlXp1eabwHFbehBlktnus=

2 2

(no subject)
by sarpedon montecarlo 26 Oct '18

26 Oct '18

Hi! I am supposed to implement, a python application that runs tor in background. The running tor is under direct control of the python app via control port. This running tor, is the proxy for the Tor Browser; By this I mean, when the Tor Browser starts, it will connect to this process, instead of the bundled tor provided by itself. The controlling features I am into, are as below: A) I want to attach streams coming from each tabs of the Tor Browser, attached to a separate circuit; By this I mean each tab of the browser, use a separate circuit, and do not share circuits with each other.(just like the way ordinary TBB does that) for this I am aware that Tor Button plugin does something with the streams to separate streams of a specific tab from other streams. Then by using IsolateSocksStream option on the tor side, tor will successfully isolate each tabs streams. My problem here, is that I am handling the routing and stream attaching all by myself and I can not use the provided IsolateSocksStream option because I am handling the circuit generation by myself because of the specific policies I am using for generating circuits, and their related paths. So if I am facing a bunch of streams, and I have a bunch of circuits myself, How am I going to detect that Stream A is from tab A of TBB and Stream B is from tab B of TBB, so I attach stream A to circuit A, and attach stream B to circuit B. Thanks in advance.

2 1