- tor-dev - lists.torproject.org

[GSoC] CONIKS for Tor Messenger - gsoc.hello()
by Huy Vu Quoc 23 Apr '16

23 Apr '16

Hi everyone! I'm Huy, a senior year undergraduate from HUST-Vietnam, who is starting to work with CONIKS for Tor Messenger as a part of Google Summer of Code. This project aims at implementing a CONIKS server for key verification and a CONIKS client which integrates with the Tor Messenger client. The details of CONIKS system is described in [0]. My mentors are Marcela and Arlo. I will start with this project soon, may be on the first day of May and finish at the end of July. Currently, I am studying deeper about crypto primitives. After that, I think I will speed up with code base in the GitHub :) I will be on IRC as c633, in GitHub as c633. I will send bi-weekly status reports to this list, and also share it on my blog [1]. Cheers! Vu Huy — [0]: https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper… [1]: http://c633.net

1 0

[GSoC '16] Exitmap Improvements Project - Hello Tor!
by Mridul Malpotra 23 Apr '16

23 Apr '16

Hi everyone! Introduction: ----------------- I'm Mridul, a senior year undergraduate from IIIT-Delhi. I am really thrilled to have been selected in GSoC 2016 for the Exitmap improvements project! It's an amazing opportunity and I hope to contribute something substantial to the Tor community. My IRC handle is mtyamantau. Details: ------------ My primary and secondary mentor will be Dr. Philipp Winter (phw) and Damian Johnson (atagar) respectively. I'll be primarily active on #tor-dev on irc.oftc.net and on tor-dev(a)lists.torproject.org. About project: ------------------- The project is mainly focused around Exitmap improvements, with the three major aspects being implementing autonomous scanning, multiple user interaction in Tor Browser and a system for implementing automated data collection from multiple users[1]. My full proposal is linked below[2] for more information on this. I Project details: -------------------- Official start and end dates: 23rd May (Mon) to 29th August (Mon). For now, I plan to start reading and getting myself familiarized with the codebase before that. Also, I have still some uncertainty and questions in certain sub-tasks, which I hope to resolve with the Tor community. I will be sending bi-weekly project reports to tor-dev(a)lists.torproject.org. They will mainly be on the progress that I have made that highlight the work done in that duration. Cheers! Mridul (mtyamantau) [1] https://summerofcode.withgoogle.com/projects/?sp-page_size=48#6137867067719… [2] https://docs.google.com/document/d/1AqjH3AsBbfesJg36SZg1frPQsdpAnJmzH8k1-G6…

1 0

Questions about "Tor Messenger CONIKS integration"
by Go 21 Apr '16

21 Apr '16

Hi, CONIKS seems to be a very useful system. Just curious: do Tor messenger users need to hand out their real identities (facebook account, twitter account, etc.) to CONIKS servers? If so it seems dangerous to put all the identities in a centralized service. If the CONIKS servers have been compromised, will the attacker be able to figure out the social networking profiles of Tor messenger users? Thanks!

4 6

prop224: HSDir caches question with OOM
by David Goulet 21 Apr '16

21 Apr '16

Hi! (For the following, I'm only talking about HS directory.) Here is my conundrum. I was working on plugging the new cache for proposal 224 into our OOM. I stumbled upon a fun problem. We plan to have both current and new HS protocol in parallel. This means two caches for both version 2 (current) and 3 (prop224). So far so good. However, here is the problem. Now, our OOM handlers is called in: cell_queues_check_size(). The heuristic is basically: /* If we're spending over 20% of the memory limit on hidden service * descriptors, free them until we're down to 10%. */ Considering we have _two_ caches now, we somehow have to cleanup both of them "evenly" that is if we have to remove 20kb we either remove 10kb on each (if possible) or we actually clean them by entry expiry time instead regardless of which version. I think the latter is what we want but then it complicates things a bit since both cache contains _different_ data struct. and indexed with different keys (DIGEST vs DIGEST256). One option here is to go over all entries in both cache, create temporary objects and put them in a sorted list (by expiry time). Those "temp object" would contain something like: 1) cache version, 2) expiry time and 3) index key. Once done, we go over that list and delete entries until we reach our number of bytes we need to remove. This could work since we would do that when we are at 20% memory but still it requires allocating some small objects to _clear_ our memory... Someone has maybe something _better_ to propose? :) (keep in mind that minimal change to the current HS code is preferable. I know that unifying both caches somehow would help but that's lots more work! and the new cache for prop224 will be able to support versionning for which our current one doesn't, it's baked for v2.) I'm asking because this will require some refactoring for which I want to make sure we are in agreement on how to proceed and it doesn't end up not the right solution. Basically my goal is to move the OOM handler for both v2 and v3 to one single function called hs_cache_handle_oom() and from which we'll do the gymnastic describe above. We'll stop calling rend_cache_clean_v2_descs_as_dir() explicitely after that in cell_queues_check_size(). Cheers! David

5 8

Comments on proposal 224 updates
by Nick Mathewson 19 Apr '16

19 Apr '16

I'm behind on this! But let me comment on the stuff that got merged recently. "prop224: Remove the MAINT_INTRO feature." "prop224: Clarify backwards compatibility sections slightly." "prop224: Clarify use of shared random values." "prop224: Fix undefined variables in the ntor section." Looks ok. "prop224: Add missing key expansion section for rendezvous crypto." KDF-Tor is a legacy algorithm, and we want to get away from SHA1. We don't use KDF-Tor with NTOR. Let's kill it for new use. I'd suggest HKDF-SHA256 or SHAKE, both of which we have implemented already. "prop224: In cells, replace TYPE/LEN/KEY with just TYPE/KEY." I'm not sure about this change. If we ever add a third key type, all of the cells will be unparseable. "prop224: Various improvements." There's no point in using HKDF with SHAKE; we should just use SHAKE as the KDF.

2 2

Request for feedback/victims: cfc-0.0.3
by Yawning Angel 18 Apr '16

18 Apr '16

Thanks for the feedback/bug reports so far. [ PEOPLE THAT HAVE BIG SCARY ADVERSARIES IN THEIR THREAT MODEL STILL SHOULD NOT USE THIS. ] This is the third release of the archive.is based captcha-be-gone extension for Tor Browser. Relative to 0.0.2, this has a minor bugfix that fixes URLs with trendy "@" signs in odd places by replacing the URI/URL parser (Eg: "https://medium.com/@blahblahblah"). I've been busy with other things so this was the only change, but medium.com is popular enough that it deserved a new XPI. Source: https://git.schwanenlied.me/yawning/cfc XPI: https://people.torproject.org/~yawning/volatile/cfc-20160418/ Regards, -- Yawning Angel

1 0

Re: [tor-dev] Latest state of the guard algorithm proposal (prop259) (April 2016)
by Fan Jiang 18 Apr '16

18 Apr '16

Hi, the last mail got rejected by tor-dev, to keep track of this thread, sending again, sorry for disturbing, > On Fri, Apr 15, 2016 at 5:37 AM, George Kadianakis <desnacked(a)riseup.net> > wrote: > >> Fan Jiang <fanjiang(a)thoughtworks.com> writes: >> >> > [ text/plain ] >> > Thanks for the insights. >> > >> > >> >> >> It seems like the latest version of prop259 was posted a few weeks >> ago: >> >> >> >> >> https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html >> >> >> >> >> > <snip> >> >> > >> >> >> A few things: >> >> >> >> >> >> a) Are there still proposal design decisions that need to be taken >> and >> >> we >> >> >> are >> >> >> unclear on? I admit I'm a bit lost in the latest [tor-dev] >> thread, so >> >> >> maybe >> >> >> I can be of help somehow here? >> >> >> >> >> >> There are still some issues, like for_directory may leads to >> maintain >> >> two >> >> > sets of >> >> > sampled_set independently, which is not yet defined clearly in >> proposal. >> >> > >> >> >> >> Hm, how come this is happening? >> >> >> >> I would think that for_directory would now be just another filter >> (like the >> >> ipv6 one etc.) that can be applied on top of the sampled list. >> >> >> > The problem here is for_directory is a parameter of function call, that >> > means we can't do filter >> > before the call happens. Now the filter action only happens at START >> stage. >> > Maybe do a check before we return the selected guard (if not valid, then >> > continue picking new one) >> > can be a solution. >> > >> >> Hello, >> >> hm, that's an interesting problem... >> >> So we learn whether a circuit is for_directory when >> choose_random_entry_prop259() is called, but at that point the prop259 >> algorithm has already STARTed and its filtering parameters have been >> determined? >> >> So if some part of tor calls choose_random_entry_prop259() quickly twice, >> first >> with for_directory set, and the second time with for_directory unset, the >> guard >> algorithm will proceed in both cases with for_directory being set? >> Because the >> context has been set in the first call to choose_random_entry_prop259()? >> >> This seems like a problem to me, and I'm not sure how to solve it well... >> >> One way could be to use the 'cpath_build_state_t *state' in >> choose_random_entry_prop259() to be able to understand whether each call >> is >> about a different circuit or not. Then you could start a separate >> algorithm >> invocation (so new START) for each new circuit you see. >> >> But then I'm not sure how to do this without each separate algorithm call >> wrecking up the sampled_guards and used_guards lists... In the dev >> meeting in >> Valencia, we discussed with Ola and Reinaldo about using locking and >> blocking >> for this, but I'm not sure how much that would impact the performance... >> >> Do you guys have any plans here? >> >> We can have two pending_guard one for directory, one for any usage(which > will be picked by the NEXT algo, so they can be same node), > and they can be checked with directory flag before return. > Locking may not work because this algo should at least return sth before > it continues to another one, saying Dir and non-Dir are now in main loop, > Or if you have any ideas please let me know. > >> --- >> >> >> >> BTW, I also noticed that you have various global structures in prop259.c, >> like >> entry_guard_selection and used_guards and sampled_guards. I see you've >> been >> working hard on un-globalizing the entry_guards list, but I'm not sure if >> there >> is value to that if all those other structures are global. Do you have >> plans >> for making those structures local to each specific algorithm instance? >> >> I've been working on moving these other structures into a > guard_selection_t, > and hope it can help to make this algo instanceable. > > >> Cheers! >> >

1 0

putting 'Nuke MyFamily' to vote (#6676)
by nusenu 17 Apr '16

17 Apr '16

One year after my last thread on that topic [0] I'd like to move forward on the question whether tor should have a MyFamily functionality or not, because it seems to be a blocker of prop242 (#5565) and it is clear that the current MyFamily design is not practical for many - given the amount of improper or undeclared families [6]. prop 242 is also relevant in the context of Sibyls because if MyFamily becomes trivially easy for everyone to configure one might even start to use it to tell "good" and "bad" apart. If you have an opinion on that topic please reply. I tried to collect opinions on that from past threads and trac. When Nick asked "So, what do we think?" last year only people in favor of keeping it replied. In favor of keeping it: Nick [1] Teor [2] Virgil [3] Griffin [4] Moritz [5] In favor of nuking MyFamily: rransom anyone? Please speak up. Tools that use/display/process/depend on MyFamily: - tor-roster.org - onionoo - atlas - others? Can we close #6676 if no one is in favor of removing MyFamily? https://trac.torproject.org/projects/tor/ticket/6676 [0] https://lists.torproject.org/pipermail/tor-dev/2015-March/008516.html [1] https://lists.torproject.org/pipermail/tor-dev/2015-March/008517.html [2] https://lists.torproject.org/pipermail/tor-dev/2015-March/008531.html [3] https://lists.torproject.org/pipermail/tor-dev/2015-March/008527.html [4] https://lists.torproject.org/pipermail/tor-dev/2015-March/008529.html [5] https://trac.torproject.org/projects/tor/ticket/6676#comment:8 [6] https://raw.githubusercontent.com/nusenu/tor-network-observations/master/to… https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan…

3 3

Add me
by Ruth Watts 17 Apr '16

17 Apr '16

1 0

Re: [tor-dev] Latest state of the guard algorithm proposal (prop259) (April 2016)
by George Kadianakis 15 Apr '16

15 Apr '16

Fan Jiang <fanjiang(a)thoughtworks.com> writes: > [ text/plain ] > Thanks for the insights. > > >> >> It seems like the latest version of prop259 was posted a few weeks ago: >> >> >> https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html >> >> >> > <snip> >> > >> >> A few things: >> >> >> >> a) Are there still proposal design decisions that need to be taken and >> we >> >> are >> >> unclear on? I admit I'm a bit lost in the latest [tor-dev] thread, so >> >> maybe >> >> I can be of help somehow here? >> >> >> >> There are still some issues, like for_directory may leads to maintain >> two >> > sets of >> > sampled_set independently, which is not yet defined clearly in proposal. >> > >> >> Hm, how come this is happening? >> >> I would think that for_directory would now be just another filter (like the >> ipv6 one etc.) that can be applied on top of the sampled list. >> > The problem here is for_directory is a parameter of function call, that > means we can't do filter > before the call happens. Now the filter action only happens at START stage. > Maybe do a check before we return the selected guard (if not valid, then > continue picking new one) > can be a solution. > Hello, hm, that's an interesting problem... So we learn whether a circuit is for_directory when choose_random_entry_prop259() is called, but at that point the prop259 algorithm has already STARTed and its filtering parameters have been determined? So if some part of tor calls choose_random_entry_prop259() quickly twice, first with for_directory set, and the second time with for_directory unset, the guard algorithm will proceed in both cases with for_directory being set? Because the context has been set in the first call to choose_random_entry_prop259()? This seems like a problem to me, and I'm not sure how to solve it well... One way could be to use the 'cpath_build_state_t *state' in choose_random_entry_prop259() to be able to understand whether each call is about a different circuit or not. Then you could start a separate algorithm invocation (so new START) for each new circuit you see. But then I'm not sure how to do this without each separate algorithm call wrecking up the sampled_guards and used_guards lists... In the dev meeting in Valencia, we discussed with Ola and Reinaldo about using locking and blocking for this, but I'm not sure how much that would impact the performance... Do you guys have any plans here? --- BTW, I also noticed that you have various global structures in prop259.c, like entry_guard_selection and used_guards and sampled_guards. I see you've been working hard on un-globalizing the entry_guards list, but I'm not sure if there is value to that if all those other structures are global. Do you have plans for making those structures local to each specific algorithm instance? Cheers!

1 0

Proposal: Tor with collective signatures
by Nicolas Gailly 14 Apr '16

14 Apr '16

Hi Tor devs, I'm part of the DeDiS team at EPFL and we are working on Cothority, which is a generic framework for Collective Authority. We worked on a proposal to apply Collective Signatures (CoSi) to D.A. consensus document in the Tor ecosystem. While not adding too much complexity to the Tor ecosystem, we believe it can bring more transparency, accountability and security regarding the consensus documents. There is also a section regarding the emergency procedure that D.A.s operators are under when a relay is detected as malicious, and how CoSi could help in this process. I hope you will find it interesting and welcome all the feedbacks / opinions you can have! Thanks in advance, Nicolas <-------- tor_cosi.txt ---------------> Filename: tor_cosi.txt Title: Tor CoSi Author: Nicolas GAILLY Created: 09.03.2016 Status: draft 0. Introduction This document describes how to provide and use a decentralized witness cosigning mechanism in order to gain proactive transparency and public accountability for the Tor consensus documents. Directory Authorities (DA) send their document to this set of witnesses and embed the signature within the document. Tor relays and clients can choose to refuse a consensus document if it has not been accepted and signed by a threshold of witnesses. 1. Overview A weakness of the current DA system is that if any 5 of the 9 DAs’ keys are stolen or coerced they could be used to sign fake directories that the attacker might use secretly in another part of the world to compromise Tor clients in the attacker’s domain. We propose to address this class of attacks by incorporating decentralized witness cosigning (CoSi) into the directory signing process, which ensures that any consensus document must be not only signed by appropriate DAs, but also publicly witnessed, signed and logged by a larger group of servers acting as witnesses, before clients will accept the directory. A Tor relay or client expects to receive an additional "CoSi" signature alongside the consensus document. They verify if the signature is correct and whether a sufficient number of witnesses attested that the consensus document is valid or not. The Tor project would fix such a threshold in the default configuration but any user or relay is free to adjust this value to its own need. In order to verify the signature, they need to have the individuals public keys of all the witnesses beforehand. This "CoSi certificate" can be embedded in the software in the same way certificate pinning does. 2. Motivation Tor's DAs are comprised of 9 servers (and one extra for the bridges): four of them are in the US and 5 of them are in the EU. Attacking these central and vital points of the Tor network is clearly within the reach of state level adversaries if they were to collaborate. Recent stories about surveillance show that such a collaboration is already happening. For example, let's imagine a plausible situation where a state-level attacker secretly coerces and/or steals the private keys of 5 of the 9 DAs, takes them back to the Republic of Tyrannia where they control the ISPs and the country’s Internet connectivity to the rest of the world. The government embeds those keys in their “Great Firewall” type devices, and uses them to secretly MITM attack targeted Tor users within Tyrannia by giving them correctly-signed but completely false views of the Tor directory in which all of the available relays are run by the Tyrannian authorities. Since this attack does not attack the consensus documents that the legitimate DAs are regularly broadcasting to the rest of the world, neither the Tor project nor anyone else outside of Tyrannia will have the opportunity to see or become aware of the fake consensus documents, and not many people even inside Tyrannia might have the opportunity to detect the attack if it is carefully targeted against the small number of suspected activists and journalists the government does not like. The main goal of CoSi applied in Tor should be to ensure consensus document transparency: that is, ensure the property that any consensus document that any Tor client anywhere will accept has been observed and logged by a significant number of parties throughout the world, so that any misuse of a quorum of 5 DA keys anywhere will be quickly detectable (soon, if not necessarily during the signing process itself). 4. Design The first part will talk more about the architecture of a "CoSi" system and the second part will go into more detail about how such a system can be integrated in Tor. 4.1 Simplified Architecture The designated leader arranges all the witnesses in a tree. The public keys of each participants are aggregated to form an aggregate public key. The tree is only there for performance reasons and can be reconfigured at any point in time without affecting security (the latest experiments showed that we could run up to 8000 nodes with a 2 second delay for generating a signature). Once the tree is constructed, its "certificate" represents the aggregate public key and the hash of a Merkle tree containing all the individual public keys. This Merkle tree is needed in case some nodes are failing, so the verification of the signature can still be executed without any change by the client. These issues are covered later in the “Handling Exceptions” part. In a nutshell, a signature round broadcasts the message down the tree, and to each participant. At the end of a signature round, the client have a simple Schnorr signature to verify. Besides contributing to the signing, each witness can and should perform any readily feasible syntactic and semantic correctness checks on the leader’s proposed statements before signing off on them. They can / should probably publish logs of the statements they witness or simply make available a public mirror of everything that its tree roster has been asked to sign. An important point is that each signature is chained with the last one, so each witness also knows the full set of witnesses that accepted the last signature and whether the leader is acting malicious or not. 4.2 CoSi in Tor 4.2.1 Setup The CoSi system can be constructed using independent, diverse and decentralized witnesses. In the context of Tor, one could imagine to include the DA themselves (one could be the leader), and some of the best relays in term of availability and reputation. Due to the decentralized nature of CoSi, this system can also includes external organizations that are favorable and trusted by Tor (e.g. EFF). Another criteria for the tree construction includes the latency between witnesses. One can collect information about the communication latencies between the witnesses and construct a shortest-path spanning tree using this data in order to reduce the global latency of the system. One important property is that the system is under a closed membership policy. The certificate of the CoSi system will have to be embedded in the Tor code in a similar way as for certificate pinning. One obvious way to do it is to setup the set of witnesses as being the DAs and the set of (future) “backup directory servers” as their public keys will already be hard-coded into the Tor client software. That way the deployment cost is drastically reduced as software will already have the keys to verify a CoSi signature. 4.2.2 Operations Once the tree is setup and each one knows about it (have the certificate), then the signature process happens for each consensus document. The CoSi protocol produces a collective signature in response to the initiation of the protocol by a leader. This signature is then included in the consensus document so clients don't have to request it from another party. One issue for discussion is who should initiate CoSi protocol rounds and at what times. For example, each of the 9 DAs (or whatever subset is online) could independently initiate CoSi rounds on each directory consensus event, producing up to nine separate, redundant collective signatures on each directory consensus. Alternatively, the common case might be for one of the 9 DAs to be the CoSi initiator at a given time, with a round-robin leader-change mechanism ensuring that another leader takes over if the prior one becomes unavailable. A related issue for discussion is whether it could be problematic if there are two or more distinct collective signatures for a given directory consensus, and whether it is a problem if distinct subsets of 5 DAs might (perhaps accidentally) produce multiple slightly different, though valid and legitimately-signed, consensus documents at about the same time. In other words, does Tor directory consensus “need” strong consistency with a single serialized timeline, as Byzantine consensus protocols are intended to provide - or is weak consistency with occasional cases of multiple concurrent consensus documents and/or collective signatures acceptable? 4.2.3 Integration First of all, integrating CoSi would *not* immediately affect the fundamental structure or function of the current DAs: there could still be 9 of them, of which any 5 can authorize the release of a new consensus document, as they do now. Secondly, CoSi would not necessarily change anything about how the 9 DAs decide on how to compute these directory consensus documents; e.g., it would not prevent the DAs from working together to block the inclusion of (or assignment of bandwidth-weight to) relays that might be perceived by the DAs as doing bad things. Finally, full backward compatibility with old Tor clients and relay software may be maintained by treating the new CoSi-generated collective signature as just an additional signature that gets attached to and distributed with consensus documents. It may be treated as a special “10th virtual DA” that does not help authorize decisions but just publicly witnesses the output of the regular 9 DAs. Old client and relay software can simply ignore that new collective signature, whereas new software might look for it and over time gradually increase the threshold number of witnesses it expects to see. 4.3 Optional: Break-the-glass Emergency Directory Adjustments In case of emergency, the delay caused by having to coordinate among 5 DAs in order to make anything happen (i.e. excluding a set of malicious nodes) can be problematic. This section proposes a mechanism in which the CoSi witnesses can accept and witness not just “full consensus” documents (signed by 5 DAs), but can also accept “emergency adjustments”, which are highly-constrained deltas (diffs) to an existing full consensus document signed by a smaller threshold of DAs, e.g., 2 or even just 1. For example, the CoSi witness cosigning rules might require that an emergency directory-adjustment must: - be a diff against a “fresh”, recent full consensus document (perhaps *the* most recent one), - can make no modifications to the full consensus other than some pre-defined operations such as decreasing bandwidth weights assigned to relays, - cannot affect the directory-wide total bandwidth weight by more than X% (e.g., 1% or .1%). These suggestions are just a few imaginable rules to get the idea across; the “right” rules would of course need much more discussion. This way, if one or two DAs discovers or even strongly suspects an attack of some kind, they can take emergency countermeasures against the attack and be able to roll them out to clients quickly without having to get a full 5 DAs out of bed - but because the delta-consensus is still witness-cosigned automatically by (perhaps) all the DAs and a number of additional trusted relays, we get the strong accountability provision that the use of such a “break-the-glass” emergency provision will immediately become known to the other DAs as soon as they do get out of bed. Such a break-the-glass emergency adjustment mechanism could be designed, if desired, so that ordinary clients and relays cannot immediately tell the difference between a directory consensus produced via the normal threshold of 5 DAs and one that was produced as a delta via the emergency adjustment mechanism. Only the witness cosigners would necessarily need to know which collectively-signed directories were authorized via the full consensus procedure or via a break-the-glass adjustment. So if it’s important to keep it secret from the general public the precise reason for a particular directory update, that can be accommodated. Only the more-trusted group of witness cosigners (and obviously all the DAs themselves) would necessarily know the precise origin and administrative justification of a given directory update. With even fancier crypto, even the witnesses would not necessarily need to know, but that’s beyond the scope of this proposal and its desirability may be questionable at any rate. 4. Security implications 4.1 Cons Since the structure is a tree, if any node fails, there must be some failover mechanisms to restore connectivity between the children of the failed node and the rest of the tree. Since the DA reach consensus every hour [1], with the help of the gossiping network, the availability problem is not an issue. 4.2 Benefits Technically, it is quite easy to implement witness cosigning if the group of witnesses is small. If we want the group of witnesses to be large, however – and we do, to ensure that compromising transparency would require not just a few but hundreds or even thousands of witnesses to be colluding maliciously – then gathering hundreds or thousands of individual signatures could become painful and inefficient. Worse, every client would need to check all these signatures individually. The key technical contribution of our research is a distributed protocol that makes large, decentralized witness cosigning groups practical. This decentralized approach enables the security of the whole system to scale with the number of witnesses. Not only does this system dramatically increase the cost of successfully deploying an attack on the DA (the attacker would have to corrupt a large majority of the witnesses), it also decreases the incentive to launch such an attack because the threshold of witnesses that are required to sign the document for the signature to be accepted can be locally set on each client. 4.3 Differences between CoSi and Certificate Transparency Prior transparency mechanisms have two weaknesses. First they do not significantly increase the number of secret keys an attacker must control to compromise any client device, and client devices cannot even retroactively detect such compromise unless they can actively communicate with multiple well-known Internet servers. For example, even with Certificate Transparency, an attacker can forge an Extended Validation (EV) certificate for Chrome after compromising or coercing only three parties: one Certificate Authority (CA) and two log servers. Since many CAs and log servers are in US jurisdiction, such an attack is clearly within reach of the US government. If such an attack does occur, Certificate Transparency cannot detect it unless the victim device has a chance to communicate or gossip the fake certificate with other parties on the Internet – after it has already accepted and started using the fake digital certificate. In the case of Tor Transparency, the attack is harder because the attacker would have to compromise the three parties plus a majority of Directory Authorities but facing a state-level adversary the threat is still plausible. One way to increase the difficulty of the attack is to make sure the logs servers are scattered in different places of the world. Second, the attacker can still evade transparency by controlling the client’s Internet access paths. For example, a compromised Internet service provider (ISP) or corporate Internet gateway can defeat retroactive transparency mechanisms by persistently blocking a victim device’s access to transparency servers elsewhere on the Internet. Even if the user’s device is mobile, a state intelligence service such as China’s “Great Firewall” could defeat retroactive transparency mechanisms by persistently blocking connections from a targeted victim’s devices to external transparency servers, in the same way that China already blocks connections to many websites and Tor relays. Using CoSi requires the clients to have the list of public keys of all the witnesses embedded in the software, like certificate pinning. In order to reduce the size of this CoSi certificate, we embed the aggregated public key of all the witnesses and a hash representing the root of a Merkle tree containing the public key of all the witnesses. Using the certificate this way provides an universally-verifiable commitment to all the witnesses’ public keys, without the certificate actually containing them all. 5. Specifications 6. Compatibility 7. Implementation Implementation in Go is open source at: https://github.com/dedis/cothority 8. Performance 9. Acknowledgments This proposals has received some valuable feedback from Bryan Ford, Linus Gasser, Ismail Khoffi, Philipp Jovanovic, and Ludovic Barman. A. References [1] https://collector.torproject.org <-------------- END ----------------------->

1 0

Re: [tor-dev] Latest state of the guard algorithm proposal (prop259) (April 2016)
by George Kadianakis 14 Apr '16

14 Apr '16

Fan Jiang <fanjiang(a)thoughtworks.com> writes: > [ text/plain ] > Hi George, > > Thanks for following up, > We have been updating the prop259 actively in recent two weeks, > >> >> It seems like the latest version of prop259 was posted a few weeks ago: >> https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html >> >> My understanding is that since then a few things have changed particularly >> with >> regards to the dystopic heuristic, and the various filtering torrc options. >> More discussion happened in the mailing list, but we have not posted a >> newer version of the proposal yet: >> https://lists.torproject.org/pipermail/tor-dev/2016-April/010714.html >> >> > the newer version of prop259 is sort of feasible again. it's here > https://github.com/twstrike/torspec/blob/review/proposals/259-guard-selecti… > Ah great. Will read it and comment on it ASAP. I notice that the prop now contains many many implementation details (like variable names, etc.). Ideally, we should abstract those details and make them look more like a specification. > And, we have our fork of Tor *running* with new proposal: > https://github.com/twstrike/tor_for_patching/tree/prop259 > How is this going? Does it work as intended? Any graphs? I should find some time and run it myself soon. > > >> A few things: >> >> a) Are there still proposal design decisions that need to be taken and we >> are >> unclear on? I admit I'm a bit lost in the latest [tor-dev] thread, so >> maybe >> I can be of help somehow here? >> >> There are still some issues, like for_directory may leads to maintain two > sets of > sampled_set independently, which is not yet defined clearly in proposal. > Hm, how come this is happening? I would think that for_directory would now be just another filter (like the ipv6 one etc.) that can be applied on top of the sampled list. > <snip> > > c) Let me know if there are any open implementation questions that I could >> assist with. > > > About implementation, one problem is when we try to remove the global > *entry_guards*, > The following functions are still using the global list: > > we already get rid of these: > > //- update_node_guard_status (OK - called from *set_from_config and > // *parse_state. This is an optimization to set the using_as_guard flag.) > //- entry_guards_compute_status (OK - when a new consensus arrives) > //- log_entry_guards (OK - wont be used) > //- add_an_entry_guard (OK - wont be used) > //- entry_guard_register_connect_status (OK - wont be used) > //- entry_guards_set_from_config (OK - wont be used) > //- entry_guards_parse_state and entry_guards_update_state (OK - wont be > used) > //- choose_random_entry_impl (OK - wont be used) > > there are still some remaining: > > //- get_entry_guards() > //- num_live_entry_guards() > //- getinfo_helper_entry_guards() > //- entries_retry_helper() > //- any_bridge_supports_microdescriptors() // Don't quite understand this, > what's a microdescriptors? A microdescriptor is a new type of relay descriptor that is more compact. (well, it used to be new, but it's a few years old these days and most bridges support it afaik). They were introduced to reduce the download sizes of clients, because asking for thousands of normal descriptors required too much bandwidth. Microdescriptors include almost all the details of normal descriptors (like onion keys, etc.) but in a much more succinct format. That function checks if the bridge supports microdescriptors. If yes, it will ask it for its microdescriptor. Otherwise, it will just ask for the normal descriptor. (I'm actually not sure how that function gets away without checking the bridge version or something.) > //- any_bridge_descriptors_known() // Calling choose_random_entry to check > a bridge, which doesn't make sense. > Hah. I didn't know of that function either. That function seems to call choose_random_entry() just to check if bridges have been configured correctly and are ready to use. It doesn't actually use the return value of the function :) Basically, if that func returns not NULL, it means that at least one bridge is live and ready to be attempted. > > > Another issue is about finding a better way to handle configuration > changes, especially for EntryNodes, > UseBridges and ReachableAddresses. The treshould numbers like > N_PRIMARY_GUARDS should be different > in such cases. > Hmm, yes I have not thought how the primary guards heuristic would work when bridges are enabled. Why do you think the thresholds should be different? Thanks for the info. Will try to have feedback on the proposal tomorrow or early next week.

1 0

iObfs: obfs4proxy on iOS
by Mike Tigas 14 Apr '16

14 Apr '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [Cross-posted to guardian-dev and tor-dev.] Hey, friends. I suppose this serves as a project announcement of sorts, and also as a progress report regarding the current status of this thing. iObfs is an effort to build obfs4proxy for iOS and to also build out some techniques for actually making it usable within other Tor-enabled iOS apps. You may have heard me or n8fr8 discuss the idea at the dev meeting a few weeks ago. I'm not in love with the name I gave it (it's a placeholder that stuck around), but such is life. The repository is currently hosted at [1]. [1]: https://github.com/mtigas/iObfs The initial sprint is being supported by a small Guardian Project grant through mid-April. The high-level goals are to: 1) successfully cross-compile obfs4proxy for the iOS environment 2) "library-ify" it and link it into a proof-of-concept iOS app 3) figure out how to get it to work without "managed mode" 4) build out a process for maybe putting it into Onion Browser, iCepa[2], and other Tor iOS efforts [2]: https://github.com/iCepa I've got a bit of work regarding #1. I think I'm close to getting the binary running, thanks to the existence of the gomobile tools[3]. Using gomobile, you easily get[4] an "obfs4proxy.app" and (given a properly configured Xcode and iPhone) you can put it on a device. But it crashes right now because (I believe) the iOS SDK requires apps to declare some user interface (even if it's blank). So that's close, but my relative lack of experience with Go and the Go buildchain have made #1/#2 a bit slow-going. [3]: https://golang.org/x/mobile/cmd/gomobile [4]: https://github.com/mtigas/iObfs/blob/master/buildobfs4.sh This week, I also took the time to figure out how PT "managed mode" actually works and now have a good idea of how I'd get obfs4proxy to work in an environment where tor can't fork it as a subprocess. There were some conversations I had during the dev meeting where we thought I'd have to use the control port and manually build circuits or something crazy like that -- but it turns out that the solution is a lot simpler.[5] [5]: https://github.com/mtigas/iObfs/blob/master/notes/obfs4-nonmanaged.md This essentially solves #3, so the big barrier now is cross-compiling, "library-ifying", and linking -- rather than the software implementation bits. Anyway, that's where things are. Progress will surely ramp up a bit over the next few weeks. Comments welcome. Best, Mike Tigas @mtigas | https://mike.tig.as/ | 0xA993E7156E0E9923 -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJW9wKpAAoJEGQdTjqn+ftyos4IANK+jKe+mdU3IcDGGWp48QnT 34a8DCk4u17MhGnoiPuRVjyF4R380v6+O23lzDsXpDA3bhorBirn1fdkJpnvTsb1 IiS75Q3falq+TPZ5pYCnijFLE0sj0VphdHcZuoiHnn6n8HlYZ13ih9sfZTUg/4pa nxNGL83H62vpuR2voeLWPgfJi+QRVIJVa9zSOz8xE3nE70sGNhbWpWlTn12UbMvj f3QmclTPNAuLCXGANyEG1QkTu+k6lHWCCOcJh/wQmwgWHgfhu3fr+PEq6WpjFqMl 4Znhn7SvLlE1lADT8FnAbfz9ND1rT+BVmhITEnQ11eXcb0YHJOLPN8Fmua+G/eM= =3Daj -----END PGP SIGNATURE-----

3 5

Latest state of the guard algorithm proposal (prop259) (April 2016)
by George Kadianakis 13 Apr '16

13 Apr '16

Greetings STRIKE team! It seems like the latest version of prop259 was posted a few weeks ago: https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html My understanding is that since then a few things have changed particularly with regards to the dystopic heuristic, and the various filtering torrc options. More discussion happened in the mailing list, but we have not posted a newer version of the proposal yet: https://lists.torproject.org/pipermail/tor-dev/2016-April/010714.html A few things: a) Are there still proposal design decisions that need to be taken and we are unclear on? I admit I'm a bit lost in the latest [tor-dev] thread, so maybe I can be of help somehow here? b) Have you guys updated your version of the torspec based on the mailing list discussions? Is it possible to post the latest version in the mailing list? A few people have enquired about the latest version of the proposal, and I'm hesitant to send them the latest [tor-dev] release of the proposal because maybe too many things have changed since then. c) Let me know if there are any open implementation questions that I could assist with. Cheers!

1 0

Configuring Single Onion Services
by Tim Wilson-Brown - teor 12 Apr '16

12 Apr '16

Hi All, I'm working on proposal 260's Rendezvous Single Onion Services in #17178. They are faster, because they have one hop between the service and the introduction and rendezvous points. But this means that their location is easy to discover (non-anonymous). So we want to come up with a design that makes it hard to configure a non-anonymous service by accident. Here's a cut-down version of an email I sent to tor-onions for feedback, for those who are on both lists: Nick's concern was that users could configure Single Onion Services without realising that it provides no server location anonymity. I initially thought we could change the torrc option name to make this clear. ... I now believe that trying to overload the name of a feature with warnings about its downsides was a mistake. … This would mean that Single Onion Service operators would include in their torrc: SingleOnionMode 1 HiddenServiceDir … ... As a separate issue, I think there are two alternative designs that can prevent users from configuring the feature and then exposing their location unintentionally: Tor2WebMode requires users to add a compilation option: --enable-tor2web-mode We could do this with Single Onion Services as well: --enable-single-onion-mode If SingleOnionMode is configured without the compilation option, tor warns the user and refuses to start. When it is configured, tor warns the user they're non-anonymous, then starts. However, using a compilation option makes the feature harder to test. And Tor2Web operators already don't like having to compile separate binaries. It's likely Single Onion operators would feel similarly. Alternately, we could add a torrc option: NonAnonymousMode If SingleOnionMode is configured without NonAnonymousMode, tor warns the user and refuses to start. When it is configured, tor warns the user they're non-anonymous, then starts. I spoke with Nick on IRC and he's happy with either of these options. I'd like to proceed with the NonAnonymousMode torrc option, unless there are compelling reasons against that design. I hope that this will allow us to get SingleOnionMode merged early in tor 0.2.9. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B ricochet:ekmygaiu4rzgsk6n

5 8

txtorcon: fixing APIs, painting bikesheds
by meejah 11 Apr '16

11 Apr '16

There are several rough edges and "regrettable" API choices in txtorcon that I'd like to fix as a "1.x" release. I also had several productive discssions with Brian Warner (thanks a lot!) suggesting some things to make using txtorcon easier. To that end, I am collecting some of these thoughts as well as massively re-organizing (re-doing?) the documentation in a branch called "release-1.x". ReadTheDocs is building this now, too. Some highlights of what I'm doing or find annoying currently: - Move a bunch of things to "private" attrs/functions that were never supposed to be public (i.e. prefix a bunch more things with "_") - Eliminate need to deal with the "bootstrap" Deferreds (via factory functions and/or other help methods) (mostly this is true already) - Python3 (works in release-1.x branch now, minus txsocksx) - Re-org docs, add "programming guide" (instead of walkthrough, tutorial and HOWTO) - consolidate examples (there's too many, and some are confusing) - introduce a "Tor" object that abstracts "a running tor instance" (whether launched by txtorcon or just connected-to) as a Builder or Factory for other useful objects. This would be "the" high-level API that most users would interact with. Something like: @inlineCallbacks def main(reactor): tor = yield txtorcon.launch(reactor, ...) # or .connect() torstate = yield tor.create_state() print("all circuits:", torstate.circuits.values()) endpoint = tor.create_client_endpoint('torproject.org', 443) onion = tor.create_onion_endpoint(port=80, private_key=None) # etc. This would get rid of "launch_tor", "build_local_tor_connection" and others, giving just "launch()" or "connect()". get_global_tor() would also return a "Tor" instance. Also, launch() would *not* take an arbitrary TorConfig (as launch_tor does now) but instead would expose a very few critical options as kwargs (and if you need to mess around with obscure options, you'd do so after launch). - .get_info() should never have returned a dict (instead: list of results, in same order as keys) - consolidate all the various types of "onion/hidden-service" things to support ephemeral and "on disk" services, as well as authenticated. There are currently conceptually 6 variants from tor: ephemeral: plain, basic-auth (not in tor), stealth-auth (not in tor) on-disk: plain, basic-auth, stealth-auth This is further complicated by the fact that both the authenticated services are really, logically, a "list of clients" each of which has a name, a secret (and for stealth, a separate .onion address). My current design *ideas* are in the release-1.x branch, but boil down to interfaces: IOnionClients (for basic + stealth auth) which is a collection of IOnionClient instances (has secret + name, and is a subclass of IOnionService) and IOnionService for all the rest (has hostname, ports, private-key). This stuff is the most in-flux still. "create a new onion service" would be available at the high level via one or several method-calls on Tor() instances which would return new concrete IStreamClientEndpoint or IStreamServerEndpoint implementers - For "I want a Stream over Circuit X", add a ".stream_to(endpoint)" method on Circuit instances that gives you a Twisted IStreamClientEndpoint implementation causing the stream resulting from .connect() to be attached to that specific circuit. - Introduce a configurable "CircuitBuilder" to more-easily control construction of "types of" circuits (instead of just "build a circuit through these exact relays" as .build_circuit() provides). For more, see: https://github.com/meejah/txtorcon/issues/125 - re-consider all the magic (attribute-style access) of TorConfig - Add a "composible"-style API for listening to Circuit and Stream events (instead of having to implement ICircuitListener etc). I would be happy to hear of (other) existing APIs that are awkward or confusing as well as opinions on the general colour of my bikeshed. Please beware that this branch is very much "in progress" ;) As far as current users of 0.x releases: I will not break these, and will backport any critical fixes to them. My preference would be to simply work with existing users (e.g. via pull-requests to your repos) to let them seamlessly upgrade to 1.x as soon as 1.0.0 is pushed out the door. Where possible I can provide wrappers for backwards-compatiblity for any removed/re-named methods My goal here is *not* to just gratuitously break things "because aesthetics" but to make the "API surface" of txtorcon smaller, easier to understand and better documented. How to help: - look at http://txtorcon.readthedocs.org/en/release-1.x/ (note that some of the docs are lies as the code doesn't always exist yet, or worse yet exists but isn't what I want) - express opinions (here, #tor-dev, via any of the methods at https://meejah.ca/contact) - *maaaybe* look at the new code (but I'm trying to write the docs first, so those are the most-useful to look at). I want the docs to reflect the upcoming reality, and will change the code to match. Thanks, meejah

1 1

Notes from the prop224 proposal reading group
by George Kadianakis 09 Apr '16

09 Apr '16

Hello, so we had a meeting about the future of "Next Generation Hidden Services" aka prop224. It was a good meeting. We spent most of the time discussing the topics brought up here: https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html Please read the above mail to get up to speed with the topics of discussion. So these are basically two topics: a) Should we try to maintain backwards compatibility with old intro/rend points? We ended up deciding that it's actually worthwhile keeping backwards compatibility if we can help it: Our rationale was that coding the logic for the extra cells that are required to maintain backwards compatibility is probably less painful than coordinating a perfect bug-free incremental deployment of prop224 in such a way that the whole network has upgraded before we enable client support. So our current plan is to bake backwards compat in the code, and also introduce a consensus parameter of "Should we connect to prop224 onion services using legacy IPs/RPs?" which we will switch off when a good percentage of the network has upgraded to support prop224. At that point, we will be able to rip out the backwards compat code as well. As an added point to that, we should implement the backwards compat code in a way that it's not spagghetied with the normal code, so that it's easy to analyze and remove when needed. Furthermore, we should look back in prop224 and see if we can simplify the backwards compat logic even more. FWIW, prop224 does not have backwards compatibility for HSDirs, so we will still have to do careful deployment there, and make sure that a good percentage of HSDirs have upgraded to prop224 before we start using them (maybe a new consensus parameter is needed here). b) In prop224, why do intro points need to know the "intro point encryption key" and also what's the point of UPDATE-KEYS-SUBCMD? Nick told us that the main point of UPDATE-KEYS-SUBCMD is that so hidden services can rotate their intro point encryption key periodically, so that they can reset their replay caches. That's a fair point. The big question here is, is this worth the complexity that MAINT_INTRO and UPDATE-KEYS-SUBCMD add to the protocol logic? Unfortunately we don't know the answer to this yet, because we actually don't have stats on how our replay caches are doing currently. Here are some things we need to look into: i) Speak with facebook or some other big onion hoster, and try to get some information about their replay cache. Is it ready to bust? How much space is it occupying? ii) The above will help us gauge replay caches in terms of normal activity, but we also need to think of how replay caches should act in cases of a DoS. iii) Also think about INTRODUCE1 replay attacks in general, and understand how dangerous they can be, so that we know how robust our replay caches should be. Is it _that_ dangerous if an attacker manages to sneak in a replay attack every once in a while? For example, imagine an attacker who fills up our replay cache on purpose, so that she can sneak in one replay attack when we reset it. If an attacker can send legit INTRODUCE2 cells to fill up our replay cache, what does she need the replays for? What other types of attacker are there? After we learn more about the above, we will understand *how much we care* about onion services being able to rotate intro pint encryption keys on the fly using UPDATE-KEYS-SUBCMD. Here are some possible scenarios here: - We end up deciding that INTRODUCE1 replay attacks are *dangerous* and we need to seriously defend ourselves against them. In this case, having some sort of UPDATE-KEYS-SUBCMD mechanism sort of makes sense, since onion services should be able to rotate keys at will and let their clients know, without them having to fetch a new HS descriptor. - We end up deciding that INTRODUCE1 are a concern but not something we should complicate our design considerably for. In this case, we might want to consider improving the quality of our replay caches, by using more compact designs (= more space for entries), or by using bloom filters or a similar tech. A proposal will need to be made if so. Yawning posted the following relevant paper: https://home.kookmin.ac.kr/~mkyoon/publications/2010TKDE.pdf - We end up deciding it's no big deal if the attacker sneaks in a replay attack every once in a while. In this case, we can just go with the most minimal approach and ditch the UPDATE-KEYS-SUBCMD mechanism for now, and have intro points be oblivious about encryption keys (which further simplifies our cell formats, etc.). If we take this approach, and in the future future we change our minds about the importance of replay attacks, we can still add some sort of UPDATE-KEYS-SUBCMD mechanism using the extensions mechanism of ESTABLISH_INTRO cells. Furthermore on this topic, we discussed some alternate approaches for doing replay detection that would require less heavy replay caches: i) Maybe we can have an increasing counter in the HS descriptor, that clients need to also include in their INTRODUCE1 cell. If an onion service receives an INTRODUCE1 cell with a counter value different than the one in the descriptor, it ignores it. Onion services update the counter and publish a new descriptor when their replay cache is close to getting filled. I believe various subtle engineering details are hidden in this scheme, along with edge cases and race conditions like "What happens if the client fetches a descriptor with counter value N, right before the onion service updates the descriptor with a new counter value?". ii) When an intro point replay cache is almost full, the onion service will make new encryption keys, tear down the old intro circuit and make a new one, and also pass a signed "HS moved to another circuit" message to the intro point. The intro point will forward that message to any clients that ask for the onion service using its old keys, so that clients know the right place to ask. Lots of engineering details hidden in this proposal as well. In the end we decided that Roger might have some useful feedback for us here :] More research is required! Cheers!

4 9

Using Let's Encrypt for meek bridges
by David Fifield 09 Apr '16

09 Apr '16

I'm looking for ideas of good ways to handle TLS certificates and their renewal for meek bridges. I want to use Let's Encrypt for this process, and I hope that someone who knows Let's Encrypt well can contribute some ideas. All three of the meek bridges use HTTPS to receive connections from the CDN, so they need TLS certificates. For example, when you use meek-azure, your traffic is forwarded to the bridge at https://meek.bamsoftware.com/. How it works now is I do the usual domain validation procedure with a CA, receive an email to show that I control the domain, install the cert and key, and then run the server like this: meek-server --cert /etc/meek/cert.pem --key /etc/meek/key.pem When I used Let's Encrypt in the past, using the --webroot option, it wanted to write a file to the URL path "/.well-known/acme-challenge/{token}". That won't work for meek-server as it exists today, because meek-server never serves files from the filesystem. But it could. Perhaps we could add an option like --acme-webroot that would allow serving files from a single whitelisted directory. I notice that there are other ways of proving domain ownership (HTTP, TLS SNI, DNS). Maybe we could use one of those? https://ietf-wg-acme.github.io/acme/#identifier-validation-challenges I also note that there are third-party plugins: https://github.com/letsencrypt/letsencrypt/wiki/Plugins Maybe there could be a plugin for meek-server (ideally not requiring new complicated code in meek-server itself). Currently you have to restart meek-server in order to make it notice a changed certificate and key file. It would be better if that were not necessary--maybe we could periodically stat the files, and re-load them if they have changed? This is going to be an issue for Snowflake as well, because we will want to use WebSocket over TLS for the server component.

2 2

Introduction: CollecTor Improvement Project
by iwakeh 08 Apr '16

08 Apr '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! With the first nice spring days in some parts of the Northern Hemisphere the CollecTor Improvement Project started. You probably know that CollecTor [0] is the friendly data-collecting service in the Tor network. It fetches data from various nodes and services in the public Tor network and makes it available to the world. The current project aims at making CollecTor more robust against data loss and improve its source base, development structure, as well as its installation procedure and configuration. More details can be found in the project's wiki page [1]. Further general discussion of the CollecTor Improvement Project will take place in the metrics-team mailing list [2]. So, if you're interested your can subscribe there, too. Cheers, iwakeh [0]: https://collector.torproject.org/ [1]: https://trac.torproject.org/projects/tor/wiki/doc/CollecTor/Improvements [2]: https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlcHjlgACgkQsANAxTOj/aYIVQD+KwlYx5FFXy+uiCtF8wCIAfeA SJQ3Fnk4YQC598/jo9QA/RUaZ/Z99Yjey8DsniBZTOJ/lTNlCOcKpXyXLIaOezOB =CSaG -----END PGP SIGNATURE-----

2 1

Research on Breaking reCAPTCHA
by bancfc＠openmailbox.org 08 Apr '16

08 Apr '16

While I don't understand why researchers are doing free labor for Google its still an interesting read on the innards of reCAPTCHAs and its weaknesses. Some tests were done with Tor: http://www.cs.columbia.edu/~polakis/papers/sivakorn_eurosp16.pdf

1 0

Re: [tor-dev] Update on 259
by Ola Bini 08 Apr '16

08 Apr '16

Hey, > > - OrPort vs DirPort > > ORPort is used for regular circuits, while DirPort is used when getting directory information. We need to interpret reachable stuff > > differently depending on the purpose. > > > > I'm not actually sure what the comment means here. This was more for our own benefit. The OrPort vs DirPort distinction has been a bit complicated so far. The comment basically means, when we are looking up directory information, we should use the DirPort to decide reachability and so on instead, correct? > Ensuring a min percentage of dirguards in our sampled set could work. Then, > when we need a directory guard, we could filter the sampled set and only > examine guards that can do directory requests. Yeah, we talked about this yesterday and our current thinking is to have a sampled set that contains every kind of thing, and then we dynamically filter it based on config and so on during START. > Hm, are you talking about the guardlists here? What's the question? > > BTW, if we have the ability to do "ensure a min percentage of X in our sampled > set", couldn't we just ensure a min percentage of dystopic guards in our > sampled set? And forget about the two separate guardlists? > > In this case we can have the percentage value be the actual portion of the > network that is dystopic guards. So if 20% of the total guard bandwidth is > dystopic, we could ensure that at least 20% of our sampled set is > dystopic". Well, the problem is really that the idea of dystopic doesn't necessarily make sense, since it's so dependent on the current network position of the client. Our current thinking is to do away with that concept as well. =) > > - DYSTOPIC - is there value in trying 80 and 443? > > Probably not. > > > > What does "trying" mean in this case? Falling back to guards with 80 and 443. > Restart pending guard selection algorithms on a SIGHUP? Plausible, but I don't > know how hard it would be to implement this. Well, the alternative is to just finish the running guard selections with the old settings, but use the new settings for new algorithm instances. > That's not very nice because the USED_GUARDS set that was created when > ClientsUseIPv6 or FascistFirewall were on will have reduced diversity. Then > even if we switch off those options, we are still stuck with reduced diversity. > > I'm not sure what's the right way to do this here! > > We could imagine having multiple USED_GUARDS sets, where we make a new set for > each possible filter. This might be worth considering, but I imagine there will > be technical difficulties. e.g. when a guard goes down, you need to update its > state in all the USED_GUARDS sets that it's in. Also, a person who toggles the > FascistFirewall option frequently, will end up using two different sets of > guards all the time which is suboptimal. Well, one thing you could do is hash the settings (and maybe also reachable ports) and use that as a key to differentiate the different USED_GUARDS. That would solve the problem, but might lead to a single client using lots of different guards in different locations. Might that be OK? > > - Can we make the lists smaller? > > Probably. Maybe a sampled set of 30 guards? Or 1.5%? > > > > Plausible. However, if we take the filtering approach but use a small sampled > guards list, it could happen that the list is not able to satisfy some of our > filtering restrictions. > > e.g. maybe in our 30 guards there are no IPv6 guards at all, and the user just > turned on ClientUseIPv6. What to do now? > > This is important to understand, because currently there is no mechanism to add > stuff to the sampled guards list if a restriction cannot be satisfied. So what > will Tor do, if a user enables ClientsUseIPv6 _and_ FascistFirewall but there > are no IPv6+80/443 guards in our sampled guards list? Yeah, we talked about that yesterday. Our suggestion is to do something like this: - if the filtered/reduced sample-set contains less than X (5?) guards, expand SAMPLED guards using the regular process. - If SAMPLE guards reach SAMPLED_MAX (50?) size, we fail closed with an error saying something like "your current network settings make it impossible for us to safely choose an entry guard. If you really need to connect under these circumstances, consider explicitly setting the EntryGuards configuration option" > I think it asks "What happens when guards in our sampled set drop out of the > consensus and get marked as bad?" (see bad_since in entrynodes.c) . > > This is also a great question. Especially when combined with the planned > "ensure a min percentage of X in our sampled set" logic. > > Like, what happens if suddenly most of our sampled IPv6 guards drop out of the > consensus when we have ClientsUseIPv6 on? Should we replace them? And if yes, > don't we need to replace them with other IPv6 guards to maintain the minimum > percentage? Well, I think if we replace, we should just replace randomly just like we always expand the sampled set. If most ipv6 guards drop out, we will have fewer ipv6 guards in our sampled set, but that also reflects the Tor network. I suspect a plausible thing to do is to wait a few consensus rounds with expanding the sampled set to replace "bad" guards - they might come back, and under most circumstances we shouldn't need to use the sampled set anyway. > The current proposal says the following about SAMPLED_UTOPIC_GUARDS: > > It will be filled in by the algorithm if it's empty, or if it contains > less than SAMPLE_SET_THRESHOLD guards after winnowing out older guards. > > which I think is a good suggestion. However, what should we do if we end up > going with the "ensure minimum percentage" logic? Yeah, my suggestion is not have minimum percentage of X type guards - instead just fill it randomly, and use the expanding process if we can't find enough guards for a specific purpose. > > - EntryNodes > > If this is set, never use the algorithm for regular circuits - we should still use it for directory server connections though. > > If this is set we should not use our algorithm, but we should instead pick one > of the guards in the EntryNodes list. This is for people who want to hardcode > their guard. It's used a lot by people currently. Yeah. Is the guard picked randomly from this list, or using something more complicated? > > - UseEntryGuardsAsDirGuards > > I don't understand exactly what this settings does. > > I'm not sure either. I'd just let it keep the exact same semantics it currently has. Yeah, except we don't exactly understand what does semantics are, and if we need to change something in our code to match it. =) Thanks for all the feedback! Hopefully we're getting close to the final iteration of this spec. =) Cheers -- Ola Bini (https://olabini.se) "Yields falsehood when quined" yields falsehood when quined.

5 10

Tor debugging
by SMTP Test 07 Apr '16

07 Apr '16

Hi all, I am working on a project that needs to do some modifications on the source code of Tor, to add functionalities to Tor relay. To debug I used chutney to setup Tor network locally, and checked the logs of the relay. But it is still painful and slow: I need to restart the script, and wait the network to be up every time I make changes. My question is: is there any fast way to test/debug the functionalities of Tor relay? Thanks!

2 1

extension for chrome and mozilla
by Mukul Gupta 07 Apr '16

07 Apr '16

hello tor-dev I want to make extension which can control network in my browser. so that i can connect to my some other computer which has VPN . And after that the data is exchanged between VPN server and the user. And the intermediate nodes won't be able to identify whats going on. This is my project proposal. Can you help me in this how to initiate this project.

1 0

Re: [tor-dev] Update on 259
by tdruiva＠riseup.net 06 Apr '16

06 Apr '16

Adding tor-dev. On 04/06/2016 08:53 AM, Tania Silva wrote: > Hey, > >>>>>> Yeah, we talked about that yesterday. Our suggestion is to do >>>>>> something like this: >>>>>> - if the filtered/reduced sample-set contains less than X (5?) guards, >>>>>> expand SAMPLED guards using the regular process. >>>>>> - If SAMPLE guards reach SAMPLED_MAX (50?) size, we fail closed with >>>>>> an error saying something like "your current network settings make it >>>>>> impossible for us to safely choose an entry guard. If you really need >>>>>> to connect under these circumstances, consider explicitly setting the >>>>>> EntryGuards configuration option" >>>> >>>> Oh, wow, I don't think failing closed is a good idea. >>>> It means users that move around a lot (and clients which have a longer state history) could fail at some arbitrary time. >>>> Why not simply continue to add guards that satisfy the restrictions? >> Well, users that move around a lot will only have an expanded sampled >> set if they move between several different networks that have severe >> restrictions - but mutually exclusive such restrictions. And we would >> only ever hit this fail closed if we can't find anything in the >> sampled set that matches the current needed restrictions. If we keep >> adding guards, the idea of the sampled set as a measure to minimize >> exposure to too many guards fly out the window. >> >> The problem really comes down to this - if you have a network that is >> actively firewalling every guard that is not under their control, if >> we keep expanding we will sooner or later be forced to use a guard >> under adversary control. By failing closed, we can avoid that >> eventuality. > > We thought in to have a minimum size for this set after been filtered [1]. > > ``` > MINIMUM_FILTERED_SAMPLE_SIZE > The minimum size of the sampled set after filtering out nodes based on > client configuration (FILTERED_SAMPLED). Proposed value is ???. > ``` > > In order to expose less guards when we are expanding sample set, we > thought in to have a maximum size before to fail. > What do you think if this is a configurable value by user? (we can have > as default if not provided) > > ``` > MAXIMUM_SAMPLE_SIZE_THRESHOLD > In order to guarantee a minimum size of guards after filtering, we > expand SAMPLED_GUARDS until a limit. This fraction of GUARDS will be > used as an upper bound when expanding SAMPLED_GUARDS. Proposed value is > 0.03. > ``` > > 1 - > https://github.com/twstrike/torspec/blob/review/proposals/259-guard-selecti… >

1 0

Adding one more (optional) step to Trac's ticket work-flow
by Isabela 06 Apr '16

06 Apr '16

Hello tor-dev! tl;dr; we want to add one more step to Trac ticket work-flow called 'merge_ready' - if you don't want to use it you don't need to During Tor's Dev Meeting in Valencia, the Network Team discussed a code review process[1] for the team and we concluded that for us a two stage review process would make things much better for the team. In order to organize that on our ticket work-flow on Trac, we decided to add the step 'merge_ready'[2] that would come after either 'needs_review' or 'needs_revision' steps. For our team, what that will mean is that we have reviewed the code and believe is ready for Nick to do a second review and merge. The first review will remove load from Nick and we want to eventually have more folks helping Nick on the second review as well. But this change alone will be already a big step. What does that means for someone working on a ticket that is not part of Core Tor development flow? Well, if you don't want to use it in your team or your project flow, you can just ignore it and keep using Trac as normal. We are sending this note to make sure folks knows about it before it happens and of course, to hear any concerns or feedback. Cheers, Isabela [1] https://trac.torproject.org/projects/tor/wiki/org/meetings/2016WinterDevMee… [2] https://storm.torproject.org/shared/pt9FtdJNG_gB_afqayg9dXTJwdDFncgU0HVXJEq… -- PM at TorProject.org gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1 B298 3224 4994 1506 4C7B @isa

3 2