November 2014 - tor-dev - lists.torproject.org

Stem roadmap, and ideas for the interpreter?
by Damian Johnson 21 Nov '14

21 Nov '14

Hi Nick. While sipping my morning coffee I just realized that you might not be aware of my sinister long schemes, and that might be to the detriment of us both. The roadmap I have for myself goes something like... Step 1: Write Stem so we have a well tested, stable controller library. (Done [1]) Step 2: Write a control interpreter to greatly simplify low level controller troubleshooting. (Done [2]) Step 3: Rewrite arm, both simplifying the codebase and smoothing the rough edges that have confused users for years. (In progress, gonna keep me busy for the better part of a year) Step 4: Write a web interface similar to arm, so relay operators can have a nice monitor by going to localhost. [3] I bring this up because honestly we don't communicate much. I don't know core tor's long term plans, and I get the impression you don't know much about Stem either. My hope had been that at step #3 we'd start bundling arm and Stem with the Tor relaying bundle, providing users both a terminal monitor and the tor-prompt command. But since we axed that with the removal of Vidalia I suppose I'll need to hit step #4 before proposing that we re-introduce those bundles (... and by extension making it so Windows and OSX users can once have an easy option for relaying). Have you ever used Stem's tor-prompt before? https://stem.torproject.org/tutorials/down_the_rabbit_hole.html If not then I'd appreciate input so this can be a useful tool to you before proposing that we make it more widely available. Cheers! -Damian PS. More general ideas on directions to take Stem, the tor-prompt, and this whole space are also welcome both from you and the list! [1] https://stem.torproject.org/ [2] https://stem.torproject.org/tutorials/down_the_rabbit_hole.html [3] https://www.torproject.org/getinvolved/volunteer.html.en#relayWebPanel

1 0

Hidden Service authorization UI
by George Kadianakis 21 Nov '14

21 Nov '14

Hidden Service authorization is a pretty obscure feature of HSes, that can be quite useful for small-to-medium HSes. Basically, it allows client access control during the introduction step. If the client doesn't prove itself, the Hidden Service will not poroceed to the rendezvous step. This allows HS operators to block access in a lower level than the application-layer. It also prevents guard discovery attacks since the HS will not show up in the rendezvous. It's also a way for current HSes to hide their address and list of IPs from the HSDirs (we get this for free in rend-spec-ng.txt). In the current HS implementation there are two ways to do authorization: https://gitweb.torproject.org/torspec.git/blob/HEAD:/rend-spec.txt#l768 both have different threat models. In the future "Next Generation Hidden Services" specification there are again two ways to do authorization: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spe… One way is with a password and the other is with a public key. I suspect that HS authorization is very rare in the current network, and if we believe it's a useful tool, it might be worthwhile to make it more useable by people. For example, it would be interesting if TBB would allow people to input a password/pubkey upon visiting a protected HS. Protected HSes can be recognized by looking at the "authentication-required" field of the HS descriptor. Typing your password on the browser is much more useable than editing a config file. Furthermore on the server-side, like meejah recently suggested [0], it would be nice if there was a way for HSes to be able to dynamically add/remove authorized clients using the control port. [0]: https://lists.torproject.org/pipermail/tor-dev/2014-October/007693.html

12 14

tor-0.2.5.10: weird test failure
by Thomas Klausner 21 Nov '14

21 Nov '14

Hi! I'm currently trying to update tor in pkgsrc (www.pkgsrc.org) to 0.2.5.10. When I run the self tests with 'make check', I see: .../work/tor-0.2.5.10> make check make check-TESTS check-local PASS: src/test/test make all-am ============================================================================ Testsuite summary for tor 0.2.5.10 ============================================================================ # TOTAL: 1 # PASS: 1 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ python2.7 ./src/test/test_cmdline_args.py ./src/or/tor "." ............ ---------------------------------------------------------------------- Ran 12 tests in 0.299s OK python2.7 ./src/test/ntor_ref.py test-tor OK python2.7 ./src/test/ntor_ref.py self-test OK ./src/test/test-bt-cl assert | python2.7 ./src/test/bt_test.py BAD ./src/test/test-bt-cl crash | python2.7 ./src/test/bt_test.py BAD [1] Segmentation fault (core dumped) ./src/test/test-... | Done python2.7 ./src/... Running src/test/test directly works fine though: .../work/tor-0.2.5.10> ./src/test/test ... util/fgets_eagain: SKIPPED ... 222 tests ok. (1 skipped) Any ideas where to look first? Thomas

1 0

torsocks-2.0: NetBSD mmap patch
by Thomas Klausner 21 Nov '14

21 Nov '14

Hi! Please apply the attached patch to fix torsocks-2.0 on NetBSD. Thanks, Thomas

1 0

Re: [tor-dev] How to distribute Tor with other software
by David Stainton 21 Nov '14

21 Nov '14

Greetings, olde thread resurrection: Earlier Meejah pointed out that the tor control port can be used to create tor hidden services. Now that tor trac ticket #11291 (https://trac.torproject.org/projects/tor/ticket/11291) is resolved this will actually be usable? There are deployment issues. The program must run as a user who is a member of the tor group in order to read the hostname file and thus retrieve the onion address. With the current upstream master tor you can use the HiddenServiceDirGroupReadable option, like this: SETCONF hiddenservicedir=/var/lib/tor-alpha-hidden-services/hiddenService01 hiddenserviceport="80 127.0.0.1:8080" HiddenServiceDirGroupReadable=1 This should result in the hostname file being readable by the tor group. Is anyone else working on tor hidden service file sharing and or tor controller written in golang? I've implemented a golang api for creating and destroying tor hidden services using the control port... and a golang commandline tool for sharing directories via http + tor hidden service similar to carml pastebin or onionshare. If we write these tools in golang then we can use a deterministic build system much like the recent gitian golang deterministic builds for golang pluggable transports. Cheers, David

1 0

Pluggable transports meeting tomorrow (16:00UTC Wednesday 19th of November 2014)
by Yawning Angel 19 Nov '14

19 Nov '14

Hello! just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks for your attention! -- Yawning Angel

1 0

User experience issue
by Adam Shostack 15 Nov '14

15 Nov '14

Hi, I just had the fun experience of trying to walk someone who's not very technical and not familiar with Tor through downloading and installing the TBB. One element which came out was she was confused by the relationship between Tor, the Tor Browser Bundle, and Vidalia, and became frustrated by that experience. ("What's this Vidalia thing? I thought we were installing Tor!") I'm unsure if it would be appropriate/useful to file a bug, and so would like advice on if/how to tackle this. Adam

2 2

Re: [tor-dev] Of CA-signed certs and .onion URIs
by Jeremy Rowley 14 Nov '14

14 Nov '14

Great summary Tom, >From my perspective, getting .onion reserved is a pretty high priority. Once reserved, we can really eliminate it as an internal name and get onion listed as part of the PSL. I'm happy to help with this part of the project if I can. >Syrup-tan had an idea on irc: Have a DV certificate sign a certificate >that is valid for the .onion URL, and display the URL of the DV >certificate. This doesn't eliminate phishing - I can register >facebok.com and then get that displayed. But doing bootstapping off >DNS and DV certificates is a fairly low bar in terms of the cost to a >.onion operator. (There are other concerns here, I'm not completely >comfortable with repurposing the EV indicator in this way. Asa on irc >had the good point that if we did this, maybe we'd want to change the >EV green to another color just to be a little bit different. Not that >I really expect users to notice that though...) This is similar to what I was thinking by proposing that CAs have both a non-onion and onion name in it. If you do that and both are validated as part of the same certificate order, you could give users an indicator that the non-onion name is related to the onion name in the certificate. >Allowing an organization to purchase an EV certificate from a CA, and >display the organization's name in the address bar, is another way - >albeit a very high bar in terms of cost to an onion operator. I'm hoping the cost won't be high - I'm interested in this solely as something that supports Tor and companies like Facebook who want to give users greater privacy. Like you, I'm not looking to make EV certs required for onion operators. Instead, I'd like to see them permitted under the industry standards for companies looking to prominently promote their onion services. The biggest penalty of requiring EV is that it locks out individuals - which is very bad. I've proposed EV for individuals several times on the forum. Probably time to bring it up again. >But there should be at least one more solution in >the short to long term (e.g. a petname approach). Unfortunately, if >the time between now and the 'long term' solution is too long, it >locks out everyone who can't get an EV cert - which is a legitimate >concern. Perhaps after there's a spec Tor likes, some large >organization concerned about preventing phishing could throw some >engineering time at the problem. Jeremy

1 0

OONI weekly dev meeting reminder
by Arturo Filastò 13 Nov '14

13 Nov '14

Hello Oonitarians, This is reminder that today (Thursday 6th of November 2014) there will be the weekly ooni dev meeting in #ooni on irc.oftc.net. The time will be: 18:00 UTC 19:00 CET 13:00 EST 12:00 CST 10:00:00 PST You are all invited to attend! ~ Arturo

1 1

Defending against guard discovery attacks by pinning middle nodes
by George Kadianakis 13 Nov '14

13 Nov '14

Hey Nick, this mail is about the schemes we were discussing during the dev meeting on how to protect HSes against guard discovery attacks (#9001). I think we have some ideas on how to offer better protection against such attacks, mainly by keeping our middle nodes more static than we do currently. For example, we could keep our middle nodes for 3-4 days instead of choosing new ones for every circuit. As Roger has suggested, maybe we don't even need to write the static middle nodes on the state file, just use new ones if Tor has restarted. Keeping middle nodes around for longer will make those attacks much slower (it restricts them to one attack attempt every 3-4 days), but are there any serious negative implications? For example, if you were unlucky and you picked an evil middle node, and you keep it for 3-4 days, that middle node will always see your traffic coming through your guard (assuming a single guard per client). If we assume you use a non-popular guard node (with only a few clients using it), the middle guard might be able to think "Ah, the circuit that comes from that guard node is always user X" making your circuits a bit linkable from the PoV of your middle node. What other attacks should we be wary about? Maybe partitioning attacks based on client behavior? And how should we move this forward if we decide it's worth it? Should we start writing a Tor proposal? Thanks!

8 26