- tor-dev - lists.torproject.org

Composing multiple pluggable transports
by Ximin Luo 18 Jun '14

18 Jun '14

Hi Steven, Nikita, I was told that you two are interested in the idea of composing multiple PTs together. Here are our ideas on it. We have a GSoC student, Quinn also at Illinois, working on turning this into reality. ## Concepts On the most abstract level, pt-spec.txt defines an "input interface" to some generic component. It consists of the following: - dest addr, of the Bridge - headers/metadata, such as fingerprint[1] or other PT-level settings - data, the actual application-layer stream, such as OR protocol The concrete form of this is the SOCKS protocol, which allows tor to make a request with the above interface. (Actually, SOCKS does not fully support metadata, which means we've had to extend it ourselves. HTTP might have worked better.) pt-spec.txt does not specify the "output interface". This means it's impossible to chain general PTs, because there's nothing defined to chain. To work around this, we observe that in practise, many PTs follow the below "output interface"; we'll call these "direct PTs": - data, sent directly to the (TCP) address given at the input Direct PTs include obfsproxy, scramblesuit, fteproxy. Indirect PTs are all other PTs, that do something different other than a straight TCP connection *to the endpoint Bridge address*. These include flashproxy and meek. ## Design Our combiner will chain up a sequence of direct PTs, then the last PT can be any PT (either direct or indirect). So for example it could potentially support obfs3|fte|fte|fte|flashproxy and obfs3|fte but not flashproxy|obfs3|obfs3|meek. Not every chain makes sense from a security viewpoint, of course. Because the output interface (TCP) does not exactly match the input interface (SOCKS), we have a component called a "shim", which has an input interface of TCP and an output interface of SOCKS. This is placed between each pair of PTs in the chain. In simple terms, it works like this: pt0 (out) -TCP-> (in) shim1 (out) -SOCKS-to-next-shim-> pt1 -> to shim2 The extra info present in SOCKS (dest addr and metadata) absent from TCP, will be supplied by the combiner, as described in the next section. Also, in practise, these shims are within the same process as the combiner, there is no need to start a new process for these. ## Algorithm Let the ith PT be listening on port pPT[i], done at program start. Later, when tor wants to connect to a PT-chain, we intercept this connection, extracting the following information (the SOCKS in-interface): - dest addr, of the Bridge - headers. generic headers, plus PT-specific headers for each PT in the chain[2] - data, OR protocol Then, the combiner starts a new shim, one for each component in the chain, each listening on pS[i]. Each shim[i] is set-up so that when it receives a connection on pS[i], it tells PT[i] (i.e. the SOCKS client listening on pPT[i]) to connect to pS[i+1], with the metadata set to the generic headers plus specific headers for PT[i], and the data set to whatever it receives from the connection. (In practise the shims are set-up in reverse order, because shim[i] needs to know what pS[i+1] is, and we want to take advantage of OS's feature to "listen on any port".) Special cases: - The last (i.e. (n-1)th) shim tells its SOCKS client to connect to the original dest addr, of the Bridge - there is no pS[last+1]. - The first shim does not need to exist, since the combiner is just sending data to itself so can do this in-process After all the shims are set up, the combiner starts forwarding data from tor over onto PT[0]. Then the magic is complete. ASCII diagram, minus annotations about metadata: +----------+ socks | PT | [ tor ] to >-------> | combiner | bridge +-< | | | +----------+ in-process | v +-------+ socks | direct| tcp to >-> | PT[0] | to >-+ pS[1] | | pS[1] | +-------+ | +-------------------<-------------------+ | +-------+ | socks | direct| tcp +->[ shim[1] ] to >-> | PT[1] | to >-+ pS[2] | | pS[2] | +-------+ | +-------------------<-------------------+ | | [etc] | | +-------------------<-------------------+ | +-------+ | socks | direct| tcp +->[ shim[y] ] to >-> | PT[y] | to >-+ pS[z] | | pS[z] | +-------+ | +-------------------<-------------------+ | +-------+ | socks | any | +->[ shim[z] ] to >-> | PT[z] | whatever it wants --> bridge | | +-------+ Note that, if for whatever reason your chain has the same PT in multiple positions, the chain will re-use the same PT process. Everything should still work, because we have separate *shims* for each *position* that the PT appears within the chain. X [1] fingerprint not actually currently given to PTs by tor; but it should be for reasons argued elsewhere [2] we haven't exactly defined a format for this, but perhaps something like k=v for generic headers to all children (as currently), and x-chain-0-k=v for PT-specific headers, and maybe even something like x-chain-0onwards-k=v. -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git

2 1

Reminder: tor dev meeting this (and every) Wednesday, 1900 UTC
by Nick Mathewson 17 Jun '14

17 Jun '14

Hi, all! Here's your regular reminder for the weekly IRC meeting for people working on the program "tor". (This won't cover all the other programs developed under the Tor umbrella.) The next meeting time will be: Wednesday June 18, 19:00 UTC. (That's 3pm EDT and 12:00 noon PDT.) As usual, we'll do it on the #tor-dev IRC channel. I've seen a drop-off in the number of people coming since I stopped sending these out weekly, so I'm sending them again for a while. Among other stuff, I expect we'll be looking at tickets for 0.2.6.x. cheers, -- Nick Mathewson

1 0

ANN: OnionPy 0.1.5
by Lukas Erlacher 17 Jun '14

17 Jun '14

Hello all, my OnionOO python wrapper has now matured significantly. While I was gone for around a month due to being otherwise occupied, I have now given OnionPy a lot of polish. The new features: - Python2 compatibility (All it took for that was to change the readme) - Encapsulated caching layer that includes a memcached interface as well as a simple python dict caching mechanism, or you can add glue code for your favourite caching backend yourself - It's on Pypi! [1] - Extended test / demonstration script Many thanks to meejah for his help. If you are planning to make something in python that uses the tor network status, accessing OnionOO [2] using OnionPy might be exactly what you need. If you are interested, check out the repo and readme! [3] Of course, criticism, suggestions, and pull requests are always welcome. Best regards, Luke [1] https://pypi.python.org/pypi/OnionPy [2] https://onionoo.torproject.org/ [3] https://github.com/duk3luk3/onion-py

2 3

Running Tor with static path
by mahdi 16 Jun '14

16 Jun '14

Hi all, I want to execute an experiment on Tor in which i need to fix the ip address of entry,relay and exit onion router. For that i need to determine the IPs and keys of ORs in OP permanently. Is there any idea of what function of Tor's code should be replace?! Thanks a lot

4 3

Re: [tor-dev] [HTTPS-Everywhere] GSoC report - Zack Mullaly - HTTPS Everywhere secure ruleset update mechanism
by Yan Zhu 15 Jun '14

15 Jun '14

(Trying again with my tp.o email address) On 06/15/2014 02:05 PM, Yan Zhu wrote: > It's unclear whether this message went through to tor-dev (can't find it > in the archives), but I've added this update to > https://trac.torproject.org/projects/tor/wiki/doc/gsoc. > > On 06/13/2014 05:06 PM, Red wrote: >> Hello, everyone! >> I apologize for the fact that this is coming in late, but here is a >> summary of my progress and plans thus far in developing a secure ruleset >> update mechanism for the HTTPS Everywhere browser extension. >> >> The specification document detailing how the ruleset updater will >> function has been perhaps the greatest focus for me until now. The >> document is currently hosted on Github as a gist[1], and currently >> details the format for the JSON document the extension will fetch to >> determine whether the update information it receives is authentic and >> relevant. >> >> A second task I have been working on is the creation of a utility[2] >> used to automate much of the process of building the update.json file >> contents outlined by [1]. A lot of the work done here so far has been >> experimental, but it is already providing some utility for composing >> data that can be used for testing purposes. >> >> The third thing I have been working on is the actual implementation of >> the ruleset updater[3]. There are to be some changes to the spec that >> will be reflected in this code in the coming week, but the >> implementation so far is very close to being ready to test. >> >> In the last week, a lot of discussion has occurred centered around >> improving the specification for the ruleset update mechanism and how the >> update.json file and signing thereof should function and be written. I >> have posted my weekly meeting notes to another gist[4] which I will from >> today onwards be keeping up to date with my weekly notes so that they >> will be publicly available and well-formatted. In summary, my upcoming >> work will involve updating the update.json spec to reflect the >> discussion being had on the https-everywhere mailing list and between >> myself and my mentor, Yan. I will then focus on updating the extension >> code as well as the utility I have been working on to reflect the >> changes to the spec. I will then move on to testing the signature >> verification method locally by creating example documents and a Python >> script to verify the signature. I will also be setting up a testing >> environment to properly test my work on the ruleset update mechanism. >> >> My work can be more closely followed on Github- specifically, my fork of >> the official HTTPS-Everywhere repository[5]. The code I have been >> working on resides in my "makeJSONManifest" and "rulesetUpdating" >> branches. You can also follow the discussion on the https-everywhere >> mailing list, and are welcome to join in mine and Yan's weekly meetings >> in #https-everywhere on irc.oftc.net at 11:00AM Pacific Time on >> Fridays. We're happy to have people chime in with ideas, and commentary >> in IRC, the mailing list, and on Github is welcome! >> >> [1]: https://gist.github.com/redwire/2e1d8377ea58e43edb40 >> [2]: >> https://github.com/redwire/https-everywhere/blob/makeJSONManifest/utils/rul… >> [3]: >> https://github.com/redwire/https-everywhere/blob/rulesetUpdating/src/chrome… >> [4]: https://gist.github.com/redwire/b62f03905a826e79947a >> [5]: https://github.com/redwire/https-everywhere >> >> >> >> _______________________________________________ >> HTTPS-Everywhere mailing list >> HTTPS-Everywhere(a)lists.eff.org >> https://lists.eff.org/mailman/listinfo/https-everywhere >> > > -- Yan Zhu <yan(a)eff.org>, <yan(a)torproject.org> Staff Technologist Electronic Frontier Foundation https://www.eff.org 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x134

1 0

Shutting down relay-search service shrinks metrics database by almost 97%
by Karsten Loesing 15 Jun '14

15 Jun '14

Hi devs, I have been planning to shut down the relay-search service, that was part of the metrics website, for about half a year, and now it's gone: https://lists.torproject.org/pipermail/tor-dev/2013-December/005948.html https://metrics.torproject.org/relay-search.html It was a good service. The main reason for shutting it down was that it required us to keep a full database of relays. And the Tor network has grown quite a bit over time. Now that the service is gone I was finally able to clean up the metrics database. Here are some numbers from before and after the cleanup with all sizes being rounded GiB: table | before | after --------------+---------------- bwhist | 13 | 0 descriptor | 6 | 0 dirreq_stats | 10 | 0 statusentry | 67 | 2 ... | | ------------------------------- total | 95 | 3 So, 92 of 95 GiB are gone, simply because we don't need that data anymore. That's much more than I had expected. Almost 97%! Just in case, and I'm going to watch over this, too: if the metrics website shows you funny numbers in the next couple of days, please let me know. All the best, Karsten

1 0

ANN: txtorcon 0.10.0
by meejah 15 Jun '14

15 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm excited to announce txtorcon 0.10.0 which adds support for Twisted's endpoint strings. This means that ANY Twisted program that uses endpoints can accept "onion:" strings to bring up a hidden services easily (by launching a new Tor instance). Typically, no code changes to the application should be needed (just "pip install txtorcon"). "twistd" supports endpoints, so for example to serve some Web content from ~/public_html as a hidden-serivce, we can do this (with txtorcon installed): twistd web --port onion:80 --path ~/public_html Some examples of other valid "onion:" endpoint strings: onion:80:hiddenServiceDir=/dev/shm/hidsrv onion:80:controlPort=9050:hiddenServiceDir=/srv/hidden The first allows specifying existing hidden service keys and the second says to connect to an already-running Tor instance. Thanks to David Stainton (dawuud) for the initial pull-request (and continued collaboration) that made this happen. There is a complete demonstration of the power of this Fully Operational endpoint-station here: https://txtorcon.readthedocs.org/en/latest/howtos.html#endpoints-enable-tor… You can download the release from PyPI or GitHub (or of course use "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.10.0 https://github.com/meejah/txtorcon/releases/tag/v0.10.0 sha256sum reports: 910ff3216035de0a779cfc167c0545266ff1f26687b163fc4655f298aca52d74 txtorcon-0.10.0-py2-none-any.whl c93f3d0f21d53c6b4c1521fc8d9dc2c9aff4a9f60497becea207d1738fa78279 txtorcon-0.10.0.tar.gz thanks, meejah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTnTM5AAoJEMJgKAMSgGmnB5EIAIJACHhd7PEWYfCZmB8lL1pr J4rrhUuXD1iI7zJJL/rmS/SZLL+34JoKke6iQsBRGYzU0GRK2JQkFAeMq++AMdMu QvoTg745OhnMSbZyCyS6buN/NhAVcmD3GYI9h8TK60jfUPEFn7+sDstMG4OePdgq X0QQHBuJq9XtDwEmRWFHq2Aht//7J2DUliPPjtwT3C4FhPT5pXxasvfQA4jOYxsO jTja6UE4/4TnonV5gB/chijp60cKvVxFQi86mKuNnVaKTZu+QCZFJtXkr/DbRSxv CJ+z7jJ9s8xhfQ5Nkv9pkVAreH6w9bemc/iijKlZmQGYvLBTsvISPATyWGtn1f4= =wIVZ -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] Tor Cloud maintenance - Question
by Sina Rabbani 13 Jun '14

13 Jun '14

Dear Team, I started building new images for Amazon EC2, as of last night. I noticed that obf2 and obf3 ports are hard-coded and the same for all Tor instances on Amazon. Is there a specific reason for this? If not, can I randomize the ports? All the best, SiNA On 2014-06-11 23:50, Karsten Loesing wrote: > Hi Sina, > > please find the following conversation below from #tor-project. Any > thoughts? > > Thanks, > Karsten > > > 06:43:15 < Lunar^> We really need a maintainer for Tor Cloud. Thre's > some of the support tickets we are getting I have > no idea how to answer… > 06:45:20 < karsten> > > https://trac.torproject.org/projects/tor/wiki/org/operations/Infrastructure > says inf0 and Runa are the maintainers. > 06:45:55 < karsten> is that not the case? should we mark it as > unmaintained and threaten to turn it off three > months later? > 06:47:01 < arma1> sina said he would pick it up > 06:47:04 < arma1> but i don't know that he ever did > 06:47:13 < karsten> sina = inf0? > 06:47:18 < arma1> perhaps karsten could mail him and ask if he is > maintaining it or if we should turn it off? > 06:47:19 < arma1> yes > 06:47:28 < karsten> sure, I can do that. > 06:47:57 < arma1> thanks! -- "be the change we wish to see in the world." Gandhi

2 3

Re: [tor-dev] Proposal for improving social incentives for relay operators
by Virgil Griffith 11 Jun '14

11 Jun '14

> Also, theconcept of naming authorities is about to be phased out [1], so > better not build new services that rely on nicknames. Karsten I love you. Not only do you have fine ideas, you are the greatest feedback provider in the world. Agreed 100%. Replace key-by-nickname with key-by-fingerprint. Not crazy about having a a separate Torati name space, but meh, you do what you have to. Maybe make the nicknames a version 2.0 feature. (Could always make a namespace integration with google+! Har.) > Okay. See Andrew's concerns about avoiding words having "Tor" in them. I will find a name that doesn't explicitly invoke Tor. -V

1 0

Typo in torspec.git/control-spec.txt
by Frithjof 11 Jun '14

11 Jun '14

Hi, the Tor control protocol spec says in §4.1 about asyncrhronous replies: > These replies can be sent after a corresponding SETEVENTS command has been > received. They will not be interleaved with other Reply elements, but they > can not appear between a command and its corresponding reply. > > C: SETEVENTS CIRC > S: 250 OK > C: GETCONF SOCKSPORT ORPORT > S: 650 CIRC 1000 EXTENDED moria1,moria2 > S: 250-SOCKSPORT=9050 > S: 250 ORPORT=0 If I am not reading the example wrongly, the negation in the last sentence is wrong, e.g. diff --git a/control-spec.txt b/control-spec.txt index 2dde043..70ddf3b 100644 --- a/control-spec.txt +++ b/control-spec.txt @@ -1253,7 +1253,7 @@ These replies can be sent after a corresponding SETEVENTS command has been received. They will not be interleaved with other Reply elements, but they - can not appear between a command and its corresponding reply. For example, + can appear between a command and its corresponding reply. For example, this sequence is possible: Cheers, Frithjof

2 1