- tor-dev - lists.torproject.org

[PATCH] Pinning middle nodes for HSes: anti-guard-discovery
by George Kadianakis 25 Nov '14

25 Nov '14

Hello, inspired by the recent discussions on guard discovery, I went ahead and implemented a small patch for Tor that tries to help defend against Hidden Service guard discovery attacks. It basically allows the operator to specify a set of nodes that will be pinned as middle nodes in Hidden Service rendezvous circuits. The option only affects HS rendezvous circuits and nothing else. Of course, it doesn't fix guard discovery, it just pushes guard discovery to the next hop, so that they need to compromise two boxes to win. You can find my branch in 'sticky_mids' at https://git.torproject.org/user/asn/tor.git . (Here it is in HTTP shape: https://gitweb.torproject.org/user/asn/tor.git/shortlog/refs/heads/sticky_m… ) I don't expect this to be merged in mainline Tor, but if any HS operators feel like they need it, here it is. I coded it fast and it seems to work for me, but please inform me of any bugs. You can use it by adding a line like this in your torrc: """ HSRendezvousMiddleNodes TorLand1 """ (BTW, I'm not advocating TorLand1, it's just a random relay name I thought of. Please use your own web of trust.)

2 2

doc/HARDENING Draft
by Libertas 25 Nov '14

25 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I thought I'd share an initial draft of doc/HARDENING. Please share any opinions or contributions you have. This was written in a little more than an hour, so it's still a work in progress. However, in the spirit of prototyping before polishing, I thought I'd share early. Here's the relevant ticket: https://trac.torproject.org/projects/tor/ticket/13703 A specific topic of conversation is how much of the advice should be in the document itself as opposed to linked sources. It could also use more OS diversity. After reading it, you can probably guess which *nix flavors I'm familiar with. Enjoy, Libertas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUc7qtAAoJELxHvGCsI27NOwsP/1bP+g4W2y1NHefR5bd+5hwo V927TXzarNneNFxfhKJsVewVnU593Ex13iHv+WgA+XM39xiK8KkhpxOaw2IpahZp pIRCk4/XX78YaEc/K3ci2AsNGFVXPBX7nm4/VOZ5qiGfo+FVeipykweF1dF+X1Wc 1wr8Q9LWKoIab+klu/BG5nG5NtwICYslbgXMvNnapHuy0Xn1+fvBx3mW9teMkJ0N Npssiy7XUqJx1XpdYNJr4XI28aHOV2p4FeCdsAgaQ1OBkOvpzMd+fw2Yb3FOiX/l 5pNCPMXFsS/+OXp1qOFKDQoOb7fEP6mY4NqdSovuJU0oWdurnHVk/X3SidALfH/L vFPdTwpCJSMLuYO7HsLLiLx6LkDtrDZ2y9+tUfpqKGAN0upXrIi5GWsbUeLcCqwY UFYdSg1GHsWJz7fU6F1vDLpGsiXU5yVqgaxfP06+nZ/smRt5sA3nlMDCZJi3BDes k0+c4+tAPZ5Yt6kJ5b1GBgxQMokDqnLm/4pb/qlp0EzDfhWpA+Un2lGdvInrz1ds VsVvbq/LLuxYylC3hlF8pNxBVMdbXycWM1w/VHtDjPZFdo9AO4CJHXeShYQa2O0W cBXdU+O59wWoxiCuEfo0O2xaJw2UIRfxauQbcp/A0rg8FKU1c2QeP2t7y8VdVC1Y SgQNVCUKYPBMCywJw9PA =yY3r -----END PGP SIGNATURE-----

1 0

Next OONI weekly meetings
by Arturo Filastò 24 Nov '14

24 Nov '14

Hello Oonitarians, Sorry for not sending this email sooner, but this week has been a bit hectic. A couple of people have said that they cannot attend the weekly meeting on thursday at 18:00, because it conflicts with another recurring appointment they have. For this reason I am going to suggest we reschedule the next OONI meetings to a date that works for everybody. Monday and Tuesdays seem to be the best option, so I am going to propose we skip next weeks meeting and instead opt for holding next weeks one on either a Monday or Tuesday at 18:00 UTC, 19:00 CET, 13:00 EST, 12:00 CST, 10:00:00 PST. How does this sound for everybody? I personally would prefer Monday over Tuesday, but if you would instead prefer Tuesday please send a reply to the ooni-dev mailing list. If nobody replies I am going to assume every Monday works for you all and the next meeting will be on Monday 24th of November. Have fun! ~ Arturo

2 2

How does a hidden service select introduction points
by Richard Dennis 24 Nov '14

24 Nov '14

Hi guys, i have been doing a bit of reading recently about hidden services, and i am just wondering how exactly a hidden service selects its introduction points, i understand there are two methods, one where the H.S picks its own set of I.P's and one where this is done for the H.S., is this correct? If so is there an algorithm for automatically selecting introduction points for a hidden service and is one method recommended over another, if so why? Finally how many introduction points does a H.S. usually have, can a larger H.S. have more I.P's to deal with the traffic or is this not advised ? Thanks for the help Rich

2 1

More consistant src/or/config.c [patch]
by grarpamp 24 Nov '14

24 Nov '14

--- src/or/config.c.orig 2014-10-19 11:13:04.000000000 -0400 +++ src/or/config.c @@ -852,12 +852,14 @@ "moria1 orport=9101 " "v3ident=D586D18309DED4CD6D57C18FDB97EFA96D330566 " "128.31.0.39:9131 9695 DFC3 5FFE B861 329B 9F1A B04C 4639 7020 CE31", - "tor26 orport=443 v3ident=14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 " + "tor26 orport=443 " + "v3ident=14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 " "86.59.21.38:80 847B 1F85 0344 D787 6491 A548 92F9 0493 4E4E B85D", - "dizum orport=443 v3ident=E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58 " + "dizum orport=443 " + "v3ident=E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58 " "194.109.206.212:80 7EA6 EAD6 FD83 083C 538F 4403 8BBF A077 587D D755", - "Tonga orport=443 bridge 82.94.251.203:80 " - "4A0C CD2D DC79 9508 3D73 F5D6 6710 0C8A 5831 F16D", + "Tonga orport=443 bridge " + "82.94.251.203:80 4A0C CD2D DC79 9508 3D73 F5D6 6710 0C8A 5831 F16D", "turtles orport=9090 " "v3ident=27B6B5996C426270A5C95488AA5BCEB6BCC86956 " "76.73.17.194:9030 F397 038A DC51 3361 35E7 B80B D99C A384 4360 292B", @@ -867,7 +869,8 @@ "dannenberg orport=443 " "v3ident=585769C78764D58426B8B52B6651A5A71137189A " "193.23.244.244:80 7BE6 83E6 5D48 1413 21C5 ED92 F075 C553 64AC 7123", - "urras orport=80 v3ident=80550987E1D626E3EBA5E5E75A458DE0626D088C " + "urras orport=80 " + "v3ident=80550987E1D626E3EBA5E5E75A458DE0626D088C " "208.83.223.34:443 0AD3 FA88 4D18 F89E EA2D 89C0 1937 9E0E 7FD9 4417", "maatuska orport=80 " "v3ident=49015F787433103580E3B66A1707A00E60F2D15B "

2 1

Damian's Status Report - November 2014
by Damian Johnson 23 Nov '14

23 Nov '14

Hi all. Next weekend I'm returning to ye olde isle of Vashon to feast with family, so figured I might as well send this out early. I'll be in a Thanksgiving food coma this time next week, after all... My devious scheme for November was to finish rewriting arm's graph panel and, while that certainly made progress, Stem, DocTor, and internal discussions stole the spotlight this month... -------------------------------------------------------------------------------- DocTor -------------------------------------------------------------------------------- * We now notify directory authority operators directly of issues in addition to the tor-consensus-health@ list. This should reduce duration of outages and other issues with the authorities. * We replaced turtles with longclaw. Sebastian deserves major kudos for orchestrating this. [1] * Properly fixed DocTor's OOM issues by not shelling out to send notification emails. [2] * DocTor detected a burst of relays from Google App Engine. These relays lacked any contact information so we dropped them from the network as a potential Sybil attack. [3] If you're the operator of these then please let us know! We'd be delighted to add you back in once there's a proper family and contact information. -------------------------------------------------------------------------------- Stem -------------------------------------------------------------------------------- * Ossi Herrala made delightful improvements so we parse descriptors ~10% faster [4], and now read from the '.new' files in Tor's data directory [5]. Thanks Ossi! * Expanded our descriptor tutorials with an example of persisting descriptors to disk. Thanks to mmcc for the idea [6]... https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html#saving… https://stem.torproject.org/tutorials/examples/persisting_a_consensus.html * Replaced quite of bit of boilerplate in Stem with a new @with_default decorator. Mmmmm, deleting code is fun... [7] * Updates to reflect changes in Tor's spec this month, including HS_DESC's new reason attribute, and validating the new consensus parameters. A couple other quick things of note is that I spruced up our volunteer page [8] and attended this month's Seattle TA3M. The later had a nice bit of serendipity in that I met Anna, a UW PhD student who's looking into our Bandwidth Authorities [8]. Best of luck Anna! That's certainly an area that could do with a lot of improvement. ;) Cheers! -Damian [1] https://trac.torproject.org/projects/tor/ticket/13296 [2] https://gitweb.torproject.org/doctor.git/commitdiff/94a2e9d [3] https://lists.torproject.org/pipermail/tor-consensus-health/2014-November/0… [4] https://trac.torproject.org/projects/tor/ticket/13821 [5] https://trac.torproject.org/projects/tor/ticket/13756 [6] https://trac.torproject.org/projects/tor/ticket/13774 [7] https://gitweb.torproject.org/stem.git/commitdiff/56a1f03 [8] https://gitweb.torproject.org/project/web/webwml.git/commitdiff/05c1b60

1 0

botnets in tor
by Enkidu Mo Shiri 22 Nov '14

22 Nov '14

Hi everyone, am new and not very sure about rules here,hope its not off-topic. im master student researcher and i am working on botnet detection. it would be appreciated if anyone can help me with : I. anyway to detect botnet trafic out of normal tor traffic? II. is this solution possible to apply? to attach a script to botnet ( so we pass reverse engineering and no mess with codes of malware) and send it back to network, let the relays and last node which is botmaster recieves the compromised botnet ,and the script report our detector machine of any time it been re-routed in tor network ( hidden service and relays and botmaster) about : ip address of receiver hosts (relays) and their computer information( os,...) and consider last hop as botmaster. after using this technic for few botnets, we can have a good view of how relays (and which relays) been used for attack bt botnet and who is botmaster : it can help tor admin to clean relays, remove that hidden service , blacklist botmaster ip address thank you *Ehsan Moshiri (Enkidu)* *Digital Forensic Student* *H/P:+96164953954 , +961124249769* *Linkedin: http://my.linkedin.com/pub/enkidu-moshiri/59/baa/90b/ <http://my.linkedin.com/pub/enkidu-moshiri/59/baa/90b/>* *Facebook: Enkidu Mo Shi Ri* *wechat: Enkidu-Moshiri* *Line: Enkidu.Moshiri*

1 0

Using Shadow to increase agility of Sponsor R deliverables
by Rob Jansen 21 Nov '14

21 Nov '14

Hi David, Roger, I think it would be great if we could show off some HS performance improvements at the next Sponsor R PI meeting in January, both as a way to show that we are making progress on the performance front and also to help demonstrate our agility and how quickly we can get results on new designs. I’m here to advocate the use of Shadow to help in this regard. So far, the list of deliverable that we could possibly show improvements is quite small: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR#Tickets From the list of completed tickets, the only one that stands out to me as providing a performance boost is #13211 (Allow optimistic data on connections to hidden services): https://trac.torproject.org/projects/tor/ticket/13211 This seems like a somewhat small change; despite that, do we think this may be something worth simulating to verify it works as expected and understand the extent to which it reduces time to first byte for HS downloads? Are there other HS performance improvements that we think may be ready by January? Best, Rob

2 6

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