- tor-dev - lists.torproject.org

PT-themed stuffed animals: huggable transports
by David Fifield 01 Apr '15

01 Apr '15

In an effort to improve pluggable transports' visual identity, we should introduce a line of stuffed animals. The only rule that the the animal's name has to be made out of the transport name. The meek meerkat! [1] The obfs blobfish! [2] The FTE eft! [3] The flash proxy banded quail (Philortyx fasciatus)! [4] The ScrambleSuit bumblebee (Bombus centralis)! [5] Call now, operators are standing by. [1] https://en.wikipedia.org/wiki/Meerkat [2] https://en.wikipedia.org/wiki/Blobfish [3] https://en.wikipedia.org/wiki/Eft [4] https://en.wikipedia.org/wiki/Philortyx_fasciatus [5] https://en.wikipedia.org/wiki/Bombus_centralis

3 2

Raptor
by Liste 01 Apr '15

01 Apr '15

Some people say to track tor users there is a tool named raptor. It uses the packet data recognition to track via AS the data streams between tor hosts. Can be a good idea to split, merge, change the packet order, the data streams etc... to obfuscate the traffic with an algotithm to create false data recostruction? Example: Alice --->node-> node -> node --> Bob1 ----> False/EndOfStream ^ ^v ^v ^v ^v | \------- node <- node <- node <-- node ---------/ If a complex network is created and some random data and connection are added to negotiate the data obfuscation, is very difficult to track a single data stream or packet. When the data arrival, send some data (same payload size)to a random loop circuit. What do you think?

1 0

0.2.7 triage [almost there!]
by Isabela 01 Apr '15

01 Apr '15

Hello there! we are almost done with the triage of 0.2.7 - we have a good chunk of tickets organized into 2 groups at the spreadsheet. Now what I would like to ask people from today till our next IRC meeting (Core Tor meeting on Wednesday) is shape group 1 to be our final list. What that means? Review what is in there and what is not in there. We have added an extra column for you to have a chance to nominate things out of group 1 or to be added to group 1 (things from group 2). We are also asking that folks try to balance nominations always towards having more negative ones than positive ones (we don't want group 1 to end up with 200 tickets again :)) https://docs.google.com/spreadsheets/d/1H_kAcQQ-NpGpKWG9RlF3w-NhruKKE9EZJcR… Thanks for playing it! See ya on Wednesday) Isabela

2 2

What's going on with websocket user numbers?
by David Fifield 31 Mar '15

31 Mar '15

I noticed there's a big increase in reported users of the websocket transport in the past few weeks, from about 5 to over 50. https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… "websocket" is the transport name that flash proxy uses. I checked the bridge for flash proxy, and it doesn't seem to be used notably more often in the last weeks than before. https://globe.torproject.org/#/bridge/9DD7D759971D03E70F0181B4E6D5F7735E7BF… There are other bridges out there that also support the websocket transport. I don't know who's running them. I appended a list at the end of this message. It comes from grepping for "websocket" in https://onionoo.torproject.org/details?type=bridge&fields=nickname,hashed_f… Most of them seem to be related; namely, there are a lot with these characteristics: 80 <= ORPort <= 105 platform = Tor 0.2.7.0-alpha-dev on Linux transports = ["websocket","fte","obfs3","scramblesuit"] Morlock-sounding nicknames: ashrak, bashaak, delmac, gonach... The only bridges not belonging to this set are C3L (ORPort = 8118), giygas (my bridge), and nerds (ORPort = 9052, platform = Tor 0.2.5.11 on Linux"). It's possible that the new websocket users are using one of these other bridges. It's also possible, since the bridges run more than one transport, that the users are actually using some other transport, and they are mistakenly being counted for websocket: https://lists.torproject.org/pipermail/tor-dev/2014-September/007483.html A lot of them have last_restarted of 2015-03-14 or 2014-03-25, which fall roughly where the user increase is on the metrics graphs. Maybe they were recently rebooted with support for the websocket transport. David Fifield {"nickname":"ashrak","hashed_fingerprint":"F1C465D38F18091F6FED9CAC924DA50F2813C0AE","or_addresses":["10.219.160.68:80"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["websocket","fte","obfs3","scramblesuit"]}, {"nickname":"bashaak1","hashed_fingerprint":"196FC9A50B1F3828730C11C4E1DD5B55F979F548","or_addresses":["10.152.136.2:80"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"bashaak2","hashed_fingerprint":"F76FB49B6B1CC1BB23618A20A2D6E8B1509BF7BC","or_addresses":["10.128.21.28:81"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"benna2","hashed_fingerprint":"3665A4A74A6554CA03122AFBC9C3C6C5AD2F9BC6","or_addresses":["10.35.205.157:83"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"C3L","hashed_fingerprint":"E1F69F3CE3107F740646127527F8B21BA8BCDFC4","or_addresses":["10.226.202.166:8118","[fd9f:2e19:3bcf::73:c310]:8118"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","obfs4","websocket","fte"]}, {"nickname":"delmac1","hashed_fingerprint":"16EBD0A3DAD2833FDA9323F89ED9B2EFF484D748","or_addresses":["10.223.29.80:84"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"delmac2","hashed_fingerprint":"5B300273F583602780746191ADF17AC96190CC92","or_addresses":["10.12.236.225:85"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"giygas","hashed_fingerprint":"9DD7D759971D03E70F0181B4E6D5F7735E7BFDED","or_addresses":["10.233.17.187:9001","[fd9f:2e19:3bcf::df:d557]:9001"],"platform":"Tor 0.2.5.10 on Linux","transports":["websocket","obfs3_websocket"]}, {"nickname":"gonach1","hashed_fingerprint":"F532D7DC394BAE539D530EB9EC5BA22450A7910D","or_addresses":["10.231.241.32:86"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"gonach2","hashed_fingerprint":"6C1259CE071500804AC2E67673EA57045D44004B","or_addresses":["10.7.64.152:87"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"hoktar","hashed_fingerprint":"86D33A3BA7A04A1D8C1D4C44AEC5BF1FC163815C","or_addresses":["10.230.24.16:80"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["websocket","fte","obfs3","scramblesuit"]}, {"nickname":"intar1","hashed_fingerprint":"98FC0DADB4EF313BAB18C4F8F5B29186CEC1EFEE","or_addresses":["10.142.253.194:90"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"intar2","hashed_fingerprint":"22A42B97C35A6CABCB837E308E302321DEE8860B","or_addresses":["10.227.197.14:91"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"kalma","hashed_fingerprint":"D923FB993A480E27023814CB22FA568B418C3561","or_addresses":["10.86.149.238:443"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["websocket","obfs3","scramblesuit"]}, {"nickname":"krantu","hashed_fingerprint":"121385AFAC02851932A40635235D16A9A47390BE","or_addresses":["10.58.14.110:82"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","fte","websocket"]}, {"nickname":"kreeshak","hashed_fingerprint":"94A4DCD9C31958710A8208233E2FA8A58F90DD08","or_addresses":["10.85.219.97:81"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","fte","websocket"]}, {"nickname":"krelnok","hashed_fingerprint":"D1B0B1FDE5FF1047C5636BEAB06E22F3505D0895","or_addresses":["10.101.210.202:83"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","fte","websocket"]}, {"nickname":"lantia","hashed_fingerprint":"6173C626355BA51DFE93F515F792CDC7B36652F4","or_addresses":["10.74.170.126:80"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","fte","websocket"]}, {"nickname":"linvris1","hashed_fingerprint":"2DE8ED06644EAD67A4351F73CF94ED4819604AB3","or_addresses":["10.90.170.20:92"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"linvris2","hashed_fingerprint":"FFC371256605279169C8F740378EB88C542940E1","or_addresses":["10.15.182.141:93"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"naquadah1","hashed_fingerprint":"6D83B4CAF9807CB2C4C8C6C04EDDE27496E47525","or_addresses":["10.184.185.130:94"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"naquadah2","hashed_fingerprint":"9577348174583345AFF8FB2CD5C1DAAC3042F0BB","or_addresses":["10.99.253.237:95"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"nerds","hashed_fingerprint":"EE2AFFBF783BEA2D24904240A48DEDA2D5372FC8","or_addresses":["10.104.45.191:9052"],"platform":"Tor 0.2.5.11 on Linux","transports":["websocket","fte","obfs3","scramblesuit"]}, {"nickname":"orak1","hashed_fingerprint":"2E3494ABC70A4AF8AD301569C40D620C565A235A","or_addresses":["10.88.122.255:96"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"paiboun","hashed_fingerprint":"D416D28AB1C24C215D40CEB70BE36F2779E8B4A2","or_addresses":["10.54.177.10:105"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"piratepartei","hashed_fingerprint":"319F4D05D76537AADD499D5B48B4425DDFEF66C7","or_addresses":["10.133.182.221:80"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","fte","websocket"]}, {"nickname":"shaltek2","hashed_fingerprint":"09C6AD6382A5C0AB268D0AEA25284E4AC0E5E4AC","or_addresses":["10.83.36.70:99"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"tauri1","hashed_fingerprint":"5B27B16BFF449E60C6084D1ED2A082AF8C459531","or_addresses":["10.16.110.176:102"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"tauri2","hashed_fingerprint":"B694A8E4E60E4CA6BF173D973731DA0B7D425999","or_addresses":["10.73.213.191:103"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]}, {"nickname":"teltac1","hashed_fingerprint":"3EAA792F08B6D99031BBC3BCEB2C4BA58C5FAA41","or_addresses":["10.210.205.232:104"],"platform":"Tor 0.2.7.0-alpha-dev on Linux","transports":["obfs3","scramblesuit","websocket","fte"]},

1 1

maintenance status of atlas or globe
by Nusenu 31 Mar '15

31 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, is globe or atlas actively maintained? Does it make sense to create trac entries? (I just want to avoid doing worthless things.) thanks, Nusenu -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVFqYBAAoJEFv7XvVCELh0u1QQAKSai+lYibASpYdqUFnfka7E APq5zGYnkR1I9KGTR8aL9+Z/dlEzl2fCCztwyfFZPYFudh/qzPtSPDUInLvDE/za 3X25hbCHwyW9Q7jQKAYWYuYWACE1S4F62e6TFzoT20gga1EhldBO+FqL943D7DuV 4FPT6lkWuPtZKF5X3gb0tkS6d48o5NYSp3RhFsowX2Y3SfdoRnTa86QbQ+2k9g7K R2W6f53c6jxwUU8MC4W3Tqc2JykojFbZADvwi8QxJ+4KlxWimG6PDshuJoY+sdsX R0n5o0L986uAn9CA5K5s/ANLkl9cYgt/oxptsY4HWSFKAh6xjdQBSYt5qjXI+KxL d1PDPdGXjolePsjUv/md+hnoRVjo4FCjx+5aQw23QhGaCi9Np0E87rF2xuUNmszs y9F/niXvNJMp1OIhVDeTinLm18lkOVCoGz/UkHdbiBj5md/5GTfql3zp2Nssku30 O+hUOEuvTJ0mousMglFeWRiO2UiliU55qTEbIUV5o4YVCK4uWA11v06so6dI4FNh bRwqUTsnzU/PqLdvgDUP3fiZXizVoxQB+KMzwnmroV+QmL+cnAR7ac8hU/PfPH/F nC/lONV5ZiXnmBZXvHTnIUBeHRwtQi48rDWtNLnSQmRN3i8jwP1NiUmuyKXZgA2a 6+cGVMKBA+Xy2sBciw9y =2YsQ -----END PGP SIGNATURE-----

5 9

#14997: canonical path to tor alpha debian repo
by Nusenu 30 Mar '15

30 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Erinn, it would be great if there was a canonical path to tor alpha releases (like the RPM repo provides) so people that choose to use alpha releases would not have to change their apt sources.list as soon as a new major tor version is released. What do you think about #14997? https://trac.torproject.org/projects/tor/ticket/14997 I guess this would not be big effort - simply creating a subfolder for the alpha builds would do it? thanks, Nusenu -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVGTW8AAoJEFv7XvVCELh0zmIP/2Whg3TTSFVXTmvV4dz0oJaq 5caVsMJcKqeNXSxhg5hs4oVVpJco5wSdMrFkz384svFNGvhbnEsPxVy24tLjUw0O EUUzw6MQ4nbL4sEV9AjjVDKTcvPPM9l4jTfLb5/l49j6X9TNmW/DLJ3qm3/KHlM/ ny3Jzm9fXIu37WjkBfGJf5FDspLNKSOVkLj2tSXe/DURZ86caRH+HJkWD6cu4A+L QtfgZgFrmSS1oLwXsvt8PB5b7Hf7uoQlNoAJiS1WneEYlREZA1B9Jj/hdjtbUbaE pS46bFGghl6l8JVkaheHauCkc5sCXQegRQ4b4280ENmGqNcWyVQiIHwJ0q1xiI5G 88oMniG3SAELvsTBWd9idH2gkvst82qtHpq8kpA0Vk1TvbL1M6gI9YECf7f2VeMi w2zZSCgeCmI509GEsG53PiR2uj+7VGPSbSTeUlLXBOx9u0Qlt8UHhSwR58LJrp7C 79RzJxoXbJKWhPmNjIbcr2xX4TYyIqtmPvq6NCq3DpF73X/XrNPE9hF2t1PHPbR5 3rhgt4NyU65Oj8T79CHn1u7Lgd2VGaYf3hVnAHd+M1R270APhGu30Qur+Y6ta/54 3m0Ai81QRdxXZSJbRGZiAUhEh+bq1MMrj/aFZtBaVzT0tT5pDcdnIzAKeLPSbsRT UkiJp34p8BB6FoFel1uc =Znzj -----END PGP SIGNATURE-----

1 1

What is the unit of the bw reported in the descriptor?
by Thee Chanyaswad 30 Mar '15

30 Mar '15

Dear all, Following the earlier question about the gap between total bw reported, what is the unit of the bw shown? The Torspec doc says it's in Byte/s. Is this still correct? Thank you very much. Best Regards, Thee

2 1

HS bi-weekly community meeting
by Isabela 29 Mar '15

29 Mar '15

Hello there, I am very sorry for this to be taking so long. I keep forgetting about it! I created a poll for us to pick a day/time and start a bi-weekly meeting for the HS community. This was something we spoke in Valencia and the members of the community think is a good idea (a place to talk about HS in general not only sponsorR stuff). The times proposed at the poll are the most common time we meet (in UTC time) and for the slots where there is no meeting going on at #dev-tor. http://doodle.com/xnxugpt9fb7rvch2 Please vote! Thanks isabela

2 3

Renaming arm
by Damian Johnson 29 Mar '15

29 Mar '15

Hmmm, thread about something as squishing and infinitely debatable as a name. What could go wrong? But before you get excited I've already picked one, this is just to sanity check with the community that I'm not making a stupid mistake... again. Five years ago when I started arm [1] I had the following criteria for picking its name... 1. It needs to be short. This is a terminal command so anything lengthy is just begging people to alias it down. 2. It should be reasonably memorable. Sorry, no 'z62*'. 3. No naming conflict with other technical things. Body parts though are fair game though. Clearly the name failed at #3. When I picked it the ARM processor was just barely becoming a thing, but time marched on and now every irc discussion goes... new_person: New relay operator here, any tips? somebody: Hey, try arm! new_person: The processor? I'm so confused now. somebody: Nope, something completely different. It's a confusing name. I'm rewriting the whole bloody codebase so why not fix this along the way? So without further ado the name I've picked is 'Seth'. It's easy to type (#1), memorable (#2), and from what I can tell no SETH processors are on the horizon. I've reserved the name on PyPI, and searchs on wikipedia looks fine (most interesting match is the Egyptian god [2], which is actually kinda neat). So now just a final sanity check with you, our wonderful community. Any strong reasons to pick something else? Nothing is set in stone yet so still open to alternatives. Cheers! -Damian [1] https://www.atagar.com/arm/ [2] https://en.wikipedia.org/wiki/Set_%28mythology%29

13 23

Damian's Status Report - March 2015
by Damian Johnson 29 Mar '15

29 Mar '15

Guten tag world! Time again for another status report... -------------------------------------------------------------------------------- Arm Graph Panel Rewrite -------------------------------------------------------------------------------- Really? Has it actually been four months? Dusted off my work from November and finished rewriting arm's graph panel. Besides untangling a mess of code that would make my family disown me, this leverages 'GETINFO bw-event-cache' to greatly improve graph prepopulation. Thanks, Nick, for adding that! Coding aside, real challenge this month has been finding a better name. Thanks everyone who has helped (especially Mike!)... https://lists.torproject.org/pipermail/tor-dev/2015-March/008398.html I'm now strongly leaning toward Nyx. Brevity aside, Nyx is the primordial goddess of the night with a description that's positively delightful... "Her appearances are sparse in surviving mythology, but reveal her as a figure of such exceptional power and beauty, that she is feared by Zeus himself. She is found in the shadows of the world and only ever seen in glimpses." Very curious to hear what the community thinks. -------------------------------------------------------------------------------- New Development Blog -------------------------------------------------------------------------------- Five years now I've dumped my status reports onto a single page. While this worked, clearly it lacked a certain... elegance. Moved to a proper blog... * before: https://www.atagar.com/log.php * after: http://blog.atagar.com/ Personally I found it interesting how my style has evolved over the years. My current approach is to focus on a couple topics, followed by a brief list of additional things I've been up to. This is much easier to skim than the walls of text I once wrote. -------------------------------------------------------------------------------- Few other noteworthy things were... * Stem can now read encrypted hidden service introduction-points. (#15004) * Support for the consensus' new packages field and new HS extrainfo stats. * You can now specify just a single test to run, rather than a whole module. (#14944) * clv expanded our tests to check if tor has capabilities Stem lacks. (#8250) * Sebastian sped up our integ tests by making them use trigger-able events. (#14943) Cheers! -Damian

1 0

Tor Browser 4.5a5 will change circuit expiry to 2hrs
by Mike Perry 28 Mar '15

28 Mar '15

In Tor Browser 4.5a5, we decided to increase MaxCircuitDirtiness to 2 hours (https://trac.torproject.org/projects/tor/ticket/13766) Because we also use Tor's SOCKS username isolation using the URL bar domain as the SOCKS username in Tor Browser 4.5 now, this has the effect that websites you visit will continue to use the same circuit (and thus the same exit IP) for all of their content elements for 2 hours, or until you click "New Identity" or "New Tor Circuit for this Site" (which appeared in Tor Browser 4.5a4). The reasons for this change are detailed in that ticket description, but in summary I think it is a really, really bad user experience when a website switches languages, bans you, or logs you out every 10 minutes. My own workflow in Tor Browser has been frequently interrupted by this in ways that have caused lost work and/or lost access due to this problem. With this change in combination with the "New Tor Circuit for this Site" Torbutton menu option, you now have the ability to get a good circuit for a site that you can actually use long enough to get something done. However, there are some downsides to this change: 1. Longer circuit lifetimes may mean more memory consumption at relays. 2. Longer circuit lifetimes may make correlation easier for adversaries that run Tor nodes or can see inside TLS (by stealing node keys). 3. Longer circuit lifetimes may distinguish Tor Browser users at the Guard node. 4. Longer circuit lifetimes may mean that the Tor client is less able to adapt to transient changes in Tor relay overload - the load conditions that caused the Circuit Build Timeout code to pick your current path may have long since changed over the span of 2 hours. 5. We actually had to hack update, OCSP, and favicon requests to continue to use 10 minute circuits, because Firefox does not make it easy to determine the URL bar associated with them. (We opted to keep the circuits for these requests at 10 minutes to avoid excessive linkability at the exit.) Did I miss any? Long term, I think what I'd rather do to achieve this functionality is to create a "TrackIsolationExits" Tor feature that ensures that Tor Browser keeps the same exit IP for a given URL bar domain independent of the underlying circuit lifespan, as I mentioned in https://trac.torproject.org/projects/tor/ticket/15458#comment:2. So: How do we make the decision as to if it is more important to improve usability in the short term while we design and implement "TrackIsolationExits", or if the above concerns (and others) trump poor usability? Right now, I am inclined to make the choice that leads to more people being able to effectively use Tor Browser in the short term, and then try to provide a better solution that gives similar user-facing behaviors with better network usage properties in the long term. To complicate matters, as ticket #15458 indicates, there are several other security concerns related to circuit use by Tor Browser that also need to be ironed out. In particular, it is actually somewhat dangerous to allow websites to use a new circuit every 10 minutes for things like Javascript/AJAX requests, because this enables Guard discovery. SOCKS isolation and a long circuit lifespan may actually make such Guard discovery harder, but unfortunately, there may still be other ways to do this in Tor today (See https://trac.torproject.org/projects/tor/ticket/13669 and https://trac.torproject.org/projects/tor/ticket/7870) Thoughts? -- Mike Perry

5 8

Measurement of the amount of discrimination by website operators on Tor users?
by Rishab Nithyanand 28 Mar '15

28 Mar '15

Hey all, I was wondering if anyone could help me figure out the status of this blog post (from August 2014): https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… Specifically this part: "Step one is to enumerate the set of websites and other Internet services that handle Tor connections differently from normal connections, and look for patterns that help us identify the common (centralized) services that impact many sites". I think it's an important step to help make more informed decisions about how the usability of Tor can be improved (by reducing discrimination). I've got a measurement platform in place, some ideas of how I'd like the study to be done, and an awesome mentor to help me with it. But I'd like to know if it's already been accomplished by someone else before investing time into it. Thanks! Rishab

2 1

onionoo-announces
by Nusenu 28 Mar '15

28 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Karsten, the latest onionoo update 2.3 triggered a bug in my onionoo "client" (charset encoding). Even though it is a bug on my side, would you mind announcing future releases/deployments on onionoo-announce [1] including a short changelog? thanks, Nusenu [1] https://lists.torproject.org/pipermail/onionoo-announce/2015/thread.html -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVFeWsAAoJEFv7XvVCELh0aeYP/R9pkcPgMGttspr5cl1W1RM+ qeIutnhNDAMs+DcbHKmB19BzgSRUfzrm4DCqnizWIxdXcF+AQP2nhmP0y+hIWTrK 5ctBQsWMUiwHym0TcKbbIEHrP2BcIoQSIM1GG52G4OWfmoymjbi5J1Jd+KuXYsFr 8GtJlLkjHWcD8wQuCUtMSfq1tTK/XnQES/UfhTUfJ3TMZvR1wxD3BNWZFJSOFMP2 k7cfBLYSG2uRCyRZ8dkoLXnSeJ/aya2PqR41mvU5y+IdUHC8IoVItx3GhC4ZT2v1 YcQyxvVFZh0NEwrdnYIxErNN5CJjqDUyLPWVQPJGvKR1KgFVdtcqsJH8OsyvYW1y ysETJ9AXPReo9os+oAWVJZvFG1HwU6MzS4U7beuVMo3drzNh3433nkZbCX50hS4z WMUdsWjZgUNscAIj76ECI58wiTgYN8Ro5X9wY9LwSwJz7NHtc+a999xSLy3GUuUp vEerRa1k06PqeqpNsZoe/8WVwohZVtRc9oGTcXJgtRF3F3hltsqB6s03hGLsQfXJ roOFglxrUlBaGAVYlyLWHSDiPf2lVnNUF27nsGodjoTLEubsJ1BsxUqT1JTNi3yx k8WTU2ATfbTVKva0N7Ac3yBE8+ZkQ+YbZB839li9ocXuxi173/aNmG3mKOVWWhP2 x0C/WXllxI2ObZY05ryR =IfVc -----END PGP SIGNATURE-----

2 1

Localization
by Abhiram Chintangal 26 Mar '15

26 Mar '15

Hi, I ran into a user, who was asking for censorship circumvention tools that have been translated to indic languages ( Bengali, Hindi, Tamil and Telugu to name a few). Is there a separate mailing list for localization efforts? I would appreciate it if someone can point me to the right resources. Cheers! -- Abhiram Chintangal

1 0

Draft report on where to focus testing efforts and modularization efforts in Tor
by Nick Mathewson 26 Mar '15

26 Mar '15

0. Summary I've got some end-of-month deliverables to try to figure out how Tor fits together to identify the most important areas to test, the hardest areas to test, and the best ways to modularize Tor in the future. Here's my current draft. Some of these ideas are half-baked; many will need more rounds of revision before they can be acted on. For more information see tickets #15236 and #15234. 1. Testing Tor: Where we should focus 1.1. Let's focus on complicated, volatile things. These functions are the highest in length and in complexity: circuit_expire_building parse_port_config run_scheduled_events connection_ap_handshake_rewrite_and_attach options_act networkstatus_parse_vote_from_string connection_dir_client_reached_eof directory_handle_command_get networkstatus_compute_consensus options_validate If we focus on the number of commits that have code still live in a function, we have: circuit_expire_building parse_port_config run_scheduled_events connection_ap_handshake_rewrite_and_attach options_act networkstatus_parse_vote_from_string connection_dir_client_reached_eof directory_handle_command_get networkstatus_compute_consensus options_validate And if we want to focus on average commits per line of code in a function, weighted in various ways, these ones stand out: add_stream_log_impl connection_close_immediate connection_connect_sockaddr connection_dir_client_reached_eof connection_edge_destroy connection_exit_begin_conn connection_handle_write_impl consider_testing_reachability directory_info_has_arrived init_keys options_act options_validate router_add_to_routerlist router_dump_router_to_string tor_free_all router_rebuild_descriptor run_scheduled_events If we focus on how many changes have *ever* been made to a function, we get these as the top offenders: router_rebuild_descriptor onion_extend_cpath directory_handle_command dns_resolve assert_connection_ok connection_handle_write connection_handle_listener_read dns_found_answer circuit_extend main connection_edge_process_inbuf connection_ap_handshake_attach_circuit config_assign init_keys circuit_send_next_onion_skin connection_dir_process_inbuf prepare_for_poll connection_exit_begin_conn connection_ap_handshake_process_socks router_dump_router_to_string fetch_from_buf_socks getconfig run_scheduled_events connection_edge_process_relay_cell do_main_loop No single list above is uniquely the right one to focus on; instead, we should probably use them in tandem to identify areas to work on. 1.2. What will be hardest to test? The entire "blob" described in section 2.1 below should be considered hard-to-test because of the number of functions reachable from one another. Removing some of this callgraph complexity will help us test, but it's not completely trivial. See Appendix A for a list of functions of this kind. 2. Untangling Tor: Modules and You If you've done a software engineering class, you probably got taught how to diagram the modules or layers of a software project. I tried this with Tor back in 2005 and my head spun; things have not gotten easier since then. Looking at Tor's call graphs tell us a lot about our issues with modularizing Tor. In the abstract, we'd like to divide Tor into layers and modules, with most modules only calling a few others, and the "central" functions limited to as little code as possible. This will make modules more independent and help us test them in isolation. This will also help us with future design ideas like splitting Tor into separate processes for testing or security or robustness purposes. 2.1. Fun with callgraphs I did some analysis of Tor's callgraph to figure out where we stand today. About 27% of the functions that tor calls (internally and externally) can reach only 10 or fewer other functions that Tor knows about. About 82% can reach a smaller portion of Tor. Then there comes a block of functions that can reach _nearly every other function_ in the block, or in Tor. They are all reachable from one another. There are about 450 of these, or 11% of the functions in Tor. I'll call them "The Blob." Finally, there are functions that can reach the Blob, and all the functions that the Blob calls, but which are not themselves part of the Blob. These are about 100 functions, or 2% of the functions in Tor. Breaking up the Blob is a high priority for making Tor more modular. So, how can we do that? * Let's start by looking at which functions, if they were made unnecessary, or if they stopped calling into the Blob, would remove the most other functions from the Blob. * Let's also start by hand-annotating the Blob with a list of functions that logically shouldn't be part of the Blob, and then seeing what they call that pulls them into the Blob. Here are some preliminary results for the best functions to try to remove from the Blob, and some antipatterns to avoid: * The following functions pull many, many other functions into the Blob: control_event_* router_rebuild_descriptor_ directory_fetches_from_authorities *mark_for_close* *free *free_ If we could stop them calling back into the blob, we would shrink the blob's size down to 254 functions, and reduce the number of outside functions calling into the blob to 74. Also worth investigating is seeing whether to remove the call from 'connection_write_to_buf_impl_' to 'connection_handle_write', and the call from 'conection_handle_write_impl' to 'connection_handle_read'. Either of these changes reduces the number of functions reachable from blob functions severely, and shifts many functions from Blob-members to Blob-callers. Finally, these might be more work to unblob: 'connection_or_change_state' 'tor_cleanup' 'init_keys' 'connection_or_close_for_error' But doing so would take the blob down to 60 functions, with the blob-callers to 118. * Many functions that are meant to simply note that an event has occurred, so that some work must happen. We could refactor most of these to instead use a deferred callback type, rather than invoking the functions that call the work directly. This would also help us decouple Blob functions from one another. * I have the blob functions listed in Appendix A.1, with the ones that would still in the blob after the changes above listed in Appendix A.2. 2.2. Separating modules into processes and libraries; module-level APIs. Let's imagine this architecture: Tor runs as a series of conceptually separate processes that communicate over a reasonable IPC mechanism. These processes correspond to module boundaries; their APIs need to be carefully designed. There is a central communications process that does the work of transferring commands and replies from A to B. APIs would be divided into publish/subscribe types and remote-procedure call types. Modules would be divided into stateful/non-stateful; non-stateful ones could be shared libraries; or if their processing is sensitive, they could be kept in very sandboxed processes. How do we get there? To make the proposal concrete, I suggest for a 0th-order draft that we imagine the following simplified version: * That all src/common modules become shared libraries with no state. * That we divide (or imagine how to divide) the contents of src/or into separate modules, with more clear connections between them. We imagine doing this one part at a time, starting by adding a nice simple publish/subscribe mechanism. * That the controller API be reimagined as a a layer on top of the rest of this. * That any multiprocess version of this be imagined, for concreteness, as ProtocolBufs over nanomsg. (I'm not tied to this particular format/transport combination; just proposing it for concreteness. We would need a transition plan here. I'd suggest that some of the easiest modules to extract first would be voting, rephist, node information management, path selection, directory data, and hidden services. Most of these have the virtue of being more easily testable once they are extracted. Once we have some significant pieces split into libraries, and submodules, we could start doing process-level refactoring, moving towards an architecture built out of processes and parts of these kinds: * Network: Has libevent-driven main loop. Accepts commands in a pool, maybe from a subthread. * Utility: Is just event-driven. Answers requests, gives responses. * Manager: starts up processes as needed and connects them to one another. * Dispatcher: relays messages from where they come from to where they go. Our best next steps in this area, IMO, seem to be to identify one or two key areas and abstractions, and begin isolating them in practice so as to better get a feel for how this kind of transition works, so we can iterate our design. [Appendices in attachment so as to keep this to a reasonable size.]

1 0

Question about estimated number of clients
by Lei Yang 26 Mar '15

26 Mar '15

Hi, I have a question about estimated number of Tor clients. I know that the average number of Tor clients per day for each country is provided on the metrics site, which is a daily basis number. I am curious if I can get a more fine-grained information about how many clients are using Tor per hour for each country? I would like to know the peak number of concurrent users who are using Tor at a given time. Can anyone please give me some clues? Thank you very much! Best, Lei

2 5

Getting visuals out of bridge bandwidth statistics
by George Kadianakis 25 Mar '15

25 Mar '15

Hello, I recently discovered that bridges report detailed bandwidth histories in their extrainfo descriptors. We should think about the privacy implications of these statistics since they are quite fine grained (multiple measurements per day) and some bridges don't have many clients (hence small anonymity set for them). Until then, I decided to visualize a bit those bandwidth histories, to better understand how much bridges are used. This took a bit longer than I expected, so I'm just going to show you some preliminary results. Here is a graph! https://people.torproject.org/~asn/bridges_bureau/bridges_daily_bandwidth.p… To generate this graph, I summed up the reported bandwidth histories of each bridge descriptor to get that bridge's daily consumption. I used the number of *read* bytes, and ignored the number of written bytes. I discarded multiple descriptors of the same bridge and bridges which did not report 24 hours worth of bandwidth history. I started with about 7603 descriptors, in the end the graphs include about 4k bridges. Basically, this graph tells us that only very few bridges see big amounts of traffic. Most bridges are concentrated on the left side of the graph. If you can't see how many bridges contribute big bandwidth because their column is so small, you can use those spikes that come from the bottom of the graph. Each such spike is one bridge. The graph is in megabytes, and its left side is too crowded. Here is another graph that might be cleaner: https://people.torproject.org/~asn/bridges_bureau/bridges_daily_bandwidth_p… This graph was created the same way, but I discarded the 200 highest observations. This makes the left hand side of the graph cleaner. Here we can see that most bridges see less than 50 MBs of traffic per day, and there are even a few hundreds of them who see none or almost none. Unfortunately, this concludes my studies for today. Maybe in the future I will work on this a bit more, and also take in account the pluggable transports that these bridges use as well as how many hours in a day each bridge did not have any activity. Questions and feedback on my methodology are welcome. If people want to work on this, I'm happy to clean up and publish my Python scripts. Cheers!

1 1

Proposal 243: Give out HSDir flag only to relays with Stable flag
by George Kadianakis 24 Mar '15

24 Mar '15

Inlining the proposal written for #8243. Feedback is welcome. Thanks! ------ Filename: 243-hsdir-flag-need-stable.txt Title: Give out HSDir flag only to relays with Stable flag Author: George Kadianakis Created: 2015-03-23 Status: Open 1. Introduction The descriptors of hidden services are stored by hidden service directories. Those are chosen by directory authorities who assign the "HSDir" flag to those relays according to their uptime. It's important for new relays to not be able to get the HSDir flag too easily, because a few correctly placed HSDirs can launch a denial of service attack on a hidden service. We should make sure that a naive Sybil attacker that injects thousands of new Tor relays to the network cannot position herself like this. 2. Motivation Currently, directory authorities give out the HSDir flag to relays that volunteer to be hidden service directories by sending a "hidden-service-dir" line in their relay descriptor, which is the default relay behavior. Furthermore, the HSDir flag is only given to relays that have been up for more than MinUptimeHidServDirectoryV2 hours. MinUptimeHidServDirectoryV2 is a parameter locally set at the directory authorities and it's somewhere between 25 to 96 hours. We propose changing that last requirement, and instead giving the HSDir flag only to relays that have the Stable flag. We believe that this will result in a few benefits: - We stop using the ad-hoc uptime calculation that we are currently doing (see dirserv_thinks_router_is_hs_dir()). Instead, we use the MTBF uptime calculation that is performed for the Stable flag which is more robust. - We increase the time required to get the HSDir flag, making it harder for naive adversaries that flood the network with relays to actually get the HSDir flag. - After implementing non-deterministic HSDir picks (#8244) we also make it harder for sophisticated adversaries to DoS a hidden service, since at that point their main attack strategy is to flood the network with relays. - By increasing the stability of HSDirs, we reduce the misses during descriptor fetching that get caused by natural churn of relays on the list of HSDirs. 3. Specification We are suggesting changing the criteria that directory authorities use to vote for HSDirs to the following: - The relay has included the "hidden-service-dir\n" line in its descriptor. - The relay is eligible for having the "Stable" flag. 4. Security considerations As it currently is, a router is 'Stable' if it is active, and either its Weighted MTBF is at least the median for known active routers or its Weighted MTBF corresponds to at least 7 days. This is stricter criteria than what's required for HSDir, which means that the number of HSDirs will decrease after the suggested changes. Currently there are about 2400 HSDirs in the consensus, and about 2300 of them are Stable, which means that we will lose about 100 HSDirs. We believe that this is an acceptable temporary loss. In the short-term future, the number of HSDirs will greatly improve as more directory authorities upgrade to #14202 and more relays upgrade to #12538. 5. Future Should we give out the HSDir flag only to relays that are Fast? Is being an HSDir a demanding job bandwidth-wise? With the upcoming keyblinding scheme (#8106) and non-deterministic HSDir selection (#8244), are there any other criteria that we should use when assigning HSDir flags?

1 0

Re: [tor-dev] #15060: Decide the fate of MyFamily / prop242 better families
by teor 23 Mar '15

23 Mar '15

> Date: Mon, 23 Mar 2015 09:32:50 -0400 > From: Nick Mathewson <nickm(a)alum.mit.edu> > >> On Mon, Mar 23, 2015 at 8:56 AM, Nusenu <nusenu(a)openmailbox.org> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Hi, >> >> I like prop242 [1] because it doesn't "Nuke MyFamily" [2] but replaces >> it with a better approach. "Better" in terms of scalability and >> maintainability. >> >> I don't know of any current 'tools' (except the tor client itself) >> that use MyFamily data but Virgil's [3] gamification website and >> compass group-by family feature [4] would depend on it. >> >> So before spending time on features that depends on an uncertain >> descriptor field, it is probably better to wait till the fate of that >> property (MyFamily) has been decided. >> >> The reason for this email is to find out when that fate will be >> decided upon? (expected answer: before tor 0.2.7.x-final is released) > > I don't know that we have a date here, or a consensus that it ought to > be done. Whether any changes happen in 0.2.7 here is going to depend > on whether we've got a solid answer one way or another on the question > of MyFamily. > > So, what do we think? I'd say that MyFamily is likely to continue to > serve a useful purpose, and that removing it entirely would be > premature given how often people come up with fun new routing and path > selection and guard selection ideas. > > On the other hand, prop242 is a fair bit of work to do, and I don't > know whether it will rise to a high enough priority over all the other > stuff we need to do. And who knows, maybe somebody will come up with > a solid argument in favor of removing MyFamily entirely? It's worth > thinking about. I can think of one good social/technical reason to keep MyFamily or similar feature(s): It provides a useful mechanism for the Tor relay community to distinguish between Sybils, technically capable enthusiastic new operators, and operators who can't/won't maintain their relays. I've seen this sort of communication a few times, but I'm not sure how frequently it happens: Someone says: "Thanks for signing up N Tor relays, please add MyFamily to each of them so we don't choose any of them in the same path." If the operator complies, they become part of the Tor network. If they decline or ignore, they are excluded from the Tor network. It would be a shame to lose such a useful technique for weeding out the bad onions, even if it relies on us finding them in the first place. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED

1 0

onionoo: grouping families in the backend?
by Nusenu 23 Mar '15

23 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I figured it might make sense to discuss this in a separate thread. > And just in case you were wondering, if you ever have a feature > request for Onionoo, I'd be happy to discuss that. In contrast to > some of its clients, Onionoo itself is actively maintained. Actually I came to the conclusion that it would make sense to move the myfamily grouping to the backend since any other compass grouping is based on onionoo data and not on data "generated" by compass itself (grouping key). The MyFamily grouping takes also a bit CPU time. So "computing" families once per generated details document make a lot more sense than recalculating them in every compass query again. Since the MyFamily is subject to change [1] is also relevant here. [1] https://lists.torproject.org/pipermail/tor-dev/2015-March/008516.html -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVEBuLAAoJEFv7XvVCELh05MMP/0Gy6zYQLbZtavXL1wdISLMg X/zdJM9+ZysuFkDj2hl0fP1iXfrNCCCvjCOdCYQJXzD5axrvgzPK/Jql1b2J1tO5 m+fbkLla9/KRCukJKYOjmkeoKAuadRDiZvI9LvePuGPrP53ZmlJmh4PT/Iss8Qh+ ndTBIbz1Kl04cBVS8RW08veFIKyzblkd2bJVj6AIlsvRvNybLJdEatgNAJ0YX6Vk ERuWuI65qP40ATFMAmL+IMsrdJ2WVdhpbbFLNkrZfloXt/UlNvFddMKlJ0k3YUkb ZQsFmZUPPv9+gMGx7Rkca94XmleBxMidjAbDVT0Y+SVyC0HxEOa5UsZ099cVu52F Hf2ZHt2E6vSxICoO4lxFEx82BxuaJLvG/+pQcNmUQk+SeBlcYn/W6PIyYV1bs9sh /pLjikLnMEMpNCls5XNc/wtFJtbnfljmsDhYL+R5jCHfUk5s3XmyEuDitenwZ8Qb 3u4qtnusQqLzW0R2bcnA8OV5RU5N12kBmFnki2lZ+m7VKtHCQVgJP8Rpvfg7G0/6 Js36UnNL2ijMNuDJED70PZEPop8kiuSZq6ePI3lYsPaLLRGLmNyHCgFQFRBox4BK ntAiePf2HtQ1kSLM2j5GLrQK5p59ko9xXrQkRBy60M5oVJkl+Rtf/+79W0Nf9f8Y /rcCkyU4s7XqW0UoHMYQ =ly6d -----END PGP SIGNATURE-----

2 5

#15060: Decide the fate of MyFamily / prop242 better families
by Nusenu 23 Mar '15

23 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I like prop242 [1] because it doesn't "Nuke MyFamily" [2] but replaces it with a better approach. "Better" in terms of scalability and maintainability. I don't know of any current 'tools' (except the tor client itself) that use MyFamily data but Virgil's [3] gamification website and compass group-by family feature [4] would depend on it. So before spending time on features that depends on an uncertain descriptor field, it is probably better to wait till the fate of that property (MyFamily) has been decided. The reason for this email is to find out when that fate will be decided upon? (expected answer: before tor 0.2.7.x-final is released) Nick's statement: > Having some paths with all three nodes in the same family scares > me gives me some hope that it won't go away completely and will allow me to group relays to an operator (as long as the operator decides to configure it). Even in the unlikely event of MyFamily being nuked completely (with no replacement) - I guess it will be some years(?) till you deprecate pre tor 0.2.7 clients? [1] https://trac.torproject.org/projects/tor/ticket/6676 [2] https://gitweb.torproject.org/torspec.git/tree/proposals/242-better-familie… [3] https://lists.torproject.org/pipermail/tor-dev/2014-June/006975.html [4] https://raw.githubusercontent.com/nusenu/misc-files/master/biggest_tor_rela… -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVEA1hAAoJEFv7XvVCELh0cUYP/jl5EknR8EC9A5KNS9rWR/4J PEOz9u/6ySu4Pn1oDaWw7zjZK3IAzaqTdDenHq4et4U4GmrLG7JaKTdhL3pAmc8W mBNzwgE7FvYDgxKAwbh7fdVS2mD13QyZ6e9SPqdYQiR7WkKF1Ep5omp1HGoyGe4M mPo413K21SvkXGBcIhf62+R20renwTTNQ6G2dWB2wwlcjKoUJ385p7TYeNBbA/Jd NjCSmfAFFX7OeC8XuP/EHdf7+5CZI/SVn5Dq3oxZIpABNl4UdDzHdjRUoXSCEvxh hxpFbp7nozV7++73QUD5ECAFjUe98siKYODSFGb/xBMA9rCm93JKLKPB8iJPy8RO 8+D+qKsK0PFQVpEbbu/Uix2gcg68lTmv/zhHt1vVtT0h13LLtHyTQGQQ1SihcNlS Jv0mSxL3wDCs/yVRVR8r76MOdMAh891rPUzrW0/TxCc6W/LWXsA2ST4xt7zE8RQf LDWqlmSO6813M5vuEXZYFBQ+GsOquTUssPRKc/l1Ik8V628LYDvyfkN8QAJ72MDR HPkc6RGmHUVejpTUa9pcSbol2F96pEZ8XVYCyX3pIRoPiqlq0phnOlctaQFeAyGN 75FfN/GhEW2JDpqmIsD0BQbgcYTHa+qMiRZ8mWE9NRkQKIcDXyOTY7nIt810wbp9 0idgIP01pqKYPzhhaO5h =81G7 -----END PGP SIGNATURE-----

4 3

RFC: Ephemeral Hidden Services via the Control Port
by Yawning Angel 23 Mar '15

23 Mar '15

Hi, The Warning: DO NOT USE MY BRANCH YET, IT HAS HAD MINIMAL TESTING AND REVIEW. IT IS NOT DONE. IT WILL BROADCAST YOUR SECRETS TO THE NSA'S ORBITAL SPACE STATION. Trac Ticket: https://trac.torproject.org/projects/tor/ticket/6411 Branch: https://github.com/Yawning/tor/compare/feature6411 With that out of the way, I've been poking at implementing a way to add hidden services at runtime via the control port. I'm calling this "ephemeral hidden services" because the HS state is not written out to disk, and they disappear when the tor damon is shutdown. Yes, this means that if you run "kittensomgmewmew.onion" and are scared of the NSA's persistent attempts to extract your hidden service key, via ultrasonic laser beamed from their satellites, you could run your tor instance entirely in a ram disk, and load the HS key manually each time from a USB token you wear around your neck. What I've come up with looks like this: ADD_EPH_HS - Adds a new ephemeral hidden service. The syntax is: "ADD_EPH_HS" keytype:keyblob SP 1*(port SP addrPort) CRLF keytype = "RSA1024", "NEW" keyblob = opaque ascii serialized key material, or an algorithm specifier, in the case of "keytype" == "NEW". port = the "VIRTPORT" addrPort = the "TARGET" A hidden service is created using the key and list of port/targets, that will persist till configuration reload or the termination of the tor process. The currently supported keytypes and keyblobs are: "RSA1024" - The keyblob contains the Base64 encoding of the PKCS#1 layout DER representation of a 1024 bit RSA private key. "NEW" - The tor instance should generate a key with the keytype specified in the keyblob parameter. A type of "BEST" will generate a key using the best supported algorithm. Returns: "250-ServiceID=serviceID" - The hidden service's onion address without the ".onion" suffix. "250-PrivateKey=keytype:keyblob" - The newly generated hidden service's private key, if a keytype of "NEW" was specified. "250 OK" - Everything went well. Proper key management, is left as an exercise for the application invoking the controller command. DEL_EPH_HS - Removes an existing ephemeral hidden service. The syntax is: "DEL_EPH_HS" serviceID CRLF serviceID = the hidden service identifier, without the trailing ".onion" suffix The hidden service specified by the given service ID is removed, and the intro points are closed. Existing connections are left as is, and it is up to the application to close them if it wishes to do so. Examples: * Adding a new ephemeral hidden service, with a pre-generated RSA key: > ADD_EPH_HS RSA1024:[Base64 blob] 80 127.0.0.1:8080 < 250-ServiceID=blahblahblahblah < 250 OK Hidden service is reachable at blahblahblahblah.onion:80 * Adding a new ephemeral hidden service, tor generates a new RSA key: > ADD_EPH_HS NEW:RSA1024 22 127.0.0.1:22 < 250-ServiceID=hogehogehogehoge < 250-PrivateKey=RSA1024:[Base64 blob] < 250 OK Hidden service is reachable at hogehogehogehoge.onion:22. At a later date, the value passed back as "PrivateKey" can be used to re-create the hidden service. * Add a new ephemeral hidden service, tor picks the algorithm: > ADD_EPH_HS NEW:BEST 1245 192.168.1.5:23 < 250-ServiceID=hemohemohemohemo < 250-PrivateKey=Ed25519:[Base64 blob] < 250 OK Hidden service is reachable at hemohemohemohemo:23. (nb: Ed25519 key support is not actually implemented yet, and is used as an example of a better algorithm.) * Remove the hidden service configured in the first example: > DEL_EPH_HS blahblahblahblah < 250 OK Note: ADD_EPH_HS can take more than one VIRTPORT/TARGET pair at once, the examples only show one pair for brevity. This does not support `HiddenServiceAuthorizeClient` yet in any way (neither basic nor stealth). It may in the future, but coming up with a sane interface for it is way more pain than I am willing to self-inflict at the moment. Design question that I want feedback on, primarily from control port library maintainers, and authors of applications that use the control port: * meejah suggested that ephemeral hidden services should have their lifetime tied to the originating control port connection. I think this is a good idea, but this would be the only control port command that does this sort of thing. My motivations for strongly considering implementing this is that, I don't think that adding a command to enumerate hidden services is a good idea (SketchORChat has no business in seeing what hidden services JankORFileSharing is using), and that this will automate cleanup in the event of an application crashing, or not removing it's hidden services before terminating. * Does this interface expose enough functionality, in a way that is intuitive and easy to use? (The initial version I was planning on proposing made key generation entirely the application's problem, but nickm convinced me otherwise). Questions, comments, feedback appreciated, -- Yawning Angel

11 28

compass: new group by options: by-contact, by-OS, by-version
by Nusenu 23 Mar '15

23 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Karsten, I added a few new grouping options to compass: - -T --by-contact (#6675) (Maybe we should truncate contacts and remove the undefined) - -O --by-os - -V --by-version (#6855) +expose -N options in html (was implemented but not exposed in gui) https://github.com/nusenu/tor-compass For all output I (mis)used the nick column as a quick solution since it is not used otherwise when grouping. Advertised bw is broken for some time. There is no 'advertised_bandwidth_fraction' (This field was removed from onionoo in November 2014.). Is it ok to change this to observed_bandwidth? (which would be a non fraction item)* ? (The MyFamily lookup is also broken) short commit log: - - add new group by ContactInfo option: by_contact (-T, --by-contact) (quick 'n dirty) - - added new grouping -O, --by-os (all BSDs are merged into one group) - - added new grouping by tor version (-V, --by-version) - - tell app.py about new options (by_version, by_os, by_contact) - - expose -N option in html and fix a missing label tag - - include network data in html output when using -N (uses nick column) - - expose by_version, by_os and by_contact options in HTML - - if it is just one item, display the actual value for AS and CC instead of saying (1) What do you think about it? thanks, Nusenu *) while playing with that I found 3 relays from JP that have a suspiciosly high adv bw: https://atlas.torproject.org/#details/F528DED21EACD2E4E9301EC0AABD370EDCAD2… https://atlas.torproject.org/#details/8901B1D2D4C0D3398C3F8363247B5AABF3136… https://atlas.torproject.org/#details/4EA0464A1B8D4231F176BA2FA1BCBF0A26F12… reminded me of SKKU43: https://lists.torproject.org/pipermail/tor-talk/2014-February/032094.html -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCtlTAAoJEFv7XvVCELh0bY0P/1aJyZncqdy47WZM9I7Y1E4a Sg1luXTqi9VlFZhbUJeFrhidLVPSqQYbMw79sKufU2uw/Jcqr0Ro2O48q9Gj7sL8 lDcM4AgFzm1yTedoXqyNAA5+bBeQTAjEgQU1ADYUZvDx2ULmGG4aD6qCuaFoP+3/ kjJ6r92jLOSYpOVdt8FyNc8IZYpbEwQNMKc4A0uZhQV/WVv6vFiOaXHliPdR6m2+ SU+KTqldWppfeezWIalGl3t7HEnz87JOaWrdnQ8fjLKSsqkex2T5E1MClguM4u2o 5ABPxg6uF/izjPv2VEy/hl42RQbLM5SDazM4CLMFN3mQu6Xa4iZ5R8A6iLDgZBj6 zK2wExcxScc58r4Briv5EKUpC9LTgE52DkPkX+TM3i9ktniYQbb/k/cy85nn+ENa WrZ2WDmaMyQXy6kXDCS4U/3gbv1+Dwq82hg372N2fga6hOXsZPFrxV1TwWlMTzp9 MvpaF6/GZsivrjNklteHxvxgcxTyywaKW5QUdFJdeCZnOrDy29iGKIql10xQ7TXa gTC7OTsDCAPiJn8P5xKhEAlVeJmz0zZN7QhbY/ybIc5KWkOoKyYwkT9ysmpS8rOK mapKbuMXvuA3Sg1F1sK9PEUy+D8ZAe+sBjOEHzqILARA6VXsly0rSJkcnhNKNpmL yxSwWe4uWOVXDmVEl7hQ =jGQe -----END PGP SIGNATURE-----

3 7

#if 0 unused functions?
by Sebastian Hahn 22 Mar '15

22 Mar '15

Hi there, we have some functions which we never call anywhere. In many cases, it appears we shouldn't delete them from the source because they "belong" there - the thing I initially stumbled across was ed25519_seckey_write_to_file(), for example. But I also don't see why compiling it and potentially including it in our binary makes any sense. Thoughts? Cheers Sebastian

2 1

Re: [tor-dev] #if 0 unused functions?
by teor 22 Mar '15

22 Mar '15

> Date: Sun, 22 Mar 2015 05:12:03 +0100 > From: Sebastian Hahn <sebastian(a)torproject.org> > To: tor-dev(a)lists.torproject.org > > Hi there, > > we have some functions which we never call anywhere. In many cases, it > appears we shouldn't delete them from the source because they "belong" > there - the thing I initially stumbled across was > ed25519_seckey_write_to_file(), for example. But I also don't see why > compiling it and potentially including it in our binary makes any sense. > > Thoughts? > > Cheers > Sebastian I'm think that removing / disabling unused code is a great idea, but I wonder what happens over the long term: [How] do we prevent bit-rot on the disabled code? Does the disabled code have unit tests? Should we add unit tests or keep them active to prevent bit-rot? Or should any unit tests be disabled too? I wonder if we could unit test unused code, but not link it into the tor binary. This would make sure it works if we ever want to use it in future, but without the risks and performance impacts of including unused code in the binary. There could be issues with this strategy that I haven't thought of. Like the added maintenance cost involved in keeping unused code and unit tests up-to-date. Perhaps we could: * remove entirely if we're unlikely to ever use the code, * disable if we want to keep it around for future reference, and * unit test it, but not link it in to the tor binary, if we think we'll use it soon. Which category do most of the unused functions fall into? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR C3C57B23 349825DE 929A1DEF C3531C25 A32287ED

2 1