- tor-dev - lists.torproject.org

Mockup for a hidden services publishing tool
by Matt Pagan 10 Mar '14

10 Mar '14

Please see the image file for what I have in mind here. http://oi62.tinypic.com/10x80ok.jpg I hope this tool, when completed, can help reduce the barrier for people seeking to set up hidden services. I anticipate this tool being able to connect to a running tor and write to that tor's torrc file. This tool will be able to connect to the network through a proxy, a standard bridge, or a pluggable transport. It will be able to send a HUP signal to tor. It will be able to read from tor's hidden service directory and tor's log. This mockup was made with wxPython 2.8. This is partially because I'm somewhat familiar with wxWidgets already, and partially because I thought incorporating stem might be a good plan. Here are some pitfalls and shortcomings: * * * By it's current design, this tool has less functionality than Vidalia. As a security property, there's no interface for setting up a relay. This tool's primary focus will be running a hidden service. By it's current design, this tool does not ship with any hosting software. The tool will inform the user that she still needs to run XAMPP or ApacheGUI to host a web page. There's no interface for setting up or designing a blog, only for hosting one that's already designed. I'm still investigating Python's multithreading capabilities so that the Tor log can be continuously read and reported. If I discovered that I didn't need a controller library at all, I'd consider using wxGo instead of wxPython (although writing in Go would be a new experience for me and would take longer). * * * Perhaps some or all of these shortcomings could be overcome given time and community feedback. I'm still not entirely sure where to take this project, if anywhere. Before I get much further with this idea, is this project worth pursuing at all? Does this look like something that could benefit Tor users, given that Vidalia still works for many people? Do you think this tool has potential to function as a point-click-publish hidden services software?

3 2

Re: [tor-dev] [tor-commits] [flashproxy/master] remove failed connections from proxy_pairs as well
by David Fifield 10 Mar '14

10 Mar '14

On Fri, Mar 07, 2014 at 02:39:18PM +0000, infinity0(a)torproject.org wrote: > commit 05b9c101ba9afe4653d1eff6f5414f90f22ef042 > Author: Ximin Luo <infinity0(a)torproject.org> > Date: Fri Mar 7 13:39:31 2014 +0000 > > remove failed connections from proxy_pairs as well > - this is a pretty major fix, as the previous behaviour effectively disabled a proxy after 5 failed connections (= max_num_proxy_pairs / 2) Can you say some more about the circumstances of this fix? What behavior changed for you after making it? I can't reproduce what's described in the commit message. With 9dea0c6c90dedc868dfaa84add2bfa19a2039281, I set up a phony facilitator with ncat -v -lk 7000 --sh-exec "./facilitator.py" where facilitator.py has the contents #!/usr/bin/env python import random import sys port = random.randint(10000,11000) print "HTTP/1.0 200 OK\r" print "Content-Type: application/x-www-form-urlencoded\r" print "Cache-Control: no-cache\r" print "Access-Control-Allow-Origin: *\r" print "\r" sys.stdout.write("check-back-in=10&client=127.0.0.1:"+str(port)+"&relay=173.255.221.44:9901") I then browse to file:///home/david/flashproxy/proxy/embed.html?debug&facilitator=http://127.0.0.1:7000&initial_facilitator_poll_interval=1&unsafe_logging&max_clients=2 All the "client" connections are going to closed ports, but the "Client: error" lines still appear and clients don't accumulate in the request URL. The same happens if I use an open port with a Ncat listener that just closes the connection. The same happens if I change to a non-listening Internet address like 1.1.1.1. 2014-03-10T16:28:48.173Z | Starting; will contact facilitator in 1 seconds. 2014-03-10T16:28:49.179Z | Facilitator: connecting to http://127.0.0.1:7000?r=1&transport=websocket. 2014-03-10T16:28:49.203Z | Next check in 10 seconds. 2014-03-10T16:28:49.204Z | Facilitator: got client:{ host: "127.0.0.1", port: 10782 } relay:{ host: "173.255.221.44", port: 9901 }. 2014-03-10T16:28:49.205Z | 127.0.0.1:10782|173.255.221.44:9901 : Client: connecting. 2014-03-10T16:28:49.206Z | 127.0.0.1:10782|173.255.221.44:9901 : Client: connecting. 2014-03-10T16:28:49.207Z | 127.0.0.1:10782|173.255.221.44:9901 : Client: error. 2014-03-10T16:28:49.208Z | 127.0.0.1:10782|173.255.221.44:9901 : Client: closed. 2014-03-10T16:28:49.209Z | Complete. 2014-03-10T16:28:49.209Z | 127.0.0.1:10782|173.255.221.44:9901 : Client: error. 2014-03-10T16:28:49.209Z | 127.0.0.1:10782|173.255.221.44:9901 : Client: closed. 2014-03-10T16:28:49.210Z | Complete. 2014-03-10T16:28:59.205Z | Facilitator: connecting to http://127.0.0.1:7000?r=1&transport=websocket. 2014-03-10T16:28:59.226Z | Next check in 10 seconds. 2014-03-10T16:28:59.227Z | Facilitator: got client:{ host: "127.0.0.1", port: 10221 } relay:{ host: "173.255.221.44", port: 9901 }. 2014-03-10T16:28:59.227Z | 127.0.0.1:10221|173.255.221.44:9901 : Client: connecting. 2014-03-10T16:28:59.227Z | 127.0.0.1:10221|173.255.221.44:9901 : Client: connecting. 2014-03-10T16:28:59.229Z | 127.0.0.1:10221|173.255.221.44:9901 : Client: error. 2014-03-10T16:28:59.229Z | 127.0.0.1:10221|173.255.221.44:9901 : Client: closed. 2014-03-10T16:28:59.230Z | Complete. 2014-03-10T16:28:59.230Z | 127.0.0.1:10221|173.255.221.44:9901 : Client: error. 2014-03-10T16:28:59.230Z | 127.0.0.1:10221|173.255.221.44:9901 : Client: closed. 2014-03-10T16:28:59.231Z | Complete. 2014-03-10T16:29:09.227Z | Facilitator: connecting to http://127.0.0.1:7000?r=1&transport=websocket. 2014-03-10T16:29:09.249Z | Next check in 10 seconds. 2014-03-10T16:29:09.250Z | Facilitator: got client:{ host: "127.0.0.1", port: 10069 } relay:{ host: "173.255.221.44", port: 9901 }. Now what *does* seem to be happening, and what had me confused for a while, is that Firefox seems to be artificially delaying repeated WebSocket connections to the same port with some kind of exponential delay. I originally had a hardcoded port in facilitator.py, and the delay made it appear that something like what the commit message describes was happening. Since WebSocket connections eventually start waiting a long time to fail, it looks like they are not being closed. https://people.torproject.org/~dcf/graphs/firefox-exponential-delay.png is a screenshot showing what looks like exponential growth in the Network panel. Chromium doesn't appear to have the same issue; the requests are linearly spaced in the network pane. Are you able to confirm any of the above? When you discovered the bug, were you testing with Firefox or Chromium? How did you find the bug, and what did you do (differently from the above) to reproduce it? In any case, what's going on must be different than what's described in the commit message, because even before the fix the proxy continues running for me with max_clients=2. David

2 2

Weekly Tor dev meeting: Wednesday March 12, 20:00 UTC
by Nick Mathewson 10 Mar '14

10 Mar '14

Hi, all! This is another developer's meeting for working on the program "tor". (This won't cover all the other programs developed under the Tor umbrella.) We're going to try doing the weekly meeting on Wednesday, so it can go right after the TBB meeting. The meeting time will be: Wednesday March 12, 20:00 UTC. (That's 3pm EST and 12:00 noon PST) As before, we'll do it on the #tor-dev IRC channel, unless the meeting turns out to be too disruptive for the rest of the channel or vice versa. peace, -- Nick

3 2

GSOC Proposal - Improving test coverage for tor
by Punit 10 Mar '14

10 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I am Punit Singh, and I have been working on Chutney for the past one week. I have already expressed my interest [1] in participating in GSOC this year for the project - Improving test coverage in tor. I have made some changes to the code base of Chutney, including completing some TODO tasks. The code can be found here. [2] I am currently in the process of completing the proposal for the project. Here are the things I have done - 1. I am now able to understand the code base of Chutney. 2. I have read parts of the Tor specification [3], not the complete document. 3. I have computed the test coverage of tor, and have seen that some parts of the code are totally untested. [4] 4. I know about unit tests and integration tests, how to write them, how to write testable code, and so on. I wanted some pointers as to how should I choose which function to write unit test for (with reference to the application requirement), and how should I go about writing the unit test (I know that I have to script individual clients using Stem, I just needed some guidance how to execute individual functions in the C code from Stem). I am really interested as well as enthusiastic to work on this. I just need a little guidance. Please correct me if I am thinking in the wrong direction. Thanks, Punit References - [1] https://lists.torproject.org/pipermail/tor-dev/2014-February/006317.html [2] https://github.com/punitkoura/chutney Branch : changes [3] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.t… [4] command.c circuitmax.c circuituse.c compat_libevent.c connection.c connection_edge.c -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHMVoAAoJEEBFGwew+1S1b2MH/1X0N+0sBl6tXiZ0w6FyWS2r MIGAN+IwvxTGOdHtk3/8926buSWAtCzhoW8XQX7IWOPDtPMQtQ9PqwhTDFRjl0tz MaHtXSfY6qOu8HToe6rJrVWiJxM+mP/v4VSLQ/tdKb5pl7AVwlli3xQnE0Qnu0UI ibOSROe9yBBtxzG2jdA5xxvlTuyUK2e5OKEjHA+qjCAXrJXqri5Zs0Kx1BYQRb2r K430hSaKAi74zw7abRjmeUXuuvWs1KJTWf7KtPcv6bjwIsO+sR5aiEL/bxQ8mAxC lB4+pKWsbW/X12BlbtY44TjUgX42kXNNq7GxyEqyYFCFuu82tVXVh3TMMH+qSs8= =ZxRG -----END PGP SIGNATURE-----

3 2

Novel distribution mechanisms (was: "s3 alternatives" on libtech)
by Griffin Boyce 10 Mar '14

10 Mar '14

Nathan of Guardian wrote: > Github? Maybe not whole sites, but specific files. I've been working with users who have networks in censored countries to expand access to specific software bundles (not just Tor). My two approaches right now are Google Web Store and torrents attached to a stable offsite seedbox. Both are fairly accessible, but both have pros/cons. With torrents, someone can sit as a seeder and try to tally information on downloaders. Google Web Store downloads are tracked in unknown (legally requestable?) ways by Google and of course it requires downloading/installing Google Chrome to gain access.[1] It's not perfect, but at least for the user groups I talk to, they are realistic solutions to a really tricky problem. ~Griffin [0] cross-posted upon recommendation of David Fifield [1] most users can't figure out how to download extensions manually

3 4

Another fake key for my email address
by Erinn Clark 09 Mar '14

09 Mar '14

Hi everyone, In September last year I discovered a fake key for my torproject.org email address[1]. Today I discovered another one: pub 2048R/C458C590 2014-02-13 [expires: 2018-02-13] Key fingerprint = 106D 9243 7726 CD80 6A14 0F37 B00C 48E2 C458 C590 uid Erinn Clark <erinn(a)torproject.org> sub 2048R/D16B3DB6 2014-02-13 [expires: 2018-02-13] To reiterate what I said last time this happened: 1. That is NOT MY KEY. Do not under any circumstances trust anything that may have ever been signed or encrypted with this key. I looked around and was unable to find anything, but nonetheless, it is out there and that is creepy. 2. If anyone on any of these lists has encountered this key anywhere -- the main fear being that it has been used to fraudulently sign packages of some kind -- can you please let me/us know ASAP? Tor Project official signatures are listed here: https://www.torproject.org/docs/signing-keys.html.en Consider that the canonical source for all signatures! Be suspicious of anything not listed there and let us know if you ever find anything. I want to note here that last year I created a new key which also belongs to me and I just haven't switched to yet. I am not signing any Tor packages whatsoever with this key, but it does belong to me and has several signatures from people I've met in person, some of whom also signed my old/current (63FEE659) key: pub 4096R/91FCD12F 2013-09-21 Key fingerprint = 724B 96C1 997A E999 F0C0 0F8A F8F4 9DD8 91FC D12F uid Erinn Clark <erinn(a)torproject.org> uid Erinn Clark <erinn(a)double-helix.org> uid Erinn Clark <erinn(a)debian.org> sub 4096R/1B749632 2013-09-21 With declining trust in the web of trust, Erinn [1] https://lists.torproject.org/pipermail/tor-talk/2013-September/029752.html

1 0

[draft]: Proposal xxx: Pluggable transport SOCKS5 extensions
by Yawning Angel 08 Mar '14

08 Mar '14

Hello all, To address bug #10671: "Pluggable Transports: Improve method of transferring parameters to client-side transports", I submit the enclosed proposal for consideration. --- Begin proposal body --- Filename: xxx-pt-socks5-extensions.txt Title: Pluggable transport SOCKS5 extensions Author: Yawning Angel Created: 25-Feb-2014 Status: Draft 0. Abstract We propose extending the SOCKS5 protocol when communicating with pluggable transports to allow passing more per-bridge meta-data to the transport and returning more meaningful connection failure response codes back to Tor. 1. Introduction To allow for more sophisticated pluggable transports, it would be useful to support more than 510 bytes of per-connection data, while using the SOCKS5 pluggable transport interface. Additionally as pluggable transports increase in sophistication, it is useful for the pluggable transport to be able to return well defined errors back to Tor if the connection establishment fails. 2. Proposal 2.1. Tor Pluggable Transport Username/Password Authentication We introduce a new authentication method to the SOCKS5 protocol based on the existing RFC 1929 Username/Password Authentication that pluggable SHOULD support. The METHOD number to be returned to indicate support for or select this method is X'80', which belongs to the "RESERVED FOR PRIVATE METHODS" range in RFC 1928. After the authentication method has been negotiated following the standard SOCKS5 protocol, the actual authentication phase begins. Tor will send a Username/Password/Extended Data request: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Username Len | +---------------+---------------+ \ Username \ / ... / \ (Username Len bytes) \ +---------------+---------------+ | Password Len | \ +---------------+ / \ Password \ / ... / \ (Password Len bytes) \ +---------------+---------------+ | Extended Data Len | +---------------+---------------+ \ Extended Data \ / ... / \ (Extended Data Len bytes) \ +---------------+---------------+ Version: 8 bits (unsigned integer) This field specifies the version of the authentication method. It MUST be set to X'01'. Username Len: 8 bits (unsigned integer) This field specifies the length of the Username field in bytes. It MAY be X'00', in which case the Username field is omitted. Username: variable length, optional The Username to use when authenticating. Password Len: 8 bits (unsigned integer) This field specifies the length of the Password field in bytes. It MAY be X'00', in which case the Password field is omitted. Password: variable length, optional The Password to use when authenticating. Extended Data Len: 16 bits (unsigned integer) This field specifies the length of the Extended Data field in bytes. It MAY be X'0000', in which case the Extended Data field is omitted. The Extended Data Len field MUST be transmitted in network byte order. The pluggable transport verifies the supplied Username, Password, and Extended Data and sends the following response: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Status | +---------------+---------------+ Version: 8 bits (unsigned integer) This field specifies the version of the authentication method. It MUST be set to X'01'. Status: 8 bits (unsigned integer) This field specifies the status of the authentication request. A Status of X'00' indicates 'success'. If the pluggable transport returns a 'failure' (Status value other than X'00'), it MUST close the connection. 2.2. Tor Pluggable Transport SOCKS5 Reply Codes We introduce the following additional SOCKS5 reply codes to be sent in the REP field of a SOCKS5 reply message. Where: * X'F0' Temporary failure, retry immediately Pluggable transports SHOULD return this status code if the connection attempt failed, but the pluggable transport believes that subsequent connections with the same parameters are likely to succeed. Example: The ScrambleSuit Session Ticket handshake failed, but reconnecting is likely to succeed as it will use the UniformDH handshake. * X'F1' Pluggable transport protocol failure, invalid bridge Pluggable transports MUST return this status code if the connection attempt failed in a manner that indicates that the remote peer is not likely to accept connections at a later time. Example: The obfs3 handshake failed. * X'F2' Pluggable transport internal error Pluggable transports SHOULD return this status code if the connection attempt failed due to an internal error in the pluggable transport implementation. Tor might wish to restart the pluggable transport executable, or retry after a delay. 3. Compatibility SOCKS5 negotiates authentication methods so backward and forward compatibility is obtained for free, assuming a non-broken SOCKS5 implementation in the pluggable transport side that ignores unrecognised authentication methods in the negotiation phase. The extended status codes are informative clarifications of a failure state, so existing Tor binaries will continue existing behavior for a general failure. 4. Security Considerations Identical security considerations to RFC 1929 Username/Password authentication applies. As the Username/Password fields are carried in cleartext, this authentication method MUST NOT be used in scenarios where sniffing is possible. The authors of this proposal note that pluggable transports bind to the loopback address, so in the current model this is believed to be acceptable. 5. Open Questions Is 65535 bytes of per-bridge/per-connection data sufficient? Pluggable transports currently have no notion of authentication due to the Username/Password fields of the RFC 1929 authentication method being hijacked to convey extended data. Is this a feature that will be implemented in the future? 6. References Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., Jones L., "SOCKS Protocol Version 5", RFC 1928, March 1996. Leech, M. "Username/Password Authentication for SOCKS V5", RFC 1929, March 1996. Appelbaum, J., Mathewson, N., "Pluggable Transport Specification", June 2012. --- End proposal body --- Questions, comments, feedback appreciated. -- Yawning Angel

5 11

Guard node security: ways forward (An update from the dev meeting)
by George Kadianakis 08 Mar '14

08 Mar '14

A main theme in the recent Tor development meeting was guard node security as discussed in Roger's blog post and in Tariq's et al. paper [0]. Over the course of the meeting we discussed various guard-related subjects. Here are some of them: a) Reducing the number of guards to 1 or 2 (#9273). b) Increasing the guard rotation period (to 9 months or so) (#8240). c) The fact that your set of guard nodes can act as a network fingerprint even if you switch to different networks (#10969). d) The fact that authorities assign flags based on knowledge they acquired while they were up. They don't use historical data to assign flags, which means that an authority thas has been up for 1 month, only knows 1 month worth of information about each relay (#10968). e) We discussed introducing a weight parameter that makes guards that have been guards for a long time, be more likely to be used as guards. f) We discussed how guards and circuit isolation should work together. Maybe each isolation profile should have a different set of guards. But what if we have hundreds of isolation profiles (we are the gateway of a network)? g) Should we refuse to add new guards after a certain number of circuits have been killed (maybe it's an attack). But won't that drive our users to simply reinstall Tor because they think it's broken? h) We discussed chaining consensus documents together as in a block chain. This could help against targetted attacks where a set of bad authorities give a poisoned consensus to a user. This design has many problems though (how much data do we have to keep forever each consensus? what happens in periods where no consensuses were published?) i) If we restrict the number of guards to 1, what happens to the unlucky users that pick a slow guard? What's the probability of being an unlucky user? Should we bump up the bandwidth threshold for being a guard node? How does that change the diversity of our guard selection process? j) How do the above influence the security of Hidden Services? Guard security is essential for the well-being of Hidden Services, but how does increasing the guard rotation period combine with guard enumeration attacks (#9001)? We discussed more topics too. You can find Nick's raw notes at: https://trac.torproject.org/projects/tor/wiki/org/meetings/2014WinterDevMee… To move forward, we decided that proposals should be written for (a) and (b). We also decided that we should first evaluate whether doing (a) and (b) are good ideas at all, especially with regards to (i). [0]: https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-pa… http://freehaven.net/anonbib/#wpes12-cogs

5 13

Hidden service search engine (GSoC)
by Rémi 08 Mar '14

08 Mar '14

Hy, I am currently a master student with a focus on natural language processing, machine learning, information retrieval and data mining. The Tor website lists a bunch of ideas, one of which is "Search Engine for Hidden Services"[1]. This project suits me well given my education and skill set and I would really enjoy it. Does tor-dev think this would be a good project? There are already many hidden search engines, although non are open source. I have done two smaller information retrieval projects in university this year, and I have a strong background in search engine algorithms. The components of the system that I am currently thinking of are: - index and features in a nosql database (possibly CodernityDB) - hidden service crawler - simple search using BM25, but recording click through and many features other than BM25. - Basic front-end. - A component for 'Learning to rank' based on more features, which should be used once there is significant click-through data. This should be an easy to use program that performs search engine optimization. The recording of the click through is done in order to learn to search better. This is important because there is no known search ranker that will give excellent results out of the box. Click through recording can be done by only recording feature weights. I would work in Python because I am very comfortable working with it. What are your thoughts? R. P.S. I would also love to do the traffic confirmation attack, but as far as I understand there is no good data set that is readily available, and making + using one will be beyond the scope of GSoC. [1] https://www.torproject.org/getinvolved/volunteer.html.en#Coding

2 1

Accessing hidden services with TAP or ntor
by Jens Kubieziel 07 Mar '14

07 Mar '14

Hi, we had some discussions during the dev meeting regarding hidden services and why users sometimes report that the access to them fails. The general problem might be that the specific hidden service doesn't exist anymore. However in some cases the HS exists (see <URL:http://tor.stackexchange.com/q/1442/88> as an example). So one theory was that the transistion from TAP to ntor might cause problems. I tried to test it and found no evidence so far. What did I do? I checked out the current Tor source from git and the tor-0.2.3.25 tagged version. I built both versions and gave them a minimal torrc (SocksPort, Log, DataDir, ControlPort). After the Tor process built a circuit I used a random page from the hidden wiki and tried to access it. If it failed, I tried either the HS from TorProject or DDG. If it succeeded, I built a new circuit and tried another HS. During the first tests I used the hotel network, which was kind of flaky. With a more stable connection I tested nearly 20 hidden services and found no difference in the behaviour of both Tor versions. Both failed on one random HS and opened all other reasonably fast. While this is no final proof it is good evidence that there is no connection between failing hidden services and TAP/ntor. So maybe we need another theory to test. ;) -- Jens Kubieziel http://www.kubieziel.de I just found out that the brain is like a computer. If that's true, then there really aren't any stupid people. Just people running Windows.

3 3