tor-dev

tor-dev@lists.torproject.org

5 participants
3594 discussions

Request for references for anonymous blocklisting (blacklisting)
by Virgil Griffith 23 Feb '14

23 Feb '14

I'm putting together a proposal for adding anonymous blocklisting into the Tor such that websites that block Tor can block single problematic users instead of all Tor exit nodes. Towards this end, I am looking for papers/prior work in this area to draw from. Pointers anyone? Enjoyed the Iceland conference. Thank you Roger for inviting me! I aim to be contributing to Tor more over the year. -Virgil

2 1

Proposal: namecoin-integration.txt
by Joe Foe 22 Feb '14

22 Feb '14

Filename: namecoin-integration.txt Title: Improve security and usability by Namecoin integration Author: Maxim Novoselov Created: 06-Feb-2014 Status: Open Overview: This document describes enchantments of hidden services domain names with integration of namecoin domains. Motivation: Currently user must lookup hidden service domain name in various directories. This directories are owned not by the hidden service owner so hidden service address can be easily spoofed by owners of this directories. Found service name is immemorable so user tends to add it to the bookmarks which leads to (maybe)harmful trails. This adds ability to use also original .bit domains and improves tor's ecosystem in general. Design: Hidden service owner registers special domain name using namecoin and binds it to the .onion hidden service. That way he anonymously claims that this service owned by him and he can control it using namecoin system. This special domain name tld must differ from .bit and .onion to avoid confusion because they are already used by clear-web sites(.bit) and deep-web ip-address surrogate(.onion). Hidden service client lookup domain name at namecoin and connects to the resolved .onion domain. Security implications: Proposed changes improve total security by decentralizing directory services and give ability to hidden service owners to claim their names. Also it makes end-user more anonimous by forcing him not to use bookmarks. Specification: Compatibility: Implementation: This can't be implemented using namecoin DNS'es because they are operated by third-party and may be forged. Good way is to use namecoin-rpc to query domain names. Its easy but requires namecoin software running which is storage space intensive. So not every user have ability to support namecoin server and we have to provide a choice: use local copy of bitcoin-rpc or remote. Even better would be to integrate namecoin-rpc into production but only for nodes or bridges and use this nodes as internal DNS alternative for enduser-tor-clients. -- Best regards

1 0

Proposal 227: Include package fingerprints in consensus documents
by Nick Mathewson 21 Feb '14

21 Feb '14

Here's a new proposal for a thing that Mike wants for TBB. Please review! Filename: 227-vote-on-package-fingerprints.txt Title: Include package fingerprints in consensus documents Author: Nick Mathewson, Mike Perry Created: 2014-02-14 Status: Open 0. Abstract We propose extending the Tor consensus document to include digests of the latest versions of one or more package files, to allow software using Tor to determine its up-to-dateness, and help users verify that they are getting the correct software. 1. Introduction To improve the integrity and security of updates, it would be useful to provide a way to authenticate the latest versions of core Tor software through the consensus. By listing a location with this information for each version of each package, we can augment the update process of Tor software to authenticate the packages it downloads through the Tor consensus. 2. Proposal We introduce a new line for inclusion in votes and consensuses. Its format is: "package" SP PACKAGENAME SP VERSION SP URL SP DIGESTS NL PACKAGENAME = NONSPACE VERSION = NONSPACE URL = NONSPACE DIGESTS = DIGEST | DIGESTS SP DIGEST DIGEST = DIGESTTYPE "=" BASE64 NONSPACE = one or more non-space printing characters BASE64 = one or more base-64 characters, with trailing =s removed. SP = " " NL = a newline Votes and consensuses may include any number of "package" lines, but no vote or consensus may include more than one "package" line with the same PACKAGENAME and VERSION values. All "package" lines must be sorted by PACKAGENAME, and then by VERSION, in lexical (strcmp) order. If the consensus-method is at least (TBD), then when computing the consensus, package lines for a given PACKAGENAME/VERSION pair should be included if at least three authorities list such a package in their votes. (Call these lines the "input" lines for PACKAGENAME.) That consensus should contain every "package" line that is listed verbatim by more than half of the authorities listing a line for the PACKAGENAME/VERSION pair, and no others. These lines appear immediately following the client-versions and server-versions lines. 3. Recommended usage Programs that want to use this facility should pick their PACKAGENAME values, and arrange to have their versions listed in the consensus by at least three friendly authority operators. Programs may want to have multiple PACKAGENAME values in order to keep separate lists. These lists could correspond to how the software is used (as tor has client-versions and server-versions); or to a release series (as in tbb-alpha, tbb-beta, and tbb-stable); or to how bad it is to use versions not listed (as in foo-noknownexploits, foo-recommended). Programs MUST NOT use "package" lines from consensuses that have not been verified and accepted as valid according to the rules in dir-spec.txt, and SHOULD NOT fetch their own consensuses if there is a tor process also running that can fetch the consensus itself. For safety, programs MAY want to disable functionality until confirming that their versions are acceptable. To avoid synchronization problems, programs that use the DIGEST field to store a digest of the contents of the URL SHOULD NOT use any URLs whose contents are expected to change while any valid consensus lists them. 3.1. Intended usage by the Tor Browser Bundle Tor Browser Bundle packages will be listed with package names 'tbb-stable, 'tbb-beta', and 'tbb-alpha'. We will list a line for the latest version of each release series. When the updater downloads a new update, it always downloads the latest version of the Tor Browser Bundle. Because of this, and because we will only use these lines to authenticate updates, we should not need to list more than one version per series in the consensus. After completing a package download and verifying the download signatures (which are handled independently from the Tor Consensus), it will consult the appropriate current consensus document through the control port. If the current consensus timestamp is not yet more recent than the proposed update timestamp, the updater will delay installing the package until a consensus timestamp that is more recent than the update timestamp has been obtained by the Tor client. If the consensus document has a package line for the current release series with a matching version, it will then download the file at the specified URL, and then compute its hash to make sure it matches the value in the consensus. If the hash matches, the Tor Browser will download the file and parse its contents, which will be a JSON file which lists information needed to verify the hashes of the downloaded update file. If the hash does not match, the Tor Browser Bundle should display an error to the user and not install the package. If there are no package lines in the consensus for the expected version, the updater will delay installing the update (but the bundle should still inform the user they are out of date and may update manually). If there are no package lines in the consensus for the current release series at all, the updater should install the package using only normal signature verification. 4. Limitations and open questions This proposal won't tell users how to upgrade, or even exactly what version to upgrade to. If software is so broken that it won't start at all, or shouldn't be started at all, this proposal can't help with that. This proposal is not a substitute for a proper software update tool.

3 3

Re: [tor-dev] Registering special-use domain names of peer-to-peer name systems with IETF
by John Bond 20 Feb '14

20 Feb '14

Hello All, Im writing to the list in response to IETF submission made by christian. This has created much debate on the DNSOPS mailing list[1] and has also seen another draft to be proposed[2]. I will start by saying I see merit in both drafts being proposed[3][4] and don¹t necessarily see them as being mutually exclusive. However the discussions on the list seem to keep coming back to one question would it be feasible for you to retrospectively change the anchor of .onion to some other TLD. E.g. .onion.arpa. There is much speculation on this questions however it appears that the question has not been directly asked on this list. Therefore I would like to ask the following. - What would be the barriers both, technical and political, for tor to change the anchor it uses from .onion to something else (whatever that may be)? - If such a change where to happen what would be an acceptable timeline for new software to stop supporting the old anchor? - If the .onion is unsuccessful in its request to be reserver under the mechanism laid out in rfc 6761[5]. Would there be any motivation to change the anchor so that it conformed to a different policy and therefore allow operators and developers to prevent leakage of this name on the internet - Are there any privacy concerns caused by .onion names leaking on to the internet in the form of a DNS QNAME by software trying to resolve the name - If an organisation where to obtain the .onion name under the gTLD programme are there any privacy concerns considering the organisation could now answer the DNS queries mentioned above. I.e. If a user requested notatrap.onion without tor configured instead of getting no response the could be redirected to a site controlled by the new owner of the .onion domain. Thanks John [1]http://www.ietf.org/mail-archive/web/dnsop/current/msg10785.html [2]http://www.ietf.org/mail-archive/web/dnsop/current/msg11074.html [3]http://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-01 [4]http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-00 [5]http://tools.ietf.org/html/rfc6761

2 2

Future pluggable/lib obfus transport?
by grarpamp 20 Feb '14

20 Feb '14

> The short answer is that obfsproxy is indeed not designed to > facilitate PTs like DNS transports. It will probably require a > considerable refactor of obfsproxy to write a DNS pluggable > transport. It will probably require so much refactoring that I'm not > sure if it would make sense to merge the changes back upstream > (because the changes might not be useful for other PTs). Re the above from George, and some talk I see about obfs versions, am I right that obfsproxy is not yet a general pluggable transport tool? As in a library and/or standalone proxy that two endpoints put in front of themselves, choose from a menu of (or negotiate) obfus and say go in a nearly automatic fashion? A C/python library interface would be interesting, as would deciding what the standalone proxy might be among socks5, transparent firewall redirection, tun interface, etc. In addition to DNS, people have written HTTP, IRC, ICMP, raw IP, etc tunneling tools in the past.

2 1

Call for testing/review: obfsclient
by Yawning Angel 19 Feb '14

19 Feb '14

Hello all, For a few reasons I thought it would be useful to have an obfs3 client implementation that did not depend on python (primarily systems where building python is non-trivial, think cellphones). The end result is https://github.com/yawning/obfsclient It passes what little basic functionality testing I've done (I can browse the web with it), but could use another set of eyes on the code. Caveats: * The build process kind of sucks, since it starts off with "Edit the CMakeLists.txt". * liballium doesn't have a install target since I didn't get around to it, adding a bit more pain to the build process. Thanks in advance, -- Yawning Angel

2 14

Coordination of censorship analysis tool
by Philipp Winter 19 Feb '14

19 Feb '14

Hi Deepak, Utsarga, Tobias, and Yiwen! The four of you recently expressed interest in the censorship analyser project [1]. At this point, we only have a paper which discusses what we want from the tool [2]. There is no official code repository but Tobias recently started experimenting with some modules [3]. It would be great if you all could join forces and split the workload. I understand that some of you have some constraints from your respective university. As a result, could you please reply to this email (don't forget to CC tor-dev) and sum up what you can/want to do and if you are under any constraints such as a time-limited class project? We can then see if and how we can divide the project into several sub projects. Regarding development and coordination: This mailing list is great for high-latency, broad, conceptual, and public discussions. For low-latency questions, the #tor-dev channel on OFTC is better. There's also #ooni for OONI-specific questions (most of the developers are in Europe, so you might have to wait for answers). I am not sure how familiar you are with git but it is certainly the preferred version control system in and around Tor. So this might be a good opportunity to learn how to use it :) [1] https://www.torproject.org/getinvolved/volunteer.html.en#censorshipAnalyzer [2] http://www.cs.kau.se/philwint/pdf/foci2013.pdf [3] https://tobiasrang.com/svn/analyser/ Cheers, Philipp

7 14

Re: [tor-dev] 2014WinterDevMeeting/notes/TBBReleaseProcess
by intrigeri 17 Feb '14

17 Feb '14

Hi, FWIW, from my Tails PoV: * I concur, it would be very helpful for us to have some better visibility on what's coming in the next TBB. * Mike has answered us in a very kind, timely and detailed way every time we've asked him this information. Many thanks! Also, I figured it would be good if the Tor Browser team was aware that we've been playing a kinda dangerous game lately: we are generally building our browser and ISO on the Sunday before a Firefox release is scheduled, so that we can test it on Monday, and release on Tuesday at the same time as Firefox. The rebased Tor browser patches are usually published at a time when we've already built our browser. Until now, it has been fairly smooth and painless: the slightly older patches apply nicely on the new tree, and the resulting browser works fine. Worst case, we've missed some last-minute improvements. However, I'm a bit scared that one these days, Tails users are hit by an important problem caused by this scheduling mismatch. I'm not expecting the Tor Browser folks to work week-ends and make our life easier, so the best we can do is possibly to go on automatizing things, so that we can reduce the time manual testing of Tails releases takes, and build our browser later. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

2 1

gsoc-2014
by G.VAMSHI KRISHNA REDDY 16 Feb '14

16 Feb '14

hi, I am vamshi pursuing B-Tech in CSE and MS by Research in CSE at IIIT Hyderabad(currently second year). I am interested in participating gsoc-2014 by doing project under your organization. I am familiar with python and interested doing the project in python language by contributing to the python tool Chutney.Can anyone suggest me how to get started with this tool and how to go further in applying for this organization for doing project this summer. Thanks, vamshi

3 2

[Discussion] 5 hops rendezvous circuit design
by Qingping Hou 14 Feb '14

14 Feb '14

Hi all, We are a university research group and following is a proposal for possible optimization on Tor's rendezvous circuit design. It's not written as a formal Tor proposal yet because I want to have a discussion with the community first, get some feedbacks and make sure it does not introduce new vulnerabilities. So please feel free to comment if you have any thoughts or find any holes :) PS: a txt version of the proposal is attached in this mail as well. ------------------------------------------------------ The changes described in this document is focused on speeding up hidden service while at least keeping the same level of anonymity as current version provides. Naming conventions: HSv3: current version of hidden service protocol HS5h: hidden service protocol that uses 5 hops HS: hidden service client: The onion proxy that tries to communicate with HS HSDir: hidden service directory RP: rendezvous point 1. The 5 hops rendezvous circuit The setup on HS side is the same as HSv3. HS picks couple introduction points and uploads the descriptor to HSDir. The main difference is how to pick the RP. In HS5h, Instead of letting the client pick whatever node it wants, both client and HS use negotiation protocol to pick a RP collaboratively. Following is a high level description for the rendezvous circuit setup process in HS5h: (0) client fetches descriptor for a hidden service. (1) client connects to introduction point. (2) since client and HS are connected via introduction point, they can negotiate a random number using this channel. (For more details, see [RAND_NEGO]) (3) both client and HS maps that random number to a random onion router using the same scheme, so they end up with the same node. This is the candidate RP. (4) both client and HS create a 3 hops circuit using RP as last hop. (5) RP joins the circuit originates from HS to the circuit originates from client. (6) now client and HS are connected. Because their original circuits share the same endpoint(the RP), the length of the path is 5 hops. Improvement: (1) Reduction in circuit setup time. Both the client and HS only build 3 hops circuit now. While In current protocol(HSv3), HS needs to build a 4 hops circuit. (2) A shorter circuit means less transmission delay. It uses only one more hop compared to HSv3's Tor2Web mode. Also the circuit length for HS5h's Tor2Web mode can be further reduced to 3 hops. (3) Less setup time on client side for the first connection. In HSv3, a client has to first setup a 3 hops circuit to RP before sending INTRODUCTION1 cell to the introduction point. While in HS5h, this process is removed. Possible drawback: (1) An extra step is needed: random number negotiation. This result ins more communication between two nodes and Introduction point needs to remember states for the negotiation. We think this negotiation step will not introduce a noticeable delay to the whole process. Firstly, it reuses the connection to introduction point for both sides so it requires no extra circuits build up. Secondly, the bottle neck is circuit setup, cell/stream transmission delay is actually pretty low. 2. Negotiate random numbers between two nodes [RAND_NEGO] H(a) here means digest of message a. (1) client generates a random number R_a and sends the digest H(R_a) to HS (2) HS remembers H(R_a), generates a random number R_h and sends it back to the client (3) client receives R_h and sends back R_a to HS (4) HS checks R_a against H(R_a) to make sure it's not generated after client receives R_h. (5) Now both client and HS compute a shared random number using R_a and R_c. (for instance, simply add up these two number) The negotiation protocol can be very simple here because only two parties are involved and the random number does not need to be remained secret. Note that at step 2), if HS is able to recover R_a from H(R_a), it can take control over R_c. So to mitigate this, we can use a variant of Diffie-Hellman handshake: (1) client generates a public key g^x and sends the digest H(g^x) to HS (2) HS remembers H(g^x), generates a public key g^y and sends it back to the client (3) client receives g^y and sends back g^x to HS (4) HS checks g^x against H(g^x) to make sure it's not generated after client receives g^y. (5) Now both client and HS compute a shared random number: R_c = g^(xy) 3. Rough anonymity analysis for HSv3 and HS5h 3.1. Assumptions, attack rules and constraints In this section, we assume 3 hops being the minimal circuit length to keep the origin node of a circuit anonymous from the destination. Two simple attack rules are used to remove nodes from a circuit: 1. If node A is picked by the attacker, then he can pick himself as node A. 2. If the identity of node A is known by the attacker, then he can connect directly to it. To defense against these attack rules, following constraints need to be enforced for a circuit: 1. No one except the circuit originator can have total control over choice of all nodes on the circuit. Note that it's OK even if the originator does not have total control. 2. Identity for all nodes on the circuit, except the last hop, must remain secret. i.e. only known by circuit originator. 3.2. Why 6 hops is the minimal circuit length for HSv3 First let's begin with an ASCII graph for HSv3 rendezvous circuit: Client -> (a1) -> (a2) -> (RP) <- (b3) <- (b2) <- (b1) <- HS Client chooses 3 ORs: a1, a2, RP. HS chooses the other 3 ORs: b3, b2, b1. Now consider HS as the malicious side. In order to get closer to client, the best it can do is to connect directly to RP, which reduces the circuit length to 3 hops: Client -> (a1) -> (a2) -> (RP) <- HS If client is the malicious side, the best it can do is to choose itself as RP, which also reduces the circuit length to 3 hops: Client <- (b3) <- (b2) <- (b1) <- HS Taking any node from the original 6 hops circuit will result in 2 hops circuit in either case. As noted above, 3 hops is assumed to be the minimal circuit length. 3.3. Why HS5h only needs 5 hops HS5h makes use of the fact that the last hop of a circuit is different from all previous hops. Since last hop will be in direct contact with the destination host, its identity does not need to be remain secret. We only have to make sure the last hop cannot be determined by any malicious host at will. Otherwise the malicious side can just pick himself as last hop and thus shorten the circuit. This is where hop negotiation come into play. A negotiated hop is guaranteed to be a random node and cannot be determined by anyone. So it can be used as the last hop for both client and HS. Since the last hop for both sides overlaps, it's effectively acting as a rendezvous point. In comparison, in HSv3, the rendezvous point is picked and controlled by the client. Therefore it can not be used as the last hop for HSs' rendezvous circuit. Again, following is an ASCII graph for a HS5h rendezvous circuit: Client -> (a1) -> (a2) -> (RP) <- (b2) <- (b1) <- HS Now if the client is malicious, it can only connects directly to the RP, i.e. pick the second last hop as himself. Therefore HS can still maintain a 3 hops distance from the malicious client: Client -> (RP) <- (b2) <- (b1) <- HS While in HSv3, the client can pick himself as the RP. And because this is a symmetric scheme, the same argument goes for malicious HS: Client -> (a1) -> (a2) -> (RP) <- HS Either cases, we maintained a 3 hops circuit. 3.4. Summary We took 3 as the minimal circuit length because that's the default setup in Tor. The analysis should work for any number. To generalize it, if N is the minimal circuit length, then: 1) without node negotiation, the minimal rendezvous circuit length is 2N. 2) with node negotiation, the minimal rendezvous circuit length is 2N-1. 4. Other possible speed optimization under HS5h 4.1 Optimistic rendezvous mode Similar to optimistic_data for AP connections, we can implement optimistic_rendezvous mode under HS5h. The basic idea is to optimistically assume any picked candidate RP will be willing to act as a RP. Since now we need to maintain state in introduction point to help with node negotiation, we can use it to communicate with HS when establishing the rendezvous circuit. So both client and HS can launch circuits to newly negotiated RP simultaneously. If this candidate RP refuses to be a rendezvous point to one side, the other side can be notified via introduction point. Then client and HS can go through the negotiation process again to pick a new candidate RP. This mode can also be implemented under HSv3 as well. In HSv3, wait for RENDEZVOUS_ESTABLISHED cell and sending INTRODUCE1 cell has to be a sequential operation. With optimistic_rendezvous mode, this can be done in parallel. NOTE: we need to test RENDEZVOUS_ESTABLISHED rate in real tor network. If the rate is low, then this mode will slow down the setup process instead. To make this mode work even better, we can have all OR explicitly mark whether it is willing to be a rendezvous point in it's descriptor. This should greatly increase the success rate for receiving RENDEZVOUS_ESTABLISHED. 5. Hazards a) How to design the scheme for mapping a random number to the same node between client and server? This will be trivia if it's easy to synchronize node list between two onion proxy. The problem is: how much overhead will be caused by synchronizing node list (or consensus). b) How much overhead will be introduced by maintaining state for node negotiation? Since in HS5h, both introduction point and hidden service need to maintain state for node negotiation. To do so, the client can send something like a negotiation identifier in the initial introduction request. Then for introduction point, it can mark the circuit from the client with this ID. For HS, it can hash the negotiation state structure into a hash table with ID as the key. Theoretically, this overhead should be low, because the "negotiation ID" is just like rendezvous cookie.

8 16

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev