Tor Bug Tracker & Wiki: Ticket Query!closed&keywords=~needs-proposal&order=id The Tor Project: anonymity online en-US Tor Bug Tracker & Wiki /images/tor-logo.png!closed&keywords=~needs-proposal&order=id Trac 1.2 #1250: strange SOCKS error code when connecting to a hidden service using the wrong port Mon, 15 Feb 2010 13:24:27 GMT ultramage <p> I set up two distinct hidden services, HTTP(80) and SSH(22) on my machine (since I didn't know you could put multiple records under a single service). </p> <p> Today I made the mistake of connecting to the HTTP service using port 22 (took the HTTP service's url, stripped the http part, entered into PuTTY). The returned error code was 0x02 = connection not allowed by ruleset. This message made me very confused, since it somehow implies that my SOCKS settings were somehow blocking the connection. But that was not the case. </p> <p> What happened on the TOR back-end was, my request got received, the remote TOR server found that my port was not on the list of ports associated with that particular onion hostname, and rejected the connection attempt. Finally, my TOR client, trying to be as clever as informative as possible, returned that specific error code. </p> <p> While the error code does in some sense describe what happened internally, I do not think that 0x02 is appropriate for this scenario. I did not study the SOCKS specification, however I'm assuming that "ruleset" refers to the access control rules implemented on the daemon that's providing the tunnel, and not on the remote endpoint (the target machine is oblivious to SOCKS and just sees an incoming TCP connection, so it can't react in any way). </p> <p> My proposal is to change this error code to reduce confusion and help users identify the cause of the problem (between keyboard and chair in my case :). Which one to use? I suggest 0x05 = connection refused by destination host. "Connection refused" is what you normally get if the destination machine has nothing running on the requested port (and there's no firewall to hide that). </p> <p> Visualize a single hidden service as a physical machine running somewhere on the internet, with stuff listening only on ports associated with that HS. In that case, connecting to a wrong port would give TCP "connection refused". And TOR hidden service isolation seems to be making virtual servers like this. So why shouldn't it be returning this error code instead? </p> <p> PS: Also think of SOCKS client software that might get confused by this error code. PS2: You could test the effectiveness of this change by taking a group of people, giving them a setup like mine, asking them to troubleshoot the issue and timing them. Whichever group can figure out what the problem is faster has the better error code. </p> <p> [Automatically added by flyspray2trac: Operating System: All] </p> Results #2395: Break Wed and Wee weights into two classes each Sat, 15 Jan 2011 22:35:54 GMT mikeperry <p> In 0.2.2, we added consensus bandwidth-weights to specify how to distribute node selection choices for the three positions in a circuit among the different node flags (Guard, Exit, Guard+Exit and None). See 3.4.3 of <a class="ext-link" href=""><span class="icon">​</span></a> and <a class="ext-link" href=""><span class="icon">​</span></a>. See also the original post: <a class="ext-link" href=""><span class="icon">​</span></a> </p> <p> I added some code to to display the breakdown of bytes by port, using Karsten's extra-info exit ports stats: Default exit blutmagie read 503.9M </p> <blockquote> <p> other: 56.6% 80: 38.9% 51413: 1.4% 443: 0.7% 4000: 0.6% 49354: 0.5% </p> </blockquote> <p> Default exit blutmagie wrote 182.6M </p> <blockquote> <p> other: 92.1% 80: 4.0% 51413: 1.6% 24273: 1.2% 53163: 0.4% 443: 0.3% </p> </blockquote> <p> Misc Exit Amunet3 read 206.1M </p> <blockquote> <p> 80: 97.1% 443: 1.6% 8080: 0.6% 81: 0.3% 563: 0.2% other: 0.1% </p> </blockquote> <p> Misc Exit Amunet3 wrote 7.5M </p> <blockquote> <p> 80: 88.0% 443: 9.0% 8080: 1.3% other: 1.3% 8888: 0.2% 81: 0.1% </p> </blockquote> <p> Amunet has the non-default exit policy listed in <a class="closed ticket" href="" title="#6: defect: Confused server clocks can screw up timing (closed: wontfix)">#6</a> at: <a class="ext-link" href=""><span class="icon">​</span></a> </p> <p> Blutmagie has the default. </p> <p> So what this tells us is that we may want to devote circuits predicted to be used for port 80 or 443 more on the non-default exit policy than for the default exit policy to compensate for the fact that these non-default exits with normally otherwise get less traffic than their default exit policy peers. </p> Results #2473: Develop a design to support multiple bridge authorities Tue, 01 Feb 2011 10:31:33 GMT arma <p> The main thing blocking multiple bridge directory authorities right now is that we don't have a design for how it would work. For the normal directory authority design, we want all of them to know about all relays. But for bridge authorities, that would defeat the purpose. So we want some algorithms for distributing bridges over authorities, such that bridge users know where to go to look up a given bridge (probably as a function of its identity fingerprint). Perhaps the algorithm should provide stable answers even as we change the set of bridge authorities, and for clients and bridges running a variety of Tor versions. More generally, we need to figure out what functionality we want and what security properties we should shoot for. </p> <p> Somebody should start with a proposal, and go from there. </p> Results #2667: Exits should block reentry into the tor network Mon, 07 Mar 2011 01:18:03 GMT mikeperry <p> With proposal 110, we blocked the ability of Tor clients to use the Tor protocol for an unbounded amplification attack to destroy the Tor network. However, we still have not completely prevented this attack. It is still possible to tunnel tor over tor by using exits to connect back to other tor nodes. This property can still be used to execute the unbounded amplification attack on the Tor network, or just on the tor directory authorities. </p> <p> One fix for this would be to add code to exit nodes to implicitly add all of the IP + ORport combinations of all other relays to their exit policy reject lines, or otherwise block this connection at some other level. </p> Results #2693: Design and implement improved algorithm for choosing consensus method Wed, 09 Mar 2011 20:27:27 GMT nickm <p> Our current algorithm for picking a consenus method is, "Pick the highest method supported by more than 2/3 of the authorities currently voting." This can sometimes result in an insufficiently signed consensus. Instead, it should be something like, "Pick the highest method supported by more than 2/3 of the authorities currently voting, UNLESS the number of authorities supporting that method is less than the threshold needed to sign a valid consensus. In that case, pick the highest method supported by enough authorities to sign a valid consensus." </p> <p> Alternatively, the algorithm could be something like, "Pick the highest method supported by enough authorities to sign a valid consensus", which I believe is mathematically identical to the above (more obviously safe) formulation. </p> <p> This change would make some attacks harder for a hostile authority, and some attacks easier. It needs a design proposal and some analysis. </p> Results #2998: If your bridge is near your exit, Tor might surprise you by failing your circuit Tue, 26 Apr 2011 18:51:39 GMT arma <p> In fixing <a class="closed ticket" href="" title="#1090: defect: Warning about using an excluded node for exit (closed: fixed)">#1090</a>, we removed the logic that said "if your exit relay and your bridge are on the same /16, and you were about to fail the circuit, ignore the distinctsubnets constraint". This could result in surprising failures for bridge users. </p> <p> The origin of the problem is that <a class="closed ticket" href="" title="#1090: defect: Warning about using an excluded node for exit (closed: fixed)">#1090</a> decides to follow the user's instructions even when we think they were bad instructions, because the user asked for the behavior explicitly. And I agree with that plan in the case of setting EntryNodes. But a user who sets Bridges might be doing it because he only knows about those bridges, not because he thinks he knows something about path selection strategy that the Tor developers don't know. </p> <p> So do we keep the user safe by failing any circuits whose exit relays are near her bridges? ("you asked for that behavior, so you get it, sucks to be you") Or do we focus on reachability and back off on our path selection constraints? </p> <p> One option might be to use the "do I want security or do I want reachability" config option we've been heading toward with <a class="closed ticket" href="" title="#2510: defect: bridge users who configure the non-canonical address of a bridge ... (closed: fixed)">#2510</a> and <a class="closed ticket" href="" title="#2511: defect: Tor will use an unconfigured bridge if it was a configured bridge last ... (closed: fixed)">#2511</a>: if we let the bridge cache and try to use bridges that aren't currently configured, we could also make current bridges work rather than fail in this situation. </p> <p> The Tor client will pick a new exit and try another circuit, so the main effect of the bug is added latency for circuit creation. But there's a slight possibility that we will give up on circuits for an entire minute (after 5 failures). How often does this edge case occur in practice? What if it starts occurring later? </p> <p> I worry because none of the developers use bridges so few people fix bridge robustness issues. </p> Results #3028: META: Support non-clique topologies on the network Thu, 28 Apr 2011 15:03:00 GMT tagnaq <p> <a class="ext-link" href=""><span class="icon">​</span></a> </p> <p> See it like a long term feature request :) (if there is not one yet) </p> Results #3459: Expose information about dir conns to controllers Fri, 24 Jun 2011 23:47:54 GMT rransom <p> Currently, we do not expose any information about non-tunneled directory connections to controllers. Should we? </p> Results #3520: CIRC FAILED REASON=DESTROYED events do not specify which hop sent the RELAY_TRUNCATED cell Fri, 01 Jul 2011 20:57:13 GMT rransom Results #3652: Export clock skew opinion as getinfo command Tue, 26 Jul 2011 20:17:44 GMT mikeperry <p> Torbutton could make use of a getinfo command to reduce the fingerprinting issues that a user has wrt their Date() object (see <a class="new ticket" href="" title="#2940: enhancement: Adapt browser time based on tor's notion of clock skew... (new)">#2940</a>). </p> <p> However, the threading support in Firefox is not good enough for us to easily make a full tor controller that listens for events. It would be much easier if the current skew (ideally down to milliseconds if possible) was available as a getinfo command, so that Torbutton could just query it and update the browser's time offset. </p> <p> I am making this a 'major' enhancement because clock skew is an important issue to address to reduce fingerprinting. </p> Results #4391: `GETINFO ns/all` doesn't return 'p' lines -- make something that does! Sat, 05 Nov 2011 02:04:50 GMT katmagic <p> The ns/all GETINFO controller command doesn't send any p lines. The spec doesn't actually require them, but they'd be helpful to have. </p> Results #4631: Idea to make consensus voting more resistant Thu, 01 Dec 2011 18:43:21 GMT Sebastian <p> This is an idea how to improve the current situation, where sometimes a directory authority is slow to get its vote out to the other dirauths, and so the dirauths don't all have the same sets of votes. To simplify, I'm illustrating with an example of three dirauths: </p> <p> at :50, all dirauths make their vote and start uploading. auth1 and auth2 get their vote to all auths, but auth3 doesn't. it cannot publish a vote to auth1 at all, and it takes more than 2.5 minutes to publish its vote to auth2. at :52:30, all auths try fetching the votes they're missing from the other auths, so auth1 asks auth2 for auth3's vote, and auth2 asks auth1 for auth3's vote. auth3 asks nobody, and nobody asks auth3. At this point, neither auth1 nor auth2 have auth3's vote. auth3 now (at, for example, :53:30) succeeds publishing to auth2, so auth1 now has a vote from auth1 and auth2, auth2 and auth3 have a vote from auth1, auth2, and auth3. At :55 the auths try to make a consensus, but auth1 will end up with a different consensus than auth2 and auth3. </p> <p> My idea to make this less of a problem would be that only for two minutes will we accept a vote that gets pushed to us, and anything we get later than that is considered "too late" and will be dropped. At :52:30 minutes, we still go ahead and try and fetch all votes from all the other authorities, and if they have a vote we will accept it. We repeat that fetching of all votes that we don't have at 53:00, 53:30, 54:00 and 54:30. That way, a delayed publication of the original vote will not cause this kind of split, where the dirauths have different opinions on who has voted, so only the dirauth that took more than 2 minutes to publish its descriptor to any of the other dirauths will be affected. There's still a race condition here, which is when a dirauth (within two minutes) only publishes to one other dirauth, and then that dirauth gets so slow it cannot get the vote to any of the other votes. But since it was fast enough to get the vote the first time, hopefully that's rather rare. </p> <p> Does this all sound viable? Am I overlooking something? </p> Results #4826: Write proposal for improved consensus voting schedules Thu, 05 Jan 2012 10:49:33 GMT arma <p> Sebastian suggests that we revise the schedule for consensus voting such that there's a cutoff after which we discard votes from the original authority. So phase 1a is to publish your vote to every authority, phase 1b is to ask every authority for votes you're missing, and during phase 1b we won't accept phase 1a votes. </p> <p> The goal here is to avoid consensus failures that occur when an authority uploads a vote during phase 1b, and some authorities end up thinking everybody knows it, yet some don't know it. </p> Results #5392: Write proposal for n23 patch behavior Wed, 14 Mar 2012 23:00:12 GMT arma <p> In <a class="closed ticket" href="" title="#4488: project: Track down the N23 patch, then update it for modern Tor (closed: implemented)">#4488</a> we located and updated the n23 patch from the Defenestrator paper. It's now in branch 'n23-2' in my git repo. </p> <p> The next step is to refactor connection_or_consider_sending_flowcontrol_cell(). To do that, we need to know what the function is *supposed* to be doing. </p> <p> Under what circumstances do we send a flowcontrol cell, and how do we pick the values for it? Just as important, in what cases (e.g. if we're a client) do we *not* send flowcontrol cells? </p> <p> I'm hoping Mashael will do this, with Ian's help. </p> Results #5456: Defend against path bias and tagging attacks Fri, 23 Mar 2012 19:58:15 GMT mikeperry <p> In <a class="ext-link" href=""><span class="icon">​</span></a>, some dude who claims to be a raccoon proved that tagging attacks are an amplification attack that allow an adversary who has c/n of the network bandwidth to compromise of c/n of all circuits through the network. </p> <p> The tagging attack he describes is actually a subset of path bias attacks we've known about for a long time. Tagging is just a particularly nasty one that also allows for a level of amplification that we previously were not aware of. </p> <p> This ticket is to serve as the parent ticket for several things we can do to improve the situation and defend against tagging in specific or path bias in general. </p> Results #5641: Exit Enclave equivalent for encrypted Tor-to-Tor connections Wed, 18 Apr 2012 18:24:24 GMT hellais <p> While current stable version of Tor (0.2.2.x) still supports Exit enclaves. The new versions of Tor (&gt; 0.2.3.x) use a new descriptor format (microdescriptors) that allow relays to specify an Exit Enclave policy, but clients will not use it, therefore voiding the purpose of exit enclaving. </p> <p> The ability to allow a Tor users to reach a certain destination without ever leaving the Tor network is a feature that a few people are interested in. </p> <p> I think these properties could be what we are looking for in Encrypted Services (<a class="closed ticket" href="" title="#2555: task: Finish 'encrypted services' proposal (closed: fixed)">#2555</a>), though what needs to be figured out is a way for a client to understand that a certain destination is running a Tor ES. </p> Results #5903: Restore ExcludeEntryNodes feature Wed, 16 May 2012 15:01:16 GMT cypherpunks <p> Seems that ExcludeEntryNodes configuration option was removed at some point (atleast's "verify-config" rejects it). </p> <p> It however would be nice to have it to avoid the "adversary can monitor entry and exit nodes" scenario which is very real in countries with few relays (which can be legally compelled to do such a thing) while still using the country's exitnodes (I don't have a problem with my traffic making a trip around the world and exiting to public Internet from the relay that my neighbour runs, I do however have a problem with my traffic entering the Tor network from the high-bandwidth relay with a Guard flag that my *other* neighbour, who happens to be an associate of the first neighbour, is running). </p> Results #5915: Write patch to make socks handshakes succeed instantly Fri, 18 May 2012 00:40:39 GMT arma <p> In <a class="closed ticket" href="" title="#3875: project: TBB's Firefox should use optimistic data socks handshake variant (closed: fixed)">#3875</a> Mike suggests we try out the usability of having the Tor in TBB just immediately succeed at all socks handshakes, and hang up if it gets an end cell rather than a connected cell. </p> <p> We should whip up a Tor patch that does this behavior, so somebody can try it out. </p> <p> (We may or may not want to merge it into mainline Tor branches. I guess it depends how complex the patch is and how successful the tests are.) </p> Results #6256: Make circuit isolation isolate exits? (signal NEWNYM exit bucketing) Fri, 29 Jun 2012 10:20:28 GMT grarpamp <p> Would like to see an option for bucketing exits on NEWNYM such that dynamic maps thrown out by NEWNYM will have their exits bucketed and quarantined from further use until all other exit's have been bucketed by NEWNYM. At which point further NEWNYM's or circuit requests round robin exits out of the bucket for such use. </p> <p> Reason: Exits seem to be reused sometime after NEWNYM, guaranteed robin on NEWNYM makes some cases of testing tor and destinations easier. </p> <p> Integration: rendevous, other limitations on exits (country), static maps, etc. </p> Results #6495: Define ReducedExitPolicy/ExitPolicyGroups in tor/dirauths Tue, 31 Jul 2012 02:34:07 GMT mikeperry <p> We've got a lot of different relays running a lot of slightly different versions of <a href=""></a>. We should maintain one version either in the directory authority consensus, or directly in the tor source itself. </p> <p> We may also want to split the thing into service groups, like the Vidalia UI does. It should be a part of tor though, not Vidalia, since most high capacity exits don't run with Vidalia. </p> Results #6790: Write proposal draft for directory mirrors to accept, aggregate and hand off descriptors to dirauths Fri, 07 Sep 2012 19:05:35 GMT mikeperry <p> In the event of DoS or braindead client behavior, directory authorities may need to rate limit or restrict connections. See <a class="new ticket" href="" title="#2665: task: Create a dirauth DoS response procedure (new)">#2665</a>. </p> <p> Under these conditions, it would be useful if directory mirrors could also accept relay descriptor data, aggregate it, and hand it off to the authorities after eliminating duplicates. This coupled with <a class="closed ticket" href="" title="#572: enhancement: fallback-consensus file impractical to use (closed: implemented)">#572</a> should allow the dirauths to better handle sudden traffic spikes by rate limiting or firewalling, without degrading the network. </p> <p> <a class="ext-link" href=""><span class="icon">​</span></a> has a related idea, but we may want a push method rather than a pull? </p> Results #7148: Even better parameter voting protocol Fri, 19 Oct 2012 05:33:56 GMT nickm <p> Our current parameter voting protocol is backwards in how many voters need to exist for a parameter before we can vote for it. Right now we accept the parameter into the consensus if it has a majority of all authorities, or at least 3 authorities. But that fails when most authorities are abstaining: 3 rogue authorities could force the value of an unset parameter to whatever they want. </p> <p> A stopgap solution (for which roger is writing a ticket) is for all authorities to vote on all parameters, and to have most/all authorities begin voting on any new parameter before we release software that looks for it. </p> <p> But surely we can do better than that. </p> <p> We need to write a little proposal for this before the little-proposal deadline to implement it in 0.2.4. </p> Results #7829: Support all kinds of DNS over Tor Sun, 30 Dec 2012 21:16:15 GMT proper <p> Please allow to request any kind of DNS over Tor through exit nodes. </p> <p> DNSSEC, clear thing. </p> <p> MX records example use case: Mixmaster over Tor. </p> Results #8453: Alter flag-weight balancing equations Tue, 12 Mar 2013 02:46:30 GMT mikeperry <p> I have a few things I want to do to the flag-weight equations. This ticket will eventually be the parent ticket, but for now it's just a brain-dump: </p> <ol><li>I definitely want to correct the balancing issues discussed in <a class="closed ticket" href="" title="#8240: defect: Raise our guard rotation period, if appropriate (closed: fixed)">#8240</a>. </li><li>I might want to account for changes due to directory guards (<a class="assigned ticket" href="" title="#7757: enhancement: Maybe revisit node flag weight calculations (assigned)">#7757</a>). </li><li>I might want to factor in an optional Guard/Middle padding parameter. (<a class="closed ticket" href="" title="#7028: project: Implement Adaptive Padding or some variant and measure overhead vs accuracy (closed: implemented)">#7028</a>) </li><li>I might want to factor in an estimate of hidden service traffic somehow. </li></ol> Results #9001: Slow Guard Discovery of Hidden Services and Clients Fri, 31 May 2013 01:34:01 GMT mikeperry <p> In <a class="ext-link" href=""><span class="icon">​</span></a>, one of the attacks described is a method for locating the Guard nodes of a hidden service within about an hour. </p> <p> It also seems possible to locate the Guard nodes of persistent, automated clients in a similar timeframe by similarly repeatedly destroying HSdir lookup circuits for your target hidden service. </p> <p> These attacks are possible to execute on such rapid timescales because *each* endpoint in hidden service communications can destroy the current circuit, and force the other party to create a new one using a new middle node. </p> <p> There are at least three ways to slow this attack: </p> <ol><li>Multiple layers of guard nodes. </li><li>Create a "Virtual Circuit" abstraction layer that picks your hops for a given purpose, and tries to re-use those hops even after certain failure conditions. </li><li>Change the Tor Protocol to prevent DESTROY cells and other mechanisms of circuit destruction from destroying the counter-party's endpoint, and create mechanisms for multiple clients to share a single HS rend circuit (such as I2Ps 'garlic routing' concept). </li></ol><p> Nick and I are tentatively leaning towards the "Virtual Circuit" approach. Such a layer would cleanly decouple path selection from circuit use, and allow us to do things like keep the same three hops for rend and intro circuits for N days, regardless of transient circuit failures or DESTROY cells. </p> <p> This would considerably slow the attack, and also make all sorts of anonymity metrics and analysis easier to do. For example: We can choose N intelligently such that we would expect the runtime of the attack to be a function of our guard lifetime from <a class="closed ticket" href="" title="#8240: defect: Raise our guard rotation period, if appropriate (closed: fixed)">#8240</a>, or we could define lifetime based on expected circuit use and application-provided linkability hints (such as <a class="closed ticket" href="" title="#5752: project: Isolate browser streams by url bar domain rather than by time interval (closed: fixed)">#5752</a>). </p> <p> We can also use the layer to improve the path bias accounting to only count failure if you are forced to choose a new path, rather than simply make a new circuit. </p> Results #9165: Evaluate datagram-based transports; build and merge as appropriate Fri, 28 Jun 2013 16:16:39 GMT nickm <p> This is an omnibus ticket to serve as parent for work involving transports other than TLS-over-TCP for client-&gt;relay and relay-&gt;relay communication. This isn't about pluggable transports for anticensorship purposes; it's about using non-TCP mechanisms for better performance. </p> Results #9208: Allow node operator to avoid Guard flag Fri, 05 Jul 2013 12:37:33 GMT cypherpunks <p> For various reasons node operator may wish to not become guard node. Add cfg option for publishing such wish to directory server. </p> Results #9498: Allow bridge descriptors to contain no address if they are not being published Fri, 16 Aug 2013 17:03:20 GMT nwf <p> To strengthen an "isolating proxy"-style approach to client security, I'd like to allow a Tor bridge node to not reveal its external address(es) in its bridge descriptor. The following patch leaves the address as when it's not going to be published: </p> <pre class="wiki">diff --git a/src/or/router.c b/src/or/router.c index 1063eda..30749b9 100644 --- a/src/or/router.c +++ b/src/or/router.c @@ -1772,7 +1772,7 @@ router_rebuild_descriptor(int force) { routerinfo_t *ri; extrainfo_t *ei; - uint32_t addr; + uint32_t addr = 0; char platform[256]; int hibernating = we_are_hibernating(); const or_options_t *options = get_options(); @@ -1780,11 +1780,16 @@ router_rebuild_descriptor(int force) if (desc_clean_since &amp;&amp; !force) return 0; - if (router_pick_published_address(options, &amp;addr) &lt; 0 || - router_get_advertised_or_port(options) == 0) { + /* If we're not trying to publish our descriptor, it's OK to use + * as the address therein. + */ + if ((options-&gt;PublishServerDescriptor_ != NO_DIRINFO) &amp;&amp; + (router_pick_published_address(options, &amp;addr) &lt; 0 || + router_get_advertised_or_port(options) == 0)) { /* Stop trying to rebuild our descriptor every second. We'll * learn that it's time to try again when ip_address_changed() * marks it dirty. */ </pre> Results #9689: Write proposal for RELAY_AUTHENTICATE/multipath AUTHENTICATE delivery Sat, 07 Sep 2013 06:32:37 GMT mikeperry <p> To protect against relay key theft, it would be useful if relays supported a way to replay the ntor handshake and the DH/ECDH TLS handshake via a directory mirror whose keys are stored in the Tor source code (via <a class="closed ticket" href="" title="#572: enhancement: fallback-consensus file impractical to use (closed: implemented)">#572</a>). </p> <p> The idea is that clients could replay some percentage of their circuits' and TLS connections handshakes via independently authenticated cryptographic paths using the directory mirror keys and <a class="new ticket" href="" title="#5968: enhancement: Improve onion key and TLS management (new)">#5968</a>. If any one handshake replay failed to yield the same session keys from a replayed DH/ECDH/ntor handshake for any subset of the paths, we know the authentication key for that handshake was stolen and one of the client's paths was MITMed, and we could sound the alarm bells. </p> <p> We'd probably need two cell types for this: a VERIFY cell that included enough information to replay one or both handshakes, and a RELAY_VERIFY cell that instructed a relay to send an enclosed VERIFY cell on behalf of a remote client. </p> <p> It would be extra neat if we could use this mechanism as the basis for a proper TLS extension, to allow the whole web to do stuff like this. </p> Results #9954: Replace broadcast voting protocol with something more robust Thu, 10 Oct 2013 16:11:52 GMT nickm <p> While discussing <a class="closed ticket" href="" title="#8244: enhancement: The HSDirs for a hidden service should not be predictable indefinitely ... (closed: fixed)">#8244</a>, Aniket Kate had some comments about our voting protocol: </p> <blockquote class="citation"> <p> The only modification I would like to suggest is to replace your broadcast protocol in the voting round. It is not secure against what is called "dangerous chain of failures" in distributed computing research ; i.e., if one authority crash in per sub-phase (1A, 1B, ...), then at least one working (or correct) authority might have more votes than others. </p> <p> To explain it, I am attaching Lorenzo Alvisi's (UT-Austin) notes along with email. I thought those will be easy to understand than a research paper. In these notes, </p> <ul><li>Dangerous chain is explained on page 7 </li><li>Two protocols that overcome this (possibly extremely unlikely situation) problem are available on page 12 </li><li>I would encourage you to incorporate the early stopping protocol as, in absence of any failure, it completes in the exactly same manner as your current protocol. I think it will not add too much to your current broadcast code, but at the same time take care of gradual failures of directory authorities. </li><li>The protocol description does not mention signatures as they are defined for non-malicious setting. Nevertheless, it will be easy for me to include signatures to the description at appropriate places if you choose to use it. </li></ul></blockquote> <p> I replied with: </p> <blockquote class="citation"> <p> I'll check this out, but I'm not sure whether the change is worth it in this case. If I understand correctly, the failure mode here is no consensus is generated if crashes happen at exactly the wrong times, or sends votes to others at exactly the wrong times. But our protocol can tolerate up to 24/48 hours worth of non-generated consensuses. (Our usual approach when this happens has been "Just debug it".) </p> <p> I'll check out the complexity of the stepping protocol, though. </p> </blockquote> <p> Still, more minds should think on this. </p> <p> I'm investigating whether I have permission to post Lorenzo Alvisi's slies, or whether they're already online. </p> Results #11101: Bridges should report implementation versions of their pluggable transports Sat, 01 Mar 2014 10:06:16 GMT arma <p> Our bridges now run a variety of pluggable transports. What if there's a bug in, say, the Scramblesuit implementation (like it appears there is)? If we fix the bug, how do bridgedb or the Tor clients know whether the Scramblesuit bridge they just learned about is one of the new (updated) ones or one of the old (buggy) ones? </p> <p> One option would be for Tor to include a version for each supported PT in its bridge (or extrainfo) descriptor, so if we turn out to not want to use certain versions for certain situations, we can do it. </p> <p> Are there better options than this one? </p> Results #11119: Write a proposal for client-side key pinning Mon, 03 Mar 2014 15:02:50 GMT nickm <p> Proposal 220 suggests that we pin RSA and Ed25519 identity keys to one another authority-side. Roger suggested to me that we also consider doing client-side identity pinning. </p> Results #11121: Revocation process for authority keys Mon, 03 Mar 2014 15:04:18 GMT nickm <p> Right now, we don't have a proposal that explains how to do revocation on an authority's signing keys. We should write one, and eventually implement it. </p> Results #11158: Write a proposal for a "couldn't reach consensus" statement Fri, 07 Mar 2014 19:07:56 GMT nickm <p> When authorities can't reach a consensus, it would be good if every authority who couldn't reach consensus would sign an "I couldn't reach consensus" statement, so that it's easier to distinguish between "there's a consensus that I cant' find" and "There is possibly/maybe no consensus this period." </p> <p> This may be good for other stuff too; I don't remember all the details from the dev mtg discussion. </p> <p> Somebody should write a proposal for this. </p> Results #11207: Sybil selection should be trickier to game Sat, 15 Mar 2014 01:56:24 GMT nickm <p> In response to some of the hidden service attack papers from 2013, we made it harder to use sybil-based tricks to move around the HSDir hash ring. But really, we should come up with a better way to shut down sybil-based tricks in general, in case there are more that we don't know about. </p> <p> One place to start would be with the question: how often does the sybil code actually get invoked for legit nodes not run by security researchers? If the answer is "infrequently" , then perhaps we could move to an even simpler, blunter approach of "Call all nodes on an IP down for as long as there are too many verified-connectable nodes on that IP." </p> <p> Or we might take another approach to selecting which nodes to list. <a class="closed ticket" href="" title="#8710: defect: Sybil selection should prefer measured over advertised bw (closed: wontfix)">#8710</a> isn't right, but perhaps something else might be. </p> Results #11327: Dir auths should choose Fast and Guard flags by consensus weight if they don't measure Wed, 26 Mar 2014 20:48:43 GMT arma <p> In <a class="closed ticket" href="" title="#8435: enhancement: Ignore advertised bandwidths for flags once we have enough measured ... (closed: fixed)">#8435</a> we made directory-authorities-that-run-bwauths stop voting Fast or Guard for relays they hadn't measured yet. </p> <p> But as I pointed out in <a href=""></a>, since only a minority of dir auths run bwauths, the majority of dir auths are still voting Fast and Guard based on descriptor bandwidths. </p> <p> So while the title of ticket <a class="closed ticket" href="" title="#8435: enhancement: Ignore advertised bandwidths for flags once we have enough measured ... (closed: fixed)">#8435</a> says "Ignore advertised bandwidths for flags once we have enough measured bandwidths", the ChangeLog entry is more accurate: </p> <pre class="wiki"> - Directory authorities that have more than a threshold number of relays with measured bandwidths now treat relays with unmeasured bandwidths as having bandwidth 0. Resolves ticket 8435. </pre><p> We should at some point actually do the original goal, which is to give Fast to the 7/8s of relays whose consensus weights are highest, and Guard to the 1/2 of relays whose consensus weights are highest and who match the other guard constraints. </p> Results #11328: Dir auths should compute Guard WFU using the consensus, not private history Wed, 26 Mar 2014 21:14:51 GMT arma <p> Currently directory authorities track the presence of each relay and keep notes about their view locally. Then when it comes time to vote about Guard, they look at their notes and decide what fraction of the past interval the relay was up for. </p> <p> But it doesn't matter anymore to clients whether the directory authority could reach the relay for that time. The question as of the v3 directory design is whether the relay was in the consensus. </p> <p> So it seems like the directory authorities should be basing their measurements off "is it in the consensus this hour". </p> Results #11458: A newer signing cert should innoculate us against older ones? Wed, 09 Apr 2014 09:10:22 GMT arma <p> Sometime in the past year or two somebody might have stolen 7 of the 9 active directory signing keys. They don't expire for several months or more. </p> <p> If the existing directory authorities rotate to new signing keys, that doesn't really change the fact that older ones remain valid. </p> <p> If we change Tor to look at its cached-certs and refuse to believe in a signing key if it's convinced there's a newer one, then we can invalidate older ones by generating newer ones. </p> <p> That approach wouldn't protect users who are bootstrapping for the first time, but it would protect them if they'd already bootstrapped. Is this a worthwhile improvement? </p> <p> Note that we'd have to sort out edge cases like <a class="closed ticket" href="" title="#11457: defect: Making a signing cert in the future will make everybody discard your ... (closed: implemented)">#11457</a> -- basically in this case it would mean that if you ever generate a signing key too far in the future and then also want to go back to an earlier one, you're fucked. But has anybody ever needed to do that? </p> <p> To tolerate rotation better, we'd want the logic to be something like the suggested fix in <a class="closed ticket" href="" title="#11454: defect: If two auth certs are both old but were generated nearby in time, we ... (closed: implemented)">#11454</a>: only disbelieve a cert if a) we have a newer one and b) the one we're disbelieving is sufficiently older than now. </p> <p> We could also think about shipping with a cached-certs file to keep raising the bar as users upgrade. </p> Results #11973: Should relays stop making unencrypted directory connections? Thu, 15 May 2014 15:36:01 GMT nickm <p> Continuing a discussion from <a class="closed ticket" href="" title="#11469: defect: Exit not using one hop circuit to Directory Server (closed: fixed)">#11469</a> : </p> <p> There is a case to be made that relays should stop uploading and downloading directory information via HTTP. We should consider the arguments there and see if there's a good rationale beyond the standard "why not encrypt everything" baseline. </p> <p> (To be clear, bridges don't make connections over HTTP.) </p> Results #12799: fingerprints - descriptor Space removal, case normalization Tue, 05 Aug 2014 19:19:57 GMT grarpamp <p> cached-descriptors... fingerprint 50E9 30FB 6141 E9A7 DAD4 968E 58DE AA1B 06CF 4908 Remove the spaces from the fingerprints. </p> <p> This isn't OpenPGP, no one goes around reading them off to people. You have to click-hold-carefully-drag to select the whole FP instead of a simple double-click. You have to postprocess strip them to make any use of them anywhere, including everywhere else in Tor... torctl, configs, etc. Nowhere else does Tor present/accept any fingerprints with spaces. And they currently waste about 60kB per descriptor set X all the nodes X frequency. The spaces have no substantive use whatsoever and are very annoying! Please remove them. </p> <p> With that, normalize all displayed/coded fingerprints everywhere in Tor to be either upper or lower case... regardless of whether either/mixed case are supported/enforced as input. Lower case is suggested for better readability (ie: A4B8D0 vs. a4b8d0) and commonality with outputs of various hash programs. </p> Results #13230: Make good use of unstable relays Wed, 24 Sep 2014 00:11:59 GMT jeffluo35 <p> Since some people run a Tor relay but shutdown their computer at night, the Tor relay should be able to keep its flags, etc the next time it is online again. </p> Results #13444: "GhostNode" - support relays that cannot accept incoming connections. Fri, 17 Oct 2014 03:24:23 GMT ikurua22 <p> My ISP doesn't offer global IP address(10.10.20.X shared), which I can't help people by setting up middle(nonexit) nodes. Why tor require opening a port!? </p> <p> What about HiddenService? It can work without opening a port to global, right? So, how about this idea. </p> <p> "GhostNode" 1. It doesn't require user to open a port to global(no router setting). 2. It works like a hidden service protocol. Your global IP won't go public. </p> <p> Client---torBridgeNode===tor2===tor2===tor4--&gt;website or Client---tor1===tor2===tor4--&gt;website </p> <p> tor1; nonexit tor2; ghost tor4; exit </p> <p> tor1 ask tor2 to connect tor4. (just like HiddenService did) tor2(GhostNode) make a connection to tor4(exitnode). </p> Results #13508: Add messaging protocol that is resistant to traffic analysis Tue, 21 Oct 2014 16:41:26 GMT Alan <p> This is a proposal to add a messaging protocol that is resistant to traffic analysis. The protocol would allow a message of reasonable length to be sent to a relay, which would then store the message for a variable period of time before forwarding to the next relay in the circuit. Circuits would be built using the message store-and-forward protocol to send setup messages, including circuits to and from Tor hidden service rendezvous points. The variable delay time could potentially be programmed by the client in the message wrapper. </p> <p> Clients could take advantage of this protocol (including Tor hidden services) to implement messaging clients that are resistant to traffic analysis, i.e., the variable delay between the time messages are received and sent would make it vastly more difficult to determine the endpoints of a message by observing the packets being sent between a set of relays. This protocol would not be suitable for "realtime" applications such as web browsing and voice or video communication; it would only be suitable for text messages, file transfer and similar non-realtime applications. </p> Results #13705: Allow relays to promise in their descriptor that their IP address won't change Fri, 07 Nov 2014 23:47:39 GMT arma <p> Imagine the following scenario: Oscar runs a fast relay that gets the Guard flag and accumulates some users, including a user Alice. Then some attacker does a guard enumeration attack to identify that his victim is using Oscar's relay as her guard. He can get a warrant to collect Oscar's computer, but for whatever reason he's not allowed to tap the relay in-place. So he steals the computer, takes it to his location, turns it back on, and the relay starts up again. Alice then says "oh good, my guard is back online" and moves back to using it. </p> <p> One straightforward option to reduce the risk of this scenario happening in practice is for relays that intend to have a static IP address to set a line in their descriptor that tells the directory authorities to refuse them if they show up from a different IP address. The implementation on the directory authority side would be to add the IP address to fingerprint mapping to the router-stability file or equivalent, and then check whether there's a mapping when considering newly published descriptors. </p> <p> This idea wouldn't handle the attack when done on relays with dynamic or varying IP addresses. </p> <p> Another avenue for addressing the attack is the encrypted identity key proposal and friends. I'm not sure if they handle this issue, or are orthogonal, or would supersede this idea. </p> Results #13908: Make it safe to set NumDirectoryGuards=1 Sat, 06 Dec 2014 03:10:05 GMT arma <p> Currently we have NumEntryGuards=1, which mitigates the "you expose your 3-hop circuits to too many relays" issue, but we still have NumDirectoryGuards=3, which means the "you have a unique guard fingerprint with respect to a local network observer" issue remains. </p> <p> We should reduce NumDirectoryGuards to 1, but that's hard for now because, as Nick has pointed out, an attacking guard can withhold certain descriptors from a client to influence its path selection and thus harm its anonymity. </p> <p> My first thought for a fix to that issue is that if you can't get all the microdescriptors you want from your guard, you should drop it and find a new one. But I think that could produce some really bad behavior network-wide if there are some microdescriptors that are hard to find in the network, or if there are race conditions where a consensus lists a relay but the guard doesn't quite have the microdescriptor for it yet so all its clients jump ship. Yuck. </p> <p> My second thought for a fix is that if you can't get all the descriptors you want, but you can get some, then you could make a two-hop circuit through your guard to another relay, and ask it for the descriptors. That sounds great, except your guard could say "sorry that one's unreachable" and end up influencing which ones you can ask questions to, ending up with a variant of the original attack. </p> <p> Nick suggested an extension of this idea where you try asking a few relays indirectly (using 2-hop circuits) and if you still can't get all your microdescriptors then you add another directory guard directly. I think that leads to the research question: how often does that situation happen naturally? </p> <p> Specifically, if you pick three directory guards right now, what is the probability distribution over fetching a given fraction of the microdescriptors from the consensus? I can't imagine you'll get 100% of them consistently. </p> <p> Once we have some expected threshold that we reach pretty consistently, should we call that good enough, since it matches what we get right now currently? Or should we worry that one guard could somehow cause the missing descriptors to be more precisely chosen than in the current design? </p> <p> Another idea I had was to extend from the guard to a directory authority, since surely those won't all be down. That's sort of sad to make a bottleneck though. </p> <p> Yet another idea is to do a three-hop circuit, so the guard doesn't know the chosen third hop. That ties directly into the path-bias field I guess. </p> <p> Taking a step back: how about a simpler design where you do a 2-hop circuit through your guard, and you try like n=10 of them, and so long as k=3 of the extends succeed, you believe that the microdescriptor is indeed hard to get, and otherwise you ask another directory guard directly? </p> <p> Lots of options -- somebody should analyze them, and ideally show that one of the simpler ones is adequate. </p> Results #15000: bring some sanity to quoted strings in the controller api Mon, 23 Feb 2015 15:24:49 GMT nickm <p> <a class="new ticket" href="" title="#14999: defect: Most/all esc_for_log instances in control.c should change. (new)">#14999</a> is about a possible mass migration to doing QuotedString right... but we can at least fix the things introduced in <a class="closed ticket" href="" title="#8405: enhancement: Provide a control port command to query the circuit used for SOCKS u+p (closed: implemented)">#8405</a>, since we *know* they won't break any users. </p> Results #15060: Decide the fate of MyFamily Fri, 27 Feb 2015 15:14:00 GMT nickm <p> See discussion on <a class="reopened ticket" href="" title="#5565: enhancement: MyFamily should provide an alternate non-idhex subscription mechanism (reopened)">#5565</a> and <a class="closed ticket" href="" title="#6676: task: Nuke ‘MyFamily’ (closed: wontfix)">#6676</a>. It may be that the family declaration is making guard selection worse, and if so, maybe we should not do guard selection in the same way. Having some paths with all three nodes in the same family scares me, though. </p> <p> We could do better than the current family system using certs as described in prop220. First we should decide whether we want to keep families at all, though. </p> Results #15061: Support Ed25519 identities in controller interface Fri, 27 Feb 2015 15:18:34 GMT nickm <p> Once <a class="closed ticket" href="" title="#12498: task: Implement ed25519 identity keys (prop 220) (closed: implemented)">#12498</a> is merged, we'll be able to identify nodes by ed25519 keys. We should allow the controller to do this too. </p> <p> This might be a use case for USEFEATURE -- <code>USEFEATURE ed25519-ids</code> could allow us to describe nodes by their best keys, and we could accept ed25519 keys regardless. </p> Results #15232: Specify a potential TLS-replacing protocol for future use in Tor. Wed, 11 Mar 2015 18:38:34 GMT nickm <p> We should wrap up the design stuff on v0 of "tentp", and rename it. </p> Results #15941: Form a plan for killing off client versions which assume they'll live forever Wed, 06 May 2015 19:25:26 GMT teor <p> From at least 0.2.4 to 0.2.6, tor client versions assume that they will keep on using the network forever. They have no "request to stop" code or other mechanisms that prevent them becoming a drain on the network. </p> <p> It would help to plan their transition out at some point, so we can work out what to do to make version obsolescence in future. </p> <p> See <a class="closed ticket" href="" title="#15233: task: Form a plan for killing off 0.2.2 and 0.2.3 (closed: implemented)">#15233</a> for killing off 0.2.2 and 0.2.3 </p> Results #16059: Add a "rendezvous approver" control API Sat, 16 May 2015 21:27:23 GMT special <p> From the discussion on mitigating HS denial of service in <a class="closed ticket" href="" title="#16052: defect: Hidden service socket exhaustion by opening many connections (closed: fixed)">#16052</a>: </p> <blockquote class="citation"> <blockquote> <p> Add a "rendezvous approver" control API, which gives an opted-in controller the chance to approve or deny all rendezvous circuit and stream requests before they're acted upon. This would allow us to make more complex and useful mitigations as third party software. </p> </blockquote> </blockquote> <p> This might be useful for: </p> <ul><li>Rate limiting; at most N unauthenticated clients per Y </li><li>Extra-conservative logic like "stop accepting connections during potential guard discovery" </li><li>Limiting capacity to control server load; only allow N simultaneous clients. </li><li>Protocol-tuned rules for things like Ricochet </li><li>More advanced pre-rendezvous authorization </li></ul><p> arma also noted: </p> <blockquote class="citation"> <p> Speaking of the mitigator, the original HS design had the services giving out tokens to preferred users, who then use the token to get access during times of high load. </p> </blockquote> <p> This could be built by using a new auth type for access tokens, and checking them in the approver. </p> Results #16844: Slow clients can't bootstrap because they expire their consensus fetch but then receive all the bytes from it anyway, making them expire their next fetch, putting them in a terrible loop Mon, 17 Aug 2015 18:34:24 GMT arma <p> If you start your Tor client with no cached directory info, and on a slow (high latency) link, you get: </p> <pre class="wiki">$ tail -f tordebug-log|grep connected Aug 09 16:17:12.299 [info] circuit_handle_first_hop(): Next router is $7EA6EAD6FD83083C538F44038BBFA077587DD755~7EA6EAD6FD83083C538 at Not connected. Connecting. Aug 09 16:17:12.826 [info] connection_edge_process_relay_cell_not_open(): 'connected' received for circid 2747423797 streamid 16685 after 0 seconds. Aug 09 16:21:57.298 [info] circuit_handle_first_hop(): Next router is $9695DFC35FFEB861329B9F1AB04C46397020CE31~9695DFC35FFEB861329 at Not connected. Connecting. Aug 09 16:21:59.099 [info] connection_edge_process_relay_cell_not_open(): 'connected' received for circid 4248917890 streamid 42612 after 1 seconds. Aug 09 16:22:09.711 [info] circuit_handle_first_hop(): Next router is $332CD489177F202570A7021328A17A91BF823889~332CD489177F202570A at Not connected. Connecting. Aug 09 16:22:09.711 [info] circuit_handle_first_hop(): Next router is $90E9E44FD74B98F87F7573F917AE4AF651B86B4C~90E9E44FD74B98F87F7 at Not connected. Connecting. Aug 09 16:22:09.712 [info] circuit_handle_first_hop(): Next router is $547C1CDB516798EC66A01F04A5884DCE1A151919~547C1CDB516798EC66A at Not connected. Connecting. Aug 09 16:22:12.499 [info] connection_edge_process_relay_cell_not_open(): 'connected' received for circid 2850575558 streamid 43745 after 0 seconds. Aug 09 16:23:33.901 [info] connection_edge_process_relay_cell(): 'connected' received on circid 2850575558 for streamid 43746, no conn attached anymore. Ignoring. Aug 09 16:24:11.599 [info] connection_edge_process_relay_cell_not_open(): 'connected' received for circid 4148503990 streamid 17036 after 0 seconds. Aug 09 16:25:34.306 [info] connection_edge_process_relay_cell(): 'connected' received on circid 4148503990 for streamid 17037, no conn attached anymore. Ignoring. Aug 09 16:26:29.559 [info] connection_edge_process_relay_cell_not_open(): 'connected' received for circid 2948078868 streamid 42748 after 0 seconds. [...] </pre><p> Oh hey, what's this "no conn attached anymore" issue? </p> <pre class="wiki">$ grep 43746 tordebug-log Aug 09 16:22:12.302 [info] connection_ap_handshake_send_begin(): Sending relay cell 1 on circ 2850575558 to begin stream 43746. Aug 09 16:22:22.299 [debug] circuit_detach_stream(): Removing stream 43746 from circ 2850575558 Aug 09 16:23:33.901 [debug] connection_edge_process_relay_cell(): Now seen 1433 relay cells here (command 4, stream 43746). Aug 09 16:23:33.901 [info] connection_edge_process_relay_cell(): 'connected' received on circid 2850575558 for streamid 43746, no conn attached anymore. Ignoring. Aug 09 16:23:35.799 [debug] connection_edge_process_relay_cell(): Now seen 1434 relay cells here (command 2, stream 43746). Aug 09 16:23:35.799 [info] connection_edge_process_relay_cell(): data cell dropped, unknown stream (streamid 43746). [...] </pre><p> We're hitting the 10-second stream timeout in connection_ap_expire_beginning(), and detaching the stream from the circuit, and presumably trying it again elsewhere. </p> <p> But that last line above, "data cell dropped", is especially bad news for us -- we get the whole answer, and ignore it all, since we sent an 'end' cell changing our mind but the answer was already coming at us. </p> <p> This situation comes up because of the optimistic data feature -- we get the answer to our request bundled with the 'connected' cell, which is a feature except in the case where we canceled (and then forgot about) the stream. </p> <p> For people trying to bootstrap their Tor on a low-bandwidth high-latency network connection, I bet this landmine will be especially frustrating, since you will be clogging your network connection with directory information that you will discard, which in turn will delay the receipt of the other directory information. </p> <p> You can reproduce the bug on your own, even if you have a great network connection, by starting your Tor with "bandwidthrate 2000 bandwidthburst 5000". </p> Results #16978: Minority of hostile dirauths can influence consensus in dangerous ways Fri, 04 Sep 2015 14:27:49 GMT Sebastian <p> We like to claim that if a minority of dirauths is not honest, the worst they can do is manipulate the voting process in such a way that no consensus emerges but not that a consensus emerges that is (at least partially) dictated by the bad actors. Unfortunately, this isn't the case for the opt-in features. If a majority of the dirauths opting in to features such as bad exit voting, bandwidth measurements, or voting for a specific parameter want to influence these values in the consensus, they don't require a majority of total dirauths to do that. This might not be so much of an issue with less important features like Naming, but since badexit and bandwidth weight directly influences path selection on the client, these authorities that opt in to those features have considerably more power over the consensus than those that do not. </p> Results #17272: Finalize a proposal for postquantum circuit-extension Wed, 07 Oct 2015 15:16:00 GMT nickm <p> There are a few ideas floating around the literature here, and some promising ideas. We should get at least one to have a proposal number by some time in December, I hope. </p> Results #17278: Fix malleable relay crypto Wed, 07 Oct 2015 15:34:35 GMT nickm <p> This has been an annoyance in our protocol for entirely too long. Once we have a solid proposal (<a class="closed ticket" href="" title="#5460: defect: Write proposal(s) to implement improved relay/circuit crypto authentication (closed: implemented)">#5460</a>) for this, we should implement it posthaste. </p> Results #17957: Detect stolen onion service key Tue, 29 Dec 2015 18:55:52 GMT ess2 <p> Would it be possible to add a detection mechanism for stolen onion service keys? </p> <p> How it could work (I know very little about Tor internals): A HSDir could tell the tor client that someone else with the same key announced a hidden service just minutes ago. To determine that it was someone else, a random number could be sent with each announcement of an onion service, and that number randomly changes every time tor is restarted. If tor isn't restarted but the HSDir tells the announcing tor client that a different number was used to announce the onion service before, one could reasonably suspect that the key has been compromised. The user could then try to rule out a false positive, and get a new key. </p> <p> It might be problematic that the HSDir can lie to .onions it doesn't like, but as long as no automatic action but the notification is done, this shouldn't cause much harm. </p> Results #18636: Write sub-proposals for each part of prop257: Refactoring authorities. Implement as appropriate. Fri, 25 Mar 2016 21:31:10 GMT nickm <p> Proposal 257 outlines a pretty large amount of stuff to do, but each part of it probably needs its own proposal. Let's get cracking on that ! </p> Results #19009: bandwidth testing circuits should be allowed to use our guards Mon, 09 May 2016 23:28:31 GMT arma <p> In git commit 267e61d0, we fixed bug <a class="closed ticket" href="" title="#654: defect: Don't re-use entry point for testing circuits (closed: Fixed)">#654</a>, where relays were putting all their bandwidth testing circuits over the same small set of guards, thus having an accidental bottleneck, meaning we got an inaccurate bandwidth estimate. </p> <p> But we fixed it by having them *never* use a guard for their first hop of a testing circuit, which in turn produced surprising behavior in tiny test networks, because relays can't make testing circuits if all the available relays are in their guard list. </p> <p> teor fixed that in commit 22a1e9cac by making us not avoid our guards if testingtornetwork, and not avoid our guards if all the nodes in the consensus are on our guard list. It turns out that latter check isn't quite good enough, because we're picking two hops, so having at least one relay in the network that isn't in our guard list isn't enough to complete a circuit. </p> <p> The underlying problem is that when UseEntryGuards is true, the rest of choose_good_entry_server() is entirely about picking a new entry guard. Except we reuse it for some edge cases where we want to just pick some entry point and not use our guard list. Some refactoring or something seems wise. </p> Results #19304: Write a proposal for having dirauths push to fallbacks, rather than pull. Mon, 06 Jun 2016 17:45:56 GMT nickm <p> This will require some kind of chatter mechanism for fallbacks to circulate documents. </p> Results #19305: Write a proposal for separating "upload descriptors here" from the rest of what dirauths do. Mon, 06 Jun 2016 17:46:15 GMT nickm Results #19306: Write a proposal for removing liveness-testing from dirauths. Mon, 06 Jun 2016 17:48:12 GMT nickm Results #19625: Allow relays to set peering policy Wed, 06 Jul 2016 13:48:32 GMT twim <p> As mentioned in the discussion at tor-relays@ (<a class="missing changeset" title="Unsupported version control system &#34;·&#34;: Can't find an appropriate component, maybe the corresponding plugin was not enabled? ">[1]</a>, <a class="missing changeset" title="Unsupported version control system &#34;·&#34;: Can't find an appropriate component, maybe the corresponding plugin was not enabled? ">[2]</a>), it would be nice to have some kind of peering policy for relays so that relay operators could restrict connections with suspicious/malicious relays themselves. </p> <p> Having PeeringPolicy similar to ExitPolicy (accept, reject) is what comes to mind first. Though it may not be the best solution. </p> <p> Also, as a side effect it can allow to have smaller state table/less file descriptors for average relay that can help with scaling of the network in the future. </p> <p> <a class="missing changeset" title="Unsupported version control system &#34;·&#34;: Can't find an appropriate component, maybe the corresponding plugin was not enabled? ">[1]</a> <a class="ext-link" href=""><span class="icon">​</span></a> <a class="missing changeset" title="Unsupported version control system &#34;·&#34;: Can't find an appropriate component, maybe the corresponding plugin was not enabled? ">[2]</a> <a class="ext-link" href=""><span class="icon">​</span></a> </p> Results #20742: prop224: Implement stealth client authorization Tue, 22 Nov 2016 16:21:00 GMT asn <p> prop224 currently does not specify stealth client authorization. </p> <p> This is a feature from <code>rend-spec.txt</code> which makes the HS create a unique onion address for each authorized client. This way revoked clients cannot get presense information about the hidden service, since they don't know the onion addresses of other clients. </p> <p> This is useful for cases where authorized clients have a chance of turning adversarial and there is a need for total revocation. </p> <p> tl;dr: We need to specify stealth auth in prop224, and implement it. </p> Results #21413: Exits can get the Exit flag without having any ports in their microdescriptor port summary Wed, 08 Feb 2017 06:29:26 GMT teor <p> Almost all clients, relays, and authorities use microdescriptors by default. </p> <p> Microdescriptor port summaries include a port if it exits to almost all IPv4 addresses (blocks no more than an IPv4 /7). </p> <p> But the Exit flag is given if at least two of ports 80, 443, 6667 exit to at least an IPv4 /8. </p> <p> This means an Exit can get the Exit flag, without having any of these ports in its IPv4 exit policy summary. </p> <p> I suggest we only award the Exit flag if an Exit has at least two of ports 80, 443, 6667 in its IPv4 Exit policy summary. </p> <p> This also requires a spec change for the Exit flag. </p> Results #21424: Treat directory guard success only as a partial success for the guard? Thu, 09 Feb 2017 15:24:37 GMT nickm <p> Right now, we treat having received data from a directory guard as that guard having succeeded. But this could be trouble: it doesn't actually mean that the guard will make circuits nicely. We could use a notion of 'partial success' for guards, possibly? Or a separate directory/circuit success track? </p> Results #21969: We're missing descriptors for some of our primary entry guards Mon, 17 Apr 2017 11:41:46 GMT asn <p> Seems like there are still a few cases where bootstrapping will stall because of: </p> <pre class="wiki">I learned some more directory information, but not enough to build a circuit: We're missing descriptors for some of our primary entry guards </pre><p> It seems to happen mainly with bridges. For me it occured with latest master (<code>b081a7ed2</code>) when I was switching between using private bridges and the default TBB bridges. I also heard reports from s7r about this happening. </p> <p> We last changed this behavior in <a class="closed ticket" href="" title="#21415: defect: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845: ... (closed: fixed)">#21415</a>, when we made Tor require that we have the descriptor of 2 bridges before we start building circuits. </p> Results #22339: META: Implement some form of jurisdiction/geography/topology-aware routing Tue, 23 May 2017 12:30:54 GMT nickm <p> This is a parent ticket for all of the tickets about using some information about the world or the internet in order to try to pick better routes. </p> Results #22340: META: allow exits to restrict on something more sophisticated than IPs Tue, 23 May 2017 13:11:02 GMT nickm <p> Right now exit nodes only support IP-based restrictions... and in microdescriptors, those IP-based restrictions are summarized as port-based restrictions. From time to time people ask for restrictions based on other things, like AS ids, hostnames, etc. </p> <p> I'm not sure I see a way to do this that would actually be worth the difficulty, much less one that would work... but perhaps there are benefits I'm not seeing? </p> <p> Creating this as a meta-ticket so I can close other things as duplicates of it </p> Results #22453: Relays should regularly do a larger bandwidth self-test Tue, 30 May 2017 17:52:07 GMT arma <p> Inspired by <a class="closed ticket" href="" title="#8247: defect: Some day soon, a 50KB bandwidth test will be too low for the Fast flag (closed: worksforme)">#8247</a> ("In sum. a vestigial tiny bw self-test seems silly to keep around"), I wonder if we're at the point where we can just take out all the bandwidth self-test infrastructure. </p> <p> In favor of ripping it out: there's some complexity at relay startup where we try to delay publishing our descriptor until we've done the self-test, since we know we'll have a newer bandwidth number to include soon. We've had bugs in this delay step. </p> <p> In favor of ripping it out: in the current design we try to build 4 separate circuits, without using our guards in order to have actually independent paths, for pushing our 500KB. Relays that aren't reachable end up with hundreds or thousands of connections open, because they keep making new circuits and each one probably is to a new relay. Not a big deal but kind of unfortunate. </p> <p> In favor of ripping it out: 50KB, which is the most that the current bandwidth test can tell you, is super tiny compared to current descriptor bandwidths and current consensus weights. In fact, as prophesied in <a class="closed ticket" href="" title="#8247: defect: Some day soon, a 50KB bandwidth test will be too low for the Fast flag (closed: worksforme)">#8247</a>, the threshold for the Fast flag is now above 50KB, so publishing 0 vs 50 is essentially just moving you around within the "don't use, they're too slow" bucket. </p> <p> In favor of keeping it: maybe the bandwidth authorities have some sort of psychotic behavior in the face of relays that have a 0 in their descriptor? Like, they multiply the 0 by a factor for how much better than the other 0's they are? I have no idea. In case they do, I propose that we proceed with ripping out the self-test, and simply replace it with the number "20KB" to guard against psychotic bwauth behavior. (I picked that number because the directory authorities already use the number 20 when assigning a weight to a relay that (A) is unmeasured and (B) self-declares at least 20KB in its descriptor.) </p> <p> Note: if we do keep it in, here's a better design: <a href=""></a> </p> <p> But what about bridges, you might ask? Public relays might have the bwauths to measure them remotely, but bridges don't have that. I think nothing uses the bandwidths in bridge descriptors. Are there any plans for that to change in the future? Even if there are, I think raising the floor from 0 to 20, and retaining the behavior where we publish a bigger number if we actually see a bigger number due to client load, should make us compatible with whatever these plans might be. </p> Results #22455: Enumerate cases where we want to retry circuits, and correctly balance retry robustness with guard discovery Tue, 30 May 2017 19:14:57 GMT arma <p> In Tor, and especially in the onion service subsystem, we have a bunch of situations where a circuit could fail and we ought to retry: </p> <ul><li>the onion service attempting to connect to the rendezvous point </li><li>the onion service attempting to publish an hsdesc to the hsdir </li><li>the client attempts to reach the intro point to send its intro1 cell </li></ul><p> If we retry too many times, we open ourselves up to new guard discovery attacks (see prop 247). If we retry too few times, we end up with robustness or reachability problems ("Tor doesn't work"). </p> <p> It would be nice to just design the single best retry algorithm, and then apply it to all cases. That way we do the hard design and analysis work once, and we don't end up with extra complexity when we combine multiple retry designs. But I think a single best design might not be possible -- compare the service-side hsdir case, where it might be best to wait a while before retrying, to the rend point case, where waiting a while before retrying is not so good. Maybe that argues that we can get away with two best designs, one in the "online, somebody's waiting on me" case, and the other in the "offline, let's get this done reliably but there's no immediate rush" case? </p> <p> Suggested next step: We should write a proposal, with a section enumerating all of the retry situations that tor has; and a section enumerating what we can learn about where the circuit failures are, and how, and how reliable each is (network failure? last hop faillure? guard failure?); and then a section trying to produce the smallest possible number of good designs such that every retry situation is handled well. </p> Results #22498: Offline directory authorities need a way to post their certificate to other authorities Mon, 05 Jun 2017 16:28:23 GMT teor <p> We have wanted to be able to run (the signing parts of) a directory authority offline for a while, because it's more secure. </p> <p> So I have been experimenting with an offline (ORPort and DirPort unreachable) directory authority on the test net. </p> <p> Almost everything works: it posts votes, downloads votes from other authorities, signs consensuses, and posts its signature. It could easily do these things using a 3-hop Tor path. </p> <p> But once its authority certificate expires, it has no way to post it to the other authorities. </p> <p> A workaround is to overwrite another authority's cached-certs file with the missing authority certificate file. But this is nasty. </p> <p> We should make authorities accept certificate posts, and post their certificates to one another. </p> Results #23280: Censorship resistant onion sites Sat, 19 Aug 2017 19:39:31 GMT cypherpunks <p> Currently HSDir and Introduction Point are in position to block a onion site if they want. HSDirs just see the site's address in plaintext and Introduction Point can check the site in HSDirs to find records related to the site and remove such records from themselves. </p> <p> So, if all hsdirs OR all Introduction Points want to block the site X, they can. </p> <p> prop224 makes onion site names less discoverable, but once discovered, they can be removed in exactly the same way. </p> <p> I believe that a system that is resistant to censoring certain sites must satisfy the following condition: nobody except the client and the site can distinguish activities related to the site. Not hsdirs, not Introduction Points, literally nobody. </p> <p> Here is my proposal of a protocol which seems to satisfy this condition. </p> <p> Participants: </p> <blockquote> <p> Operator -- A person running a hidden service </p> </blockquote> <blockquote> <p> Host, "Server" -- The Tor software run by the operator to provide </p> <blockquote> <p> a hidden service. </p> </blockquote> </blockquote> <blockquote> <p> User -- A person contacting a hidden service. </p> </blockquote> <blockquote> <p> Client -- The Tor software running on the User's computer </p> </blockquote> <blockquote> <p> Pubsub Point -- A Tor node that accepts anonymous subscription </p> <blockquote> <p> requests and anonymous publishing requests and translated all data sent in publishing requests to all subscribers. </p> </blockquote> </blockquote> <blockquote> <p> Rendezvous Point -- A Tor node to which clients and servers </p> <blockquote> <p> connect and which relays traffic between them. </p> </blockquote> </blockquote> <p> Data involved: </p> <blockquote> <p> Onion site name - a public key for Asymmetric Encryption. </p> </blockquote> <p> </p> <blockquote> <p> Access Token - one time secret used by between Client Host when </p> <blockquote> <p> contacting Rendezvous Point. It is used by Rendezvous Point to match a connection from Client with the corresponding connection from Host. </p> </blockquote> </blockquote> <p> </p> <blockquote> <p> Access Key - cryptographic key used by between Client Host when </p> <blockquote> <p> contacting Rendezvous Point. It is needed to protect data passed through Rendezvous Point by authenticated encryption. </p> </blockquote> </blockquote> <h2 id="WhatPubsubPoint">What Pubsub Point</h2> <p> It has two "methods": </p> <p> HOST - keep the connection open. CLIENT - read a piece of data from the connection and send it to all open HOST connections. </p> <h2 id="WhatRendezvousPointdoes">What Rendezvous Point does</h2> <p> It has two "methods": </p> <p> CLIENT - read Access Token from the connection and keep it open. HOST - read Access Token from the connection, lookup the CLIENT </p> <blockquote> <p> connection with this Access Token and connect them. </p> </blockquote> <h2 id="Client-Hostprotocol">Client-Host protocol</h2> <p> A hidden service is identified with a public key (not with a fingerprint as now). A Client can encrypt a message with the public key. The ciphertext can be decrypted only by the Host. All other parties can not decrypt it and can't tell the Host (i.e. the public key) from the ciphertext. </p> <p> A shared random algorithm (similar to the existing one) is used to derive a set of Tor nodes from a public key. These nodes are Pubsub Points. </p> <p> The Host establishes an anonymous connection to its Pubsub Points and starts listening. </p> <p> The Client generates random string to be Access Token. The Client generates random string to be Access Key. The Client chooses a random Tor node and connects to it as to Rendezvous Point using the Access Token. </p> <p> Then the Client makes tuple (Rendezvous Point pubkey, Access Token, Access Key), encrypts it with the Host public key. </p> <p> The Client connects to the Pubsub Points whose pubkeys are derived from the Host pubkey (see above). The Client sends the ciphertext to the Pubsub Points. </p> <p> The Host reads all data from the Pubsub and tries to decrypt it. If it succeeds, it connects to the Rendezvous Point specified in the decrypted message with the Access Token specified in the decrypted message. The Access Key specified in the decrypted message is used by Host and Client to protect communications from the Rendezvous Point with authenticated encryption. </p> <h2 id="Theattackontheprotocoltocensoraparticularonionsite">The attack on the protocol to censor a particular onion site</h2> <p> The malicious Pubsub Points wants to block a particular onion site. It makes a Client connection to the site, but sends the ciphertext only to itself (not to other Pubsub Points) and the Pubsub Point sends it to only one of the listeners. If the Client succeeds connecting the Host the Pubsub makes a conclusion that the connection belongs to the Host and stops sending ciphertexts to that connection. </p> <p> A Host can protect itself from this kind of attack by opening a new connection to Pubsub Points from time to time. Also it can open two connections to the same Pubsub Point and compare results it gets from them. If some ciphertext is missing in one of connections, it opens one more connection and so on. </p> Results #23620: Tor lies about "Optimistically trying directory fetches again" Fri, 22 Sep 2017 12:22:57 GMT teor <p> My tor hasn't sent anything to the network for 15 minutes, but it keeps telling me <code>Application request when we haven't used client functionality lately. Optimistically trying directory fetches again.</code> </p> <p> My laptop was asleep, and when I woke it up, Tor tried to connect to the network a few times, and then ended up in this state. </p> <pre class="wiki">21/9/17, 12:35:33.100 [NOTICE] Average packaged cell fullness: 67.067%. TLS write overhead: 4% 21/9/17, 12:46:37.900 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working. 21/9/17, 12:46:37.900 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working. 22/9/17, 11:42:02.700 [NOTICE] Your system clock just jumped 65128 seconds forward; assuming established circuits no longer work. 22/9/17, 11:42:02.700 [NOTICE] Heartbeat: Tor's uptime is 4 days 16:01 hours, with 0 circuits open. I've sent 11.27 MB and received 124.39 MB. 22/9/17, 11:42:02.700 [NOTICE] Average packaged cell fullness: 67.151%. TLS write overhead: 4% 22/9/17, 11:52:39.800 [NOTICE] Application request when we haven't used client functionality lately. Optimistically trying directory fetches again. 22/9/17, 11:54:39.000 [NOTICE] Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. (waiting for circuit) 22/9/17, 12:05:05.400 [NOTICE] Application request when we haven't used client functionality lately. Optimistically trying directory fetches again. (repeats many times) </pre> Results #23863: When our directory guards don't have each others' microdescs, we should try an authority or fallback Sat, 14 Oct 2017 21:27:19 GMT teor <p> If our directory guards don't have each others' microdescriptors, we should mark some of them dead. </p> <p> But should we mark the one that won't give us the microdescriptor dead? Or should we mark the one that we can't get a microdescriptor for dead? </p> Results #24366: compare_vote_rs() could check more fields for better SHA1 collision resistance Tue, 21 Nov 2017 11:17:57 GMT teor <p> If someone submits descriptors with the same SHA1 hashes, compare_vote_rs() checks a few fields to make sure they are really the same. </p> <p> We should make sure there is some way of checking all (most?) of the fields. And we should compare new fields when they are added to [vote_]routerstatus_t. But we can't just use a binary comparison, because some of the fields are pointers. </p> <p> Do we need a new consensus method to add extra tie-breakers? </p> <p> Here are the fields from vote_routerstatus_t and routerstatus_t, in rough order of size/flexibility/collision-usefulness: </p> <p> Comparing these is probably necessary, they have 128+ bits of entropy: </p> <ul><li>version </li><li>protocols </li><li>exitsummary </li><li>ed25519_id </li><li>ipv6_addr </li></ul><p> Comparing these might not be necessary, they only have a few bits: </p> <ul><li>ipv6_orport </li><li>measured_bw_kb / bandwidth_kb ? </li><li>guardfraction_percentage </li></ul><p> I'm not sure if comparing these is necessary, they probably don't have enough bits to lead to a collision: </p> <ul><li>flags / is_x (x is a flag name) </li><li>supports_x (x is a feature name) </li><li>has_guardfraction </li><li>has_measured_bw </li><li>has_ed25519_listing </li><li>has_bandwidth </li><li>has_exitsummary </li></ul><p> This is a bug in Tor, which introduced this tie-breaking code. (Or in all the versions since then that added extra fields to [vote_]routerstatus_t, but didn't add them to the tie-breakers.) </p> Results #24404: Propose a relay protover that allows IPv6 extends Sun, 26 Nov 2017 02:46:36 GMT teor <p> Write a proposal for a relay protover, in which relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may be over IPv4.) </p> Results #24405: Implement relay IPv6 extends with proposed protover Sun, 26 Nov 2017 02:50:34 GMT teor <p> Make relays with IPv6 ORPorts start attempting to connect to IPv6 ORPorts in response to EXTEND2 cells containing IPv6 addresses. (Relays always prefer existing canonical connections, which may be over IPv4.) </p> <p> Make these relays declare the protover from <a class="new ticket" href="" title="#24404: enhancement: Propose a relay protover that allows IPv6 extends (new)">#24404</a>. </p> <p> Make them implement the IPv4/IPv6 Extend behviour from <a class="new ticket" href="" title="#24404: enhancement: Propose a relay protover that allows IPv6 extends (new)">#24404</a>. </p> Results #24487: Reverse path selection (choose outer hops first) Fri, 01 Dec 2017 23:37:10 GMT mikeperry <p> Because Tor's path selection chooses inner nodes first, and then excludes those nodes from being used in outer hops, over many circuits, outer hops get information about the choice of inner hops/guards. </p> <p> We need to reverse the selection of nodes in the loop circuit_establish_circuit() in order to fix this. </p> <p> This isn't as bad as it might otherwise be, because the last hop already is chosen first in that function. So it is a little tricky to take advantage of this info leak. </p> Results #24617: Feature flags for new controller-accessible Tor features Wed, 13 Dec 2017 18:54:43 GMT meejah <p> As Tor grows new features available via the control protocol, it would be useful to indicate support for these features via some GETINFO. </p> <p> Currently, controllers have two ways to discover if the Tor they connected to supports a feature: "just try" and see if there's an error; or look at the Tor version. </p> <p> Both of these can be problematic: </p> <p> You can't always "just try". For example, when HS_DESC was first added as an event it didn't include the onion address, so you'd wait forever to see if a descriptor was uploaded. For completely new commands, "just try" is probably sufficient but when commands gain new capabilities and/or options it can get less obvious what the right thing to do is. </p> <p> Doing version comparisons can get tricky: as a new feature is implemented, it will generally appear on master first, then maybe in an alpha release and finally in a "real/full" release. A controller wanting to take fullest advantage of a new feature (e.g. to let users test it against a Tor from "master") would have to program in each of these versions separately, which is tedious. </p> <p> Instead, a definitive "GETINFO" which returns details of the feature would be ideal. Then, a controller can change its behavior and take advantage of a new feature as soon as it's on master and users can continue to take advantage of this as the feature moves through alphas, betas, etcetera. This would also work well for features that can be turned off (or on) through other mechanisms (e.g. configuration, command-line or build options). </p> <p> Such flags could also "roll up" logical features that actually need multiple controller commands/events to work. For example, adding v3 services changed some config options, modified the ADD_ONION command and (later) provided upload information via the HS_DESC event. So until the ADD_ONION *and* HS_DESC changes landed, a controller couldn't properly add a v3 ephemeral service. </p> Results #24839: Add a torrc option and descriptor line to opt-in as a FallbackDir Tue, 09 Jan 2018 02:27:22 GMT teor <p> This needs: </p> <ul><li>a proposal and a design </li><li>a patch to dir-spec.txt </li><li>a patch to the tor man page </li><li>a tor code patch </li><li>an code patch </li><li>a wiki update to <a class="wiki" href="">doc/UpdatingFallbackDirectoryMirrors</a> </li></ul><p> Here's a quick sketch of a design: </p> <ol><li>Relay operators set <code>OfferFallbackDirServer 1</code> to offer their relay as a potential FallbackDir. </li><li>Relays with this option set put <code>offer-fallback-dir-server</code> in their descriptors </li><li> loads relay fingerprints with <code>offer-fallback-dir-server</code>, and from the legacy whitelist (<a class="closed ticket" href="" title="#24838: enhancement: Fuzzy match the fallback whitelist (closed: implemented)">#24838</a> will make this easier) </li><li> applies the blacklist, does stability checks, and generates the fallback list </li></ol> Results #24940: Make authorities post authority_certificate to other authorities Thu, 18 Jan 2018 21:47:35 GMT teor <p> At the moment, offline authorities work, until their certificates expire. They post their votes to other authorities, and fetch votes from other authorities, and no-one needs to connect to them. </p> <p> But when their certificates expire, no-one can get their new certificate, because it's only available via a download from that authority. </p> <p> (There's a hack that involves placing the new certificate in another authorities cached certificates file. Which is not ok on the public network.) </p> <p> Let's make a way for offline authorities to post their certificates to other authorities, and make all authorities do it when they have a new certificate. </p> Results #24990: Write a proposal for a post-quantum lattice KEX Tue, 23 Jan 2018 23:36:19 GMT isis <p> As part of <a class="new ticket" href="" title="#24985: project: Preserve circuit-layer confidentiality against a quantum-capable adversary (new)">#24985</a>, we'll need a solid, reviewed proposal for which post-quantum key exchange we intend concretely to use. </p> <p> My current idea for the key exchange is to use q=12289 and n=1024 (the lattice parameters from <a class="ext-link" href=""><span class="icon">​</span>NewHope</a> and other designs), along with the constant-time sampling protections I devised while working on <a class="ext-link" href=""><span class="icon">​</span>prop#270</a>, ripping out the Voronoi-cell based reconciliation mechanism and instead using a variant of the XE5 reconciliation from the NIST <a class="ext-link" href=""><span class="icon">​</span>HILA5</a> submission (possibly tuning down the failure probability by increasing the noise, which raises the security level, since our key exchange is interactive and thus we don't care about having the 2<sup>-128</sup> failure probability which allows HILA5 to be used for public key encryption schemes). </p> Results #25066: Rendezvous points should return signed proof of the established rend point Mon, 29 Jan 2018 10:22:34 GMT arma <p> Right now our protocol has a vulnerability where you can send an introduce attempt without actually establishing the rendezvous point that you send the onion service toward. </p> <p> If the establish_rendezvous attempt sent back a signed acknowledgment from the relay, then you could include that signed acknowledgment in your introduce attempt, and the onion service could use it to decide whether to answer. </p> <p> In the short term, when most people aren't including it, onion services would want to answer even when it's missing. But under load, or in the future where most people should be sending them, onion services could opt to discard introduction attempts that are missing a proof-of-rendezvous-point (or that provide a proof from a relay that the onion service doesn't know about). </p> <p> This idea needs some crypto design where we want to choose a compact efficient-to-compute thing that the relay can return. And also we want to figure out which key should be signing it. And we probably want some sort of timestamp in the blob so onion services can discard really old ones. </p> <p> Note that there's some flexibility for how we accomplish this goal, for example, if it helps we could change things so the relay tells the client what rendezvous cookie it can use. </p> <p> (When I say efficient, I'll note that my relay right now is receiving about 160 establish-rendezvous attempts per second, sustained -- and that's after discarding the ones from tor2web clients.) </p> <p> I am also open to other smart ideas on how best to resolve the protocol flaw. :) </p> Results #25153: Specify how PrivCount in Tor statistics are configured and interpreted Mon, 05 Feb 2018 19:50:17 GMT teor <p> In <del>prop<a class="closed ticket" href="" title="#280: defect: getaddrinfo does not set hints (closed: Fixed)">#280</a></del> prop<a class="closed ticket" href="" title="#288: defect: 'resetconf ORPort' does not close the listener (closed: Fixed)">#288</a>, we specified the counters, noise, and secure aggregation for PrivCount in Tor. </p> <p> Now we need to specify: </p> <ul><li>how long each collection round goes for </li><li>how we determine which counters are collected </li><li>how we configure the amount of noise for each counter </li><li>how Metrics can interpret the final results </li></ul><p> We should also try to answer the unanswered questions in prop280. </p> Results #25347: Tor keeps on trying the same overloaded guard over and over Sat, 24 Feb 2018 21:15:01 GMT teor <p> When Tor can't download microdescriptors (<a class="new ticket" href="" title="#21969: defect: We're missing descriptors for some of our primary entry guards (new)">#21969</a>), maybe it should try authorities or fallbacks (<a class="new ticket" href="" title="#23863: enhancement: When our directory guards don't have each others' microdescs, we ... (new)">#23863</a>), before it runs out of microdesc retries (<a class="closed ticket" href="" title="#24113: defect: We stop trying to download an md after 8 failed tries (closed: fixed)">#24113</a>). </p> <p> But even after Tor has the microdescs it needs, it sometimes doesn't start building circuits again. Instead, it is in state "waiting for circuit". </p> <p> For the log messages, see: <a href=""></a> </p> Results #25687: over-report of observed / self-measure bandwidth on fast hardware -- important to torflow / peerflow Mon, 02 Apr 2018 01:52:30 GMT starlight <p> Have observed that on fast hardware the maximum bandwidth estimate reported by <code>rep_hist_bandwidth_assess()</code> and published via <code>ri-&gt;bandwidthcapacity</code> is frequently overstated and have seen it go as high 160% of true physical bandwidth, stay there for days. </p> <p> Connected today in my mind that this may be one of the larger causes of <code>torflow</code> misbehavior No control system will function correctly with bad input data and without question +60% qualifies as bad--GIGO. </p> <p> Problem appears to have worsened with the arrival of KIST scheduler. </p> <p> Have no idea why it occurs, but have see for years, with overrating appearing relative to absolute physical link speeds and relative to Linux <code>tc-police</code> rate limits. </p> <p> Even <code>peerflow</code> when it arrives will require reliable measurement data to function properly. </p> Results #25729: UTF8 encoded TORRC does NOT parse non-Latin paths Fri, 06 Apr 2018 11:00:37 GMT Fleming <p> Unpack <a class="ext-link" href=""><span class="icon">​</span>this Tor archive</a> to C:\ </p> <p> It will create the following hierarchy: <em>C:\Проверка\Tor</em> (for executables, libraries and torrc) <em>C:\Проверка\Tor\Data</em> (for data and geoip) </p> <p> Configuration file, torrc, is encoded UTF8. It has this line: <em>DataDirectory C:\Проверка\Tor\Data</em> </p> <p> If I run tor.exe -f torrc, the output as follows <em>[warn] Error creating directory C:\Проверка\Tor\Data: No such file or directory [warn] Failed to parse/validate config: Couldn't create private data directory "C:\Проверка\Tor\Data"</em> </p> <p> Now let’s replace UTF8 encoded torrc with <a class="ext-link" href=""><span class="icon">​</span>ANSI encoded torrc</a> and Tor works as expected. </p> Results #26137: Integrate AS-aware circuit selection Sun, 20 May 2018 01:58:56 GMT cypherpunks <p> The "ASToria" Tor client has been available since 2015, but I haven't seen any analysis of it from Tor Project or any plans to integrate any of the ideas. The general idea behind ASToria is to improve path selection to minimize the risk of AS-level traffic correlation. It is effectively an enhanced version of Tor's current naïve path-selection behavior which simply involves avoiding circuits with relays that share too small of a subnet. This is a similar proposal to <a class="new ticket" href="" title="#10221: enhancement: Implement BGP malicious route checks before publishing descriptor in ... (new)">#10221</a>, which was created before this paper was published. </p> <p> Tor should integrate AS-aware circuit selection (whether by including the ASToria code or creating a bespoke solution), or at the very least integrate AS-aware circuit measurement to make potential transition easier in the future. Additionally, this change would require no modifications of the Tor protocol and would be completely backwards-compatible with the network. From the paper's abstract: </p> <blockquote class="citation"> <p> We find that up to 40% of all circuits created by Tor are vulnerable to attacks by traffic correlation from Autonomous System (AS)-level adversaries, 42% from colluding AS-level adversaries, and 85% from state-level adversaries. In addition, we find that in some regions (notably, China and Iran) there exist many cases where over 95% of all possible circuits are vulnerable to correlation attacks, emphasizing the need for AS-aware relay-selection. </p> <p> Astoria reduces the number of vulnerable circuits to 2% against AS-level adversaries, under 5% against colluding AS-level adversaries, and 25% against state-level adversaries. In addition, Astoria load balances across the Tor network so as to not overload any set of relays. </p> </blockquote> <p> Key points: </p> <ul><li>The code has already been written and just needs a cleanup and some review. </li><li>Load balancing is done to prevent individual relays from being overloaded. </li><li>No changes to the protocol are needed, making this fully backwards-compatible. </li><li>AS-level traffic analysis risk is reduced from 40% to 2% for any given circuit. </li></ul><p> <a class="ext-link" href=""><span class="icon">​</span></a> <a class="ext-link" href=""><span class="icon">​</span></a> </p> Results #26168: Rename HSDir consensus flag to OnionDir Tue, 22 May 2018 18:03:43 GMT arma <p> Over time, nobody is going to know what an HSDir is. Eventually we will want to use a more understandable name. I propose OnionDir. </p> <p> Step 1: Make clients able to parse the OnionDir flag, and they just treat it as a synonym for HSDir. </p> <p> Step 2: Wait a long time until all clients from before step 1 are gone. </p> <p> Step 3: Have dir auths start saying OnionDir instead of HSDir. </p> <p> (In the above plan, step 2 could take years. But I think it's still the simplest plan. The only real risk is if we somehow screw up with step 1, and don't notice the screw-up until we try step 3.) </p> Results #26240: Check Maxmind GeoIPLocation Database before distributing Wed, 30 May 2018 13:57:51 GMT jvsg <p> Currently we're consuming Maxmind's (a company registered in the U.S) GeoIPLocation Database in Tor. Not just this goes against the principles of modern privacy that advocates non-reliance on any single organisation/product, but comes with some serious threats. A powerful adversary can impose it's control over Maxmind's database. This can be used to attack tor in a variety of ways: </p> <ol><li>The Tor Network is constantly monitored for any suspicious spike in nodes, as it may be an indication of an oncoming/undergoing sybil attack. A powerful adversary can coerce Maxmind to map some specific IP address blocks to random countries. This may lead to people/scripts monitoring the network to not feel suspicious about this event, and would result in the adversary staying under the radar. </li></ol><ol start="2"><li>A large percentage of people don't want the exit of their circuits to be located in certain countries where the communication is under surveillance. The powerful adversary knows this as well. Users generally add a line in their config that allows them to not form a circuit through nodes located in those locations. To overcome this, the adversary can coerce Maxmind to alter it's database to map some particular IP's to locations which the user thinks are havens of free speech. </li></ol><p> <strong>Solution</strong> </p> <p> I propose a system where instead of directly distributed maxmind's db to the users, we first check it for any anomalies. </p> <p> This is how it works: </p> <ol><li>The Dir Authorities fetch the GeoIPLocation DBs from all the companies (including Maxmind) located in distinct countries. </li></ol><ol start="2"><li>Tor Nodes' location (from maxmind) are checked against other DBs as well. The location which appears in a majority of DB is considered authentic. </li></ol><ol start="3"><li>All the Dir Authorities perform the above two steps periodically and independently of each other, and try to reach on a consensus. </li></ol><ol start="4"><li>This DB is then distributed to the users along with any modifications from step 2. </li></ol><p> <strong>What if locations differ in all/most of the DBs?</strong> </p> <p> A case might arise where the locations for an IP differ in all/most of DBs, because these locations are just guesses and hence can be erroneous. However IMO, </p> <ol><li>Most of the nodes are either run from large datacentres, which in all cases have the right GeoLocation mapped to their IP addr range. </li></ol><ol start="2"><li>Even if the nodes are run from home on a static IP, usually the whois records are well kept, which help companies such as maxmind fetch data for their DBs. </li></ol><p> So, false positives would be very few. Even if there are some, we can ban the IP addr from participating in the network until the issue is resolved. Or we can be a little liberal and allow them to participate given that there isnt a spike in number of nodes recently. </p> <p> <strong>What about DB licenses?</strong> </p> <p> Only the Dir Auths have to pay to get DBs in addition to the freely available maxmind DB. The DB that we will distribute to the users would just be maxmind (with some possible modifications) </p> Results #26646: add support for multiple OutboundBindAddressExit IP(ranges) Wed, 04 Jul 2018 23:17:09 GMT nusenu <p> tor has support for dedicated outbound IP addresses for on exit relays via OutboundBindAddressExit. This parameter supports only a single IPv4 and a single IPv6 address. </p> <p> I propose to add an extension of this feature to support IPv4 and IPv6 ranges/prefixes. </p> <p> The idea is to assign an IP address to each tor circuit. The exit IP address must never change during the lifetime of the circuit. </p> <p> Exit IP addresses would be randomly assigned to circuits. Once the exit runs out of IPs it cycles through his pool of IPs again. With IPv6 address space availability this can take a long time with IPv4 it will be limited. </p> <p> This aims to reduce the negative impact of few "bad" users on many "good" users since they will not share the same IP address on the exit. </p> <p> This might also have some negative? side effect since it demultiplexes tor clients to multiple source IPs on the exit and an external observer (not running the exit itself) can tell clients apart by looking at source IPs. </p> <p> Instead of doing it on the circuit level you could do it based on time. Change the exit IP every 5 minutes (but do _not_ change the exit IPs for _existing_ circuits even if they live longer than 5 minutes). </p> <p> <a class="ext-link" href=""><span class="icon">​</span></a> </p> Results #26691: add 'working DNS' to the list of mandatory requirements for the 'exit' flag Mon, 09 Jul 2018 11:13:07 GMT nusenu <p> current requirements for the exit flag as per the spec: </p> <p> <a class="ext-link" href=""><span class="icon">​</span></a> </p> <blockquote class="citation"> <blockquote> <p> "Exit" -- A router is called an 'Exit' iff it allows exits to at </p> </blockquote> <blockquote> <p> least one /8 address space on each of ports 80 and 443. (Up until Tor version 0.3.2, the flag was assigned if relays exit to at least two of the ports 80, 443, and 6667.) </p> </blockquote> </blockquote> <p> Recently the requirements for the exit flag have been changed to make 80+443 mandatory because exits only allowing 80 OR 443 would introduce to much breakage, the same is true for exits not able to resolve any DNS requests, their usefulness as an exit is limited. </p> <p> <a class="ext-link" href=""><span class="icon">​</span></a> </p> <blockquote class="citation"> <blockquote> <p> "Exit" if the router is more <strong>useful</strong> for building general-purpose exit circuits than for relay circuits. </p> </blockquote> </blockquote> <p> So lets add the DNS requirement to the list of requirements for the exit flag. </p> <p> The requirement should be automatically verified by dir auths by attempting DNS resolution for each exit candidate up to 5 times a day. If more than 2 resolution attempts fail the 'working DNS' requirement is not met. After 3 successful attempts no further attempts are necessary for that day. </p> <p> Relays loosing the exit flag have a chance to regain it after being tested the next day again. </p> <p> <a class="ext-link" href=""><span class="icon">​</span></a> </p> Results #26778: Enable supporting multiple bridge authorities Fri, 13 Jul 2018 03:49:58 GMT chelseakomlo <p> BridgeDB already supports multiple bridge authorities. To add an additional bridge authority, it needs to be added to the bridgedb config in the BRIDGE_AUTHORITY_DIRECTORIES list. </p> <p> A bridge should be able to select a bridge authority from the list of authorities, where multiple bridge authorities can be represented, and try one at a time until it is able to successfully upload its descriptor. </p> <p> Note: This feature might already exist in tor, so auditing the code to check first would be useful. </p> Results #27435: Poland, PLAY operator and OBFS4 Tue, 04 Sep 2018 10:41:20 GMT VeryVeryBadUser <p> The OBFS4 looks to be blocked by PLAY in Poland. </p> <p> The router was restarted, the computer with Tor Browser was restarted. It doesn't help me. </p> <p> I can connect via Firefox to other web pages but not via Tor. </p> <p> [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections. [NOTICE] Opening Socks listener on [NOTICE] Ignoring directory request, since no bridge nodes are available yet. [NOTICE] Bootstrapped 5%: Connecting to directory server [NOTICE] Bootstrapped 10%: Finishing handshake with directory server [NOTICE] Bridge 'Lisbeth' has both an IPv4 and an IPv6 address. Will prefer using its IPv6 address ([2001:470:b381:bfff:216:3eff:fe23:d6c3]:443) based on the configured Bridge address. [NOTICE] Bridge 'Lisbeth' has both an IPv4 and an IPv6 address. Will prefer using its IPv4 address ( based on the configured Bridge address. [NOTICE] Bridge 'NX01' has both an IPv4 and an IPv6 address. Will prefer using its IPv4 address ( based on the configured Bridge address. [NOTICE] Bootstrapped 15%: Establishing an encrypted directory connection [NOTICE] Bootstrapped 20%: Asking for networkstatus consensus [NOTICE] new bridge descriptor 'noisebridge01' (fresh): [removed] at [WARN] Proxy Client: unable to connect to ("general SOCKS server failure") [WARN] Proxy Client: unable to connect to ("general SOCKS server failure") [WARN] Proxy Client: unable to connect to ("general SOCKS server failure") 9[WARN] Proxy Client: unable to connect to ("general SOCKS server failure") [WARN] Proxy Client: unable to connect to ("general SOCKS server failure") [WARN] Proxy Client: unable to connect to ("general SOCKS server failure") [NOTICE] Ignoring directory request, since no bridge nodes are available yet. [NOTICE] Bootstrapped 25%: Loading networkstatus consensus [NOTICE] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6360/6377). [NOTICE] Ignoring directory request, since no bridge nodes are available yet. [NOTICE] Ignoring directory request, since no bridge nodes are available yet. [NOTICE] Bootstrapped 50%: Loading relay descriptors </p> <p> After last notice there is no progress. Version: 7.5.6 (based on Mozilla Firefox 52.9.0) (32-bit) Maybe security / privacy problem. </p> Results #27491: Prefer IPv4 or IPv6 based on the number of failures Wed, 05 Sep 2018 23:23:34 GMT neel <p> Suggested by teor at <a class="assigned ticket" href="" title="#17835: enhancement: Make ClientPreferIPv6ORPort smarter (assigned)">#17835</a>: </p> <blockquote class="citation"> <ol start="3"><li>If the machine instantly fails IPv4 or IPv6 connections, stop those connections for a while </li><li>When there are a lot more IPv4 than IPv6 failures, don't try IPv4 as much </li><li>When there are a lot more IPv6 than IPv4 failures, don't try IPv6 as much </li><li>After a while, forget old failures </li></ol></blockquote> Results #27790: sbws: design and construct bias curves Wed, 19 Sep 2018 23:18:32 GMT teor <p> From <a href=""></a> </p> <p> The essence of Torflow's active approach is that observed bandwidth capacity at each relay is the key measurement and that it can only be reliably determined locally but that it requires adjustment, principally to account for used vs unused capacity and secondly the relative performance of each node in the asymmetric domain of internet traffic routing. IMO indisputably correct. The Peerflow paper tacitly recognizes this. </p> <p> However the simple linear adjustment algorithm cannot be fine-tuned for better results across the vast range of relay performance. IIRC polynomial equations of sufficient order can describe curves of near arbitrary complexity and therefore parameterized polynomials can be used interactively, in a gradual empirical search, to describe an improving set of adjustment biases for applying scanner measurements to advertised bandwidths. This link illustrates the general principal, though the idea is to design and construct bias curves with polynomials rather then to fit them somehow. </p> <p> ​<a class="ext-link" href=""><span class="icon">​</span></a> </p> Results #27906: PrivCount noise specification Sat, 29 Sep 2018 20:48:21 GMT teor <p> Let's write a spec for PrivCount noise: </p> <ul><li>how noise is determined for each statistic </li><li>how much noise each relay adds </li><li>how to interpret the final result </li><li>how to avoid obvious pitfalls </li></ul> Results #27907: PrivCount config and version spec Sat, 29 Sep 2018 20:50:11 GMT teor <p> Specify how: </p> <ul><li>PrivCount is configured </li><li>How we transition between PrivCount versions </li></ul> Results #28509: Limit relay bandwidth self-tests based on RelayBandwidthRate, not BandwidthRate Mon, 19 Nov 2018 02:24:37 GMT teor <p> Discovered while working on <a class="needs_information ticket" href="" title="#22453: defect: Relays should regularly do a larger bandwidth self-test (needs_information)">#22453</a>. </p> <p> This is a bug on, where RelayBandwidthRate was introduced. </p> Results #28510: When relays reset bandwidth tests, the test waits until the next directory document is received Mon, 19 Nov 2018 03:16:42 GMT teor <p> When Tor is doing its first ORPort reachability test, it initiates one testing circuit after the first successful circuit, then one testing circuit per second until the ORPort is found reachable. Then it gives up after 20 minutes. (1200 circuits is too many.) </p> <p> When tor receives any descriptor or consensus, it does another ORPort reachability test, and initiates a testing circuit. </p> <p> When a testing circuit opens, and there aren't enough testing circuits to test bandwidth, then tor initiates another testing circuit. </p> <p> But no testing circuits are opened after the bandwidth tests are reset. </p> <p> So tor waits for the next directory document before doing a bandwidth test. We should just lunacy the tests straight away. </p> <p> This is a bug on the original feature in commit 769f9201a68387c2cdf03e1efd28399c93bb2bdf in </p> Results