- tor-dev - lists.torproject.org

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

UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header
by George Kadianakis 26 Oct '18

26 Oct '18

UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header ======================================================================== 1. Motivation: Lots of high-profile websites have onion addresses these days (e.g. Tor , NYT, blockchain, ProPublica). All those websites seem confused on what's the right way to inform their users about their onion addresses. Here are some confusion examples: a) torproject.org does not even advertise their onion address to Tor users (!!!) b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion address and completely wrecking the UX (loses URL params, etc.) c) ProPublica has a "Browse via Tor" section which redirects to the onion site. Ideally there would be a consistent way for websites to inform their users about their onion counterpart. This would provide the following positives: + Tor users would use onions more often. That's important for user education and user perception, and also to partially dispell the darkweb myth. + Website operators wouldn't have to come up with ad-hoc ways to advertise their onion services, which sometimes results in complete breakage of the user experience (particularly with blockchain) This proposal specifies a simple way forward here that's far from perfect, but can still provide benefits and also improve user-education around onions so that in the future we could employ more advanced techniques. Also see Tor ticket #21952 for more discussion on this: https://trac.torproject.org/projects/tor/ticket/21952 2. Proposal Websites use the Alt-Svc HTTP header to specify their onion counterpart: http://httpwg.org/http-extensions/alt-svc.html The Tor Browser intercepts that header (if any) and auto-redirects the user to the onion site. Tor Browser only does so if the header is served over HTTPS. (That's it.) 3. Improvements 3.1. User education through notifications To minimize the probability of users freaking out about auto-redirects Tor Browser could inform the user that the auto-redirect is happening. This could happen with a small notification bar [*] below the URL bar informing users that "Tor Browser is auto-redirecting you to the secure onion site". The notification bar could also have a question mark button that provides the user with additional information on the merits of onion sites and why they should like them. [*]: like this one: http://www.topdreamweaverextensions.com/UserFiles/Image/firefox-bar.jpg 3.2. Auto-redirects too intrusive? Make them optional. If we think that auto redirects are too intrusive, we should consider making them optional, or letting the website specify the desired behavior. If a website wants to specify an onion address but doesn't like auto-redirects, it could specify that as part of Alt-Svc and we could still inform the user that an onion is available using a notification bar again. 4. Drawbacks This proposal is far from the perfect solution of course. Here are a few reasons why: 4.1. Auto-redirects are scary Novice users or paranoid users might freak out with auto-redirects since it's unexpected. They might think they are under attack or they got hacked. An argument against that is that we are already using HTTPS-everywhere which is basically a redirection layer, and while its redirection technique is simpler, sometimes the derivative URL is not similar to the original URL, and we still don't see people freaking out. I think that's because people trust Tor Browser to do the right thing. Combining this knowledge with section 3.1 might solve this problem. 4.2. No security/performance benefits While we could come up with auto-redirect proposals that provide security and performance benefits, this proposal does not actually provide any of those. As a matter of fact, the security remains the same as connecting to normal websites (since we trust its HTTP headers), and the performance gets worse since we first need to connect to the website, get its headers, and then also connect to the onion. Still _all_ the website approaches mentioned in the "Motivation" section suffer from the above drawbacks, and sysadmins still come up with ad-hoc ways to inform users abou their onions. So this simple proposal will still help those websites and also pave the way forward for future auto-redirect techniques. 4.3. Alt-Svc does not do exactly what we want I read in a blog post [*] that using Alt-Svc header "doesn’t change the URL in the location bar, document.location or any other indication of where the resource is; this is a “layer below” the URL.". IIUC, this is not exactly what we want because users will not notice the onion address, they will not get the user education part of the proposal and their connection will still be slowed down. I think we could perhaps change this in Tor Browser so that it rewrites the onion address to make it clear to people that they are now surfing the onionspace. [*]: https://www.mnot.net/blog/2016/03/09/alt-svc 5. The future As I said this is just a simple proposal to introduce the auto-redirect concept to people, and also to help some sysadmins who are currently coming up with weird ways to inform people about their onions. It's not the best way to do this, but it's definitely one of the simplest ways. In the future we could implement with more advanced auto-redirect proposals like: a) Have a "domains to onions" map into HTTPS-everywhere and have it do the autoredirects for us (performance benefits, and security benefits under many threat models). b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested by comment:42 in #21952. But both of the designs above require non-trivial engineering/policy work and would still confuse people. So I think starting with a simple approach that will educate users and then moving to more advanced designs is a more normative way to go. ====================================================================== Let me know what you think :) (Should this be part of torspec?)

10 25