- tor-dev - lists.torproject.org

[Measurement Team] Next IRC meeting happens on Wednesday, Aug 12, 14:00 UTC in #tor-project
by Karsten Loesing 11 Aug '15

11 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team on Wednesday, August 12, 2015, 14:00 UTC in #tor-project https://www.timeanddate.com/worldclock/fixedtime.html?iso=20150812T14 Suggested agenda is: - 1-1-1 task exchange: you get 1 minute to describe a task that would take somebody else roughly 1 hour and that they will do for you within 1 week (review a document, write some analysis code, fix a small bug, etc.; better come prepared to get the most out of this; give 1, take 1) - Priorities: should we focus more on a certain aspect of measurements in the Tor network, while temporarily suspending or even permanently dropping other aspects? Let's talk about how we can add such priorities to the roadmap draft we have been working on [0]. - Misc/discussion: whatever comes up during the meeting If you think this can be fun, please join us at the meeting! Talk to you tomorrow! All the best, Karsten [0] https://people.torproject.org/~karsten/volatile/measurement-roadmap.pdf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVyhwAAAoJEJD5dJfVqbCrjkMIAMCUpfVBIw2GWaPLMgW9MSFo 1ANENAwisD86f2r+ypRtBtK28TDN4d3cauACkqY8zLHs4ZzghO0f58Ob9ZhGgHei jkOM2i/M/yBEZehAit2kYoeND8gfWdW2vj5HufFF2khw+xFsL1+oQgVyurfdMQ3/ TfI1iWBuv5NSTQx4h/W64DJ9vagwYiLNvPrI2TbO2hhOiEKS1nIMZ3vYjI2V3Yff 0rjGsTd3WMm2AIarbJtVoeFW2jgqeweSFR5M+aAYdsRRKH/nRdcl6ToVPro+8uih I3GRCFJpEIh1CHJSGvfLuazJ88W1INYf/LQiOkEAx8CiSshBHar+0JpWOMpsrfc= =ZC0R -----END PGP SIGNATURE-----

1 0

Tor's default behavior for ed25519 identities
by s7r 11 Aug '15

11 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Tor 0.2.7.x will support Ed25519 router identities along with the traditional 1024-bit RSA ones which will be used simultaneously for some time, until we will completely deprecate RSA router identities. I would like to document what Tor needs to do (or don't do) by default in some cases to prevent mistakes which confused operators could do. Please review and add/edit/remove if something is wrong, doesn't make sense or is incomplete. When finished, I will split it in more parts and open tickets on trac based on priorities. Some cases are already covered (Tor does what it should by default). We also need to compose the messages Tor will print in the log files in a way that they will be of a reasonable length and expressive/explicit/polite/whatever. Take in consideration the design: For an Ed25519 identity, Tor will generate these files in $datadirectory/keys: - - ed25519_master_id_secret_key - the master identity key. Optionally this can be kept offline or encrypted. This is the file one needs in case he wants to restore a relay. Never expires. Sensitive (if reached it will compromise the identity of the relay forever). - - ed25519_master_id_public_key - the public key. This is the actual router identity which Tor publishes in the descriptors. It is computed from the secret key and it is not sensitive. Never expires. - - ed25519_signing_secret_key - a temporary signing key. This will be used for circuits (onionskin) encryption. It is valid only temporary for as long as ed25519_signing_cert says so. - - ed25519_signing_cert - a cert signed by the master ID key (ed25519_master_id_secret_key) attesting that the ed25519_signing_secret_key 'x' is valid for 'n' days/months. The validity period can be configured with the torrc option SigningKeyLifetime 'n' days/weeks/months (default is 30 days). Also take in consideration that the directory authorities will pin relays with paired RSA-Ed25519 identities and reject them if one changes. For example, if relay A has ID RSA_A & Ed25519_A, and later changes to RSA_B & Ed25519_A or RSA_A & Ed25519_B, it will be rejected. The text is also available on Etherpad: https://etherpad.mozilla.org/efIBq6nDwt - ------------------------------------------------------ Ed25519 router identity - default behavior - ------------------------------------------------------ We don't touch the RSA ID key behavior. We let it as it was, use it if secret ID file is there, generate new one if not. The behavior below should be implemented by taking in consideration only the ed25519_* files in $datadirectory/keys (should not care or notice the RSA related files). We don't say anything about offline Ed25519 ID keys or encrypted Ed25519 ID keys. Whoever wants to use these features will have to read the FAQ first and understand some things. The default is: generate ed25519_master_id_secret_key (unencrypted) in $datadirectory/keys and use that forever, by automatically renewing ed25519_signing_secret_key and ed25519_signing_cert with the default validity period of 30 days, unless otherwise specified in torrc. This is already implemented and it is how Tor works now. At every start, restart, reload, server reboot, signal sent by user or another app, etc. Tor should: 1) check if file ed25519_master_id_secret_key exists in $datadirectory/keys and it's a valid curve25519 private key file; 2) check if file ed25519_master_id_secret_key_encrypted exists in $datadirectory/keys; 3) check if file ed25519_master_id_public_key exists in $datadirectory/keys and it's a valid curve25519 public key file; 4) check if file ed25519_signing_cert exists in $datadirectory/keys; 5) check if ed25519_signing_cert in $datadirectory/keys is expired; 6) check if ed25519_signing_cert correlates with ed25519_master_id_public_key; 7) check if file ed25519_signing_secret_key exists in $datadirectory/keys; 8) check if ed25519_signing_secret_key correlates with ed25519_signing_cert (non-expired cert refers to that signing key); 1. If ed25519_master_id_secret_key && ed25519_master_id_public_key && ed25519_signing_secret_key && ed25519_signing_cert are all missing from $datadirectory/keys: - -> We assume it's a new relay or a relay which just upgraded to a Tor that supports Ed25519 router identities. Generate a new Ed25519 identity unencrypted (ed25519_master_id_secret_key, ed25519_master_id_public_key, ed25519_signing_secret_key and ed25519_signing_cert with a validity for 30 days unless specified otherwise in torrc) and publish a descriptor using that, proceed as normal after. 2. If ed25519_master_id_secret_key is missing or exists encrypted && ed25519_master_id_public_key exists in $datadirectory/keys and ed25519_signing_secret_key and ed25519_signing_cert are expired: - -> We assume this can happen suddenly, while running unattended. Disable relay functionality and stop publishing descriptors (close ORPort and (if open) DirPort). Leave client functionality since that could be used by something else on that machine and it shouldn't be affected. Print warnings in the log file that action is required (generate new ed25519_signing_secret_key and ed25519_signing_cert or move the ed25519_master_id_secret_key unencrypted in $datadirectory/keys so Tor can do this by itself). The operator needs to signal Tor with a reload signal (HUP) or restart/stop & start after completing the action. Tor will check for the valid ed25519_signing_secret_key and ed25519_signing_cert by itself every time server restarts (along with Tor process) or at every automated reload signal (HUP). 3. If ed25519_master_id_secret_key exists unencrypted in $datadirectory/keys and there is no ed25519_master_id_public_key, ed25519_signing_secret_key or ed25519_signing_cert (or ed25519_signing_secret_key and ed25519_signing_cert are expired): - -> We assume the relay has just been restored and the Ed25519 identity was backed up. Automatically generate ed25519_master_id_public_key, ed25519_signing_secret_key and ed25519_signing_cert with a validity period of 30 days (unless otherwise specified in torrc). - -> Since we have the ed25519_master_id_secret_key unencrypted, and at startup we always check for availability/validity of the other ed25519* files by default anyway, we should generate automatically in this case: ed25519_master_id_public_key (if missing), ed25519_signing_secret_key (if missing or expired) and ed25519_signing_cert (if missing or expired). 4. If ed25519_master_id_secret_key exists encrypted in $datadirectory/keys && there is no ed25519_master_id_public_key, ed25519_signing_secret_key or ed25519_signing_cert (even if just one of these 3 is missing): - -> We assume the relay identity existed previously and ed25519_master_id_secret_key_encrypted was restored form a backup. Do not start Tor at all and print explicit warnings that action is required - Tor cannot decrypt the ed25519_master_id_secret_key_encrypted file. Generate ed25519_master_id_public_key, ed25519_signing_secret_key and ed25519_signing_cert or decrypt the ed25519_master_id_secret_key_encrypted in $datadirectory/keys so Tor can do it by itself. 5. If the chain validation fails (ed25519_signing_cert doesn't correlate to ed25519_master_id_public_key AND/OR ed25519_signing_secret_key doesn't correlate to ed25519_signing_cert): - -> We assume the operator probably runs many relays and holds many ed25519_master_id_secret_key files maybe accidentally mixes them and generates temporary signing key and key cert using the master key from another relay. Do no start Tor service at all and print warnings: the ed25519_signing_secret_key and ed25519_signing_cert are generated with the ed25519_master_id_secret_key of another relay. These files should be removed and replaced with the correct ones (search for the ed25519_master_id_secret_key which belongs to this relay). Otherwise it's useless (since we already reject RSA-Ed25519 which don't match), if the ed25519_master_id_secret_key is lost permanently, nothing else for the operator to do but to manually generate fresh identity both RSA and Ed25519 so the relay can be part of the consensus (start from scratch). 6. If ed25519_master_id_secret_key is missing or _encrypted AND ed25519_master_id_public_key is also missing from $datadirectory/keys AND a) we have an ed25519_signing_secret_key and ed25519_signing_cert which are not expired: - ->Automatically compute ed25519_master_public_key from the ed25519_signing_cert and save it in $datadirectory/keys. b) if ed25519_signing_secret_key and ed25519_signing_cert are expired: - ->Do no start Tor service at all and print warnings that user action is required (generate new ed25519_signing_secret_key and ed25519_signing_cert or move the ed25519_master_id_secret_key unencrypted in $datadirectory/keys so Tor can do this by itself). The operator needs to signal Tor with a reload signal (HUP) or restart/stop & start after completing the action. Tor will check for the valid ed25519_signing_secret_key and ed25519_signing_cert by itself every time server restarts (along with Tor process) or at every automated reload signal (HUP). - ------------------------------------------------------ Commands related to Ed25519 keys - ------------------------------------------------------ 1. tor --keygen should be replaced with tor --ecckeygen (keygen is not explicit enough since we are talking about 2 router identities which are used simultaneously [RSA and Ed25519]). - - Ask if user wants to encrypt the key with a passphrase and if yes ask 2 passphrase confirmations. Only allow ASCII, check and return invalid passphrase otherwise (local language keyboards mess things up). I suggest the Encrypt key? question [y/N] should be a No by default. - - Unless user specifies --out /path/to/dir to save the output files, save them in working directory (where the command is run). Do not create the folder and save them in $HOME/.tor. - - Only generate an ed25519_master_id_secret_key with this command (no ed25519_master_id_public_key, ed25519_signing_secret_key or ed25519_signing_cert). Print a message confirming this: ed25519_master_id_secret_key was successfully generated and saved encrypted/unencrypted (depending how it was generated) in $location ($location = either working directory where the command was run either the location specified separately with --out argument included in the - --ecckeygen command). Append _encrypted at the end of the file name in case a passphrase was provided. 2. tor --encryptkey <ed25519_master_id_secret_key file> or /path/to/<key file> - - check if it's a valid ed25519_master_id_secret_key unencrypted, ask for 2 passphrase confirmations and encrypt it. Only allow ASCII, check and return invalid passphrase otherwise (local language keyboards mess things up). - - ask if the user wants to delete the old plaintext ed25519_master_id_secret_key and only remain with the encrypted copy. [Y/n], Yes by default. Delete it in a secure way if yes, obviously. - - save the encrypted key in the working directory where the command is run or with an argument --out /path/to/dir. Print a message confirming this: ed25519_master_id_secret_key was successfully encrypted and saved in $location ($location = either working directory where the command was run either the location specified separately with --out argument included in the --encryptkey command). 3. tor --decryptkey <ed25519_master_id_secret_key file> or /path/to/<key file> - - ask for confirmation: Are you sure you wan to decrypt your ed25519_master_id_secret_key? This will save the master ID key in plaintext, not protected by a passphrase. [Y/n], Yes by default. - - ask for the passphrase and decrypt. - - ask if the user wants to delete the old encrypted ed25519_master_id_secret_key and only remain with the unencrypted copy of it. [y/N], No by default. - - save the plaintext key in the working directory where the command is run or with an argument --out /path/to/dir. Print a message confirming this: ed25519_master_id_secret_key was successfully decrypted permanently and saved in $location ($location = either working directory where the command was run either the location specified separately with --out argument included in the --decryptkey command). 4. tor --newpasskey <ed25519_master_id_secret_key file> or /path/to/<key file> - - ask for the current passphrase. - - ask for the new passphrase 2 times. Only allow ASCII, check and return invalid passphrase otherwise (local language keyboards mess things up). - - update the ed25519_master_id_secret_key file with then new passphrase in place, don't save a separate new copy with this command. - - print a message confirming that the passphrase has been successfully and permanently changed. 5. tor --gensignkey <ed25519_master_id_secret_key file> or /path/to/<key file> - - ask for the passphrase if key file is encrypted. - - generate new ed25519_signing_secret_key and ed25519_signing_cert valid for 30 days unless specified otherwise in torrc. If there is a SigningKeyLifetime in torrc, read it and ask the user: The signing key lifetime in your torrc is n days/weeks/months, use this validity period? [Y/n], yes default. If user enters N, ask the user to manually enter the lifetime. - - save the output files in the working directory where the command is run or with an argument --out /path/to/dir. Print a message which explains that these files need to be moved in Tor's $datadirectory/keys. - - Print a message confirming this: ed25519_master_id_public_key, ed25519_signing_secret_key and ed25519_signing_cert with a validity period of $validity have been successfully created and saved in $location. Please move them to your Tor $datadirectory/keys folder and make sure Tor can access/read them. ($validity = SigningKeyLifetime in torrc or lifetime manually specified by the user or 30 days, the default if there is no torrc setting for this and no input from the user; $location = either working directory where the command was run either the location specified separately with --out argument included in the --gensignkey command). 6. tor --getpubkey <ed25519_master_id_secret_key file> or /path/to/<key file> - - ask for the passphrase if key file is encrypted - - compute the ed2551_master_id_public_key - - save the output file ed25519_master_id_public_key in working directory where the command is run or with an argument --out /path/to/dir. - - Print a message confirming that the ed25519_master_id_public_key has been saved in $location ($location = either working directory where the command was run either the location specified separately with - --out argument included in the --getpubkey command). - ------------------------------------------------------ Permissions - a thing many users don't know/care about: - - If Tor cannot complete a command from above because it does not have permission to read the ed25519_master_id_secret_key print an error message and instruct the user that he should run the tor command as the rightful user or change permissions over the ed25519_master_id_secret_key file. - - If Tor cannot save the output files resulted from a command because it does not have write permissions in the working directory where the command is run or the destination directory manually specified with - --out argument included in command print an error message and instruct the user that he should either run the tor command as the rightful user or select a destination directory where current user has write permissions. - - Always save the output files when using above commands with the correct permissions (I guess these are chmod 0600?). - - Can Tor work if the files in $datadirectory/keys folder are owned by other user than the one running Tor? If not, we should try to detect what user runs Tor on that system (not everywhere Tor runs under debian-tor, in FreeBSD it is _tor for example) and change the owner of the files after they are generated and saved. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBCAAGBQJVv/FNAAoJEIN/pSyBJlsRQJYIAJvO10nrCyGR7ImHptZS+GGN DQS424+drGF5uwMunADN/m9MQ2sqXBfa9xA74irA9KU4y1HtY4NUTJZWC9mUrlZv xb8nkp1jml6NMk7M8RQ/A330Ca04bTNcMOzvaBwqDodlG4GDuiNBMnia2SIqzaBD WSLzVQ1wz5zVdF5CPblQXIzS8jhLYQU4wjQf3Z7nnmPgjjn4HNKcd9Q9x/DWRCL7 TsdgE05ZCHpjCzep9xi0RhPV4tdY77Yti7n9b81ty4O+ctYSU8kzvYhiY4nglnDH YQvJSvDH2QnNqR6QXcC+cHSLAkoJMM56OLKoZmhU6cJkbZ3aC/9I5EcFyAZs62E= =X/f3 -----END PGP SIGNATURE-----

2 8

please can haz code review -> Tor-ified Twisted Python HTTP proxy server - txtorhttpproxy
by David Stainton 11 Aug '15

11 Aug '15

Dear Twisted/Tor developers, I am motivated by language security concerns. I think Twisted Python can often implement excellent replacements for our old crufty C implementations. In this case I'd like to stop using C programs running as root (or not root) to torify http connections... like privoxy, polipo, apt tor transport etc. Last year I wrote this little tor http proxy; yes it also handles RFC 2817 proxy CONNECT method as well: https://github.com/david415/txtorhttpproxy I wrote an AgentProxy that can proxy any sort of twisted http agent: https://github.com/david415/txtorhttpproxy/blob/master/txtorhttpproxy/proxy… It used to use more terrible underscore imports but Leif fixed the bit-rot and made it work with Twisted 15: https://github.com/david415/txtorhttpproxy/commit/38f1a0cfab586f7a8965a47e9… Is this project worthy of your precious 10 minutes to review it... so I can improve the code quality? If I get rid of this last terrible import: from twisted.web._newclient import ResponseDone then I'm not sure how to detect when to call the finish() method here: https://github.com/david415/txtorhttpproxy/blob/master/txtorhttpproxy/proxy… Sincerely, David Stainton

1 0

Re: [tor-dev] First release of OnioNS for beta testing
by Jesse V 10 Aug '15

10 Aug '15

Thanks Dr. Fu, I look forward to your comments. From the server log, apparently so far no one has tested the client, though someone has set up a server. I just want to highlight that I have servers up and running so the client and the HS functionality should work out of the box. For the client, install the software then follow the instructions in the README to integrate it into the Tor Browser. My current approach is to rename the Tor binary from "tor" to "torbin" and then insert a symlink to the onions-tbb executable under the name "tor". Then the onions-tbb software lauches "torbin", "onions-client", and the Stem script in that order, thus allowing all the necessary software to start with the Tor Browser. I have also added some functionality to wait until Tor is fully bootstrapped before launching onions-client and the Stem script, thus this approach is fully compatible with Tor bridges. Jesse V. > Subject: > Re: [tor-dev] First release of OnioNS for beta testing > From: > Xinwen Fu > Date: > 08/08/2015 04:25 AM > > To: > "tor-dev(a)lists.torproject.org" <tor-dev(a)lists.torproject.org> > > > Fantastic work. Will test it. > > Xinwen Fu >

1 0

Invitation to participate in a survey about Tor's future
by Sue Gardner 09 Aug '15

09 Aug '15

Hello people of tor-dev, You may have heard that I'm working with the Tor Project to help it develop a strategic plan [1]. To kick off, we're running a survey asking Tor-related people their opinions about Tor and its future. I'd like to invite you to participate: https://www.surveymonkey.com/r/tor_core The survey's pretty short and should take about 15 minutes to fill out. If you have time to do it within the next few days, that would be great. We'd really appreciate your input :) If you've got questions, there's an FAQ here (or you can just ask me here on this list). https://trac.torproject.org/projects/tor/wiki/org/Strategy/SurveyFAQ Thanks, Sue [1] http://suegardner.org/2015/05/20/why-im-working-with-tor-and-first-look/

2 1

collector problems since 2015-08-07 18:00?
by nusenu 08 Aug '15

08 Aug '15

Hi, I was wondering why onionoo reported empty platform strings for a growing number of relays. I wanted to confirm that by looking at collector data, but then I noticed that there is a problem with collector data itself. Files in [1] usually have a size of around 1 MB, currently they are at 1KB (basically empty). @thomas: Is that the cause for your onionoo instance issue? [1] https://collector.torproject.org/recent/relay-descriptors/server-descriptor…

3 3

First release of OnioNS for beta testing
by Jesse V 08 Aug '15

08 Aug '15

Happy Saturday everyone, At long last, 310 commits later, I am pleased to present a release of the Onion Name System (OnioNS), a DNS for Tor hidden services. This release is a usability test; it offers reliable behind-the-scenes integration with the Tor Browser, a friendly command-line dialog for claiming domain names and subdomains, and many options for hosting and configuring a server. The system utilizes two servers: a single Quorum node which hidden services upload their claims to and another server which clients query against. I am looking for feedback as to how usable the system is and areas where it could be improved. Most of the changes going forward will be behind-the-scenes. The software is divided into three primary pieces, OnioNS-client, OnioNS-HS, and OnioNS-server. These all have OnioNS-common (a shared library) as a dependency. You can install whichever one you'd like, or all of them. This software is currently Linux-only, and Debian 7 and 8, Ubuntu 14.04 - 15.10, Mint 17 - 17.2, and Fedora 21 - 23 are supported. I provide packages for Debian 7 and a software repository for currently-supported versions of Ubuntu and Mint on 32-bit, 62-bit, and ARM systems. If possible, please use the repository. Please see the READMEs in the following repositories for more information, including installation, initialization, and configuration procedures. Manpages are also included for your convenience. https://github.com/Jesse-V/OnioNS-common https://github.com/Jesse-V/OnioNS-client https://github.com/Jesse-V/OnioNS-HS https://github.com/Jesse-V/OnioNS-server Please star the repository if it works well for you. I have claimed "example.tor" for my project's HS and claimed the "arma.example.tor" subdomain that points to Roger's site, so you can test this from the client. Please open a ticket if you find a new bug, or contact me if you don't have a Github account. A brief FAQ: Q: How does one pronounce "OnioNS"? A: As one would pronounce the lowercase form: "onions", the plural of "onion". Q: It only takes a couple of minutes to claim a domain name, isn't that too easy? A: In this release, I have set a very small difficulty level. It will certainly be harder in the future and more counter-measures are being considered. Also, since the claims are not yet saved to disk, I offer no guarantee of their long-term survival. Q: Should I use this on production hidden services? A: No, this software is not ready. This release introduces _features_, not security. Tor circuits are used on both the client and HS side, but I can't guarantee that my SOCKS use is leak-proof, for example. I'm asking for help with finding bugs that may compromise anonymity. Q: I'm running Windows/OSX/BSD/Arch/Gentoo/LFS/etc, can I test OnioNS? A: Yes, but I'm not currently supporting that environment, so you're mostly on your own. However, if you can give me compilation instructions, I may be able to. I am also looking to coordinate with anyone familiar with RPM or Windows development. Q: Is there security on your network communications? A: Client and HS communication occurs over Tor circuits, and there are some integrity checks, but simply getting everything to work is the priority here. Most of the infrastructure is set up so adding signatures and such will be easy, but that is next on the list. Once that occurs, the name server (Mirror) the client uses can be malicious with no significant impact. Q: Where can I learn more about this project? A: The normal project page, onions55e7yam27n.onion, is currently being rewritten. A simple page is in its place, so "example.tor" is still there. Literature on this project may be found at https://github.com/Jesse-V/OnioNS-literature. Please see the PDFs under the respective folders. Note that the distributed design will be changing to use George's commit-and-reveal scheme. Q: Are the servers reliable enough to run under Comcast? A: I have not tested them in production or otherwise under https://github.com/tylertreat/comcast, but I may in the future. I welcome help in this area. Enjoy, Jesse V.

2 1

simple onionoo patch
by firebrand＠ruggedinbox.com 07 Aug '15

07 Aug '15

Hi, I have submitted a small patch some time ago to fix some issues in onionoo. Could someone have a look? https://trac.torproject.org/projects/tor/ticket/16626 ** firebrand

2 1

Relay Dashboard Code Review
by Damian Johnson 05 Aug '15

05 Aug '15

Hi Cristobal, again apologies for the delay in getting you feedback. Just gave RWSD a whirl and worked great - nice work! >From a UI perspective only feedback on what we have so far is... * Both graphs just have the title of 'Graph component'. Better would be to say if it's inboud or outbound. * Graph's y-axis should indicate its units. * Personally I kinda like Vidalia's line graph better than bar graphs for this, but obviously just something to experiment with. Lots of options. https://upload.wikimedia.org/wikipedia/commons/e/ef/Tor-non-exit-relay-band… * Only having fifteen seconds of information is pretty short. Actually, if you raise it to something high (like several minutes of data) then you might want to consider prepopulating bandwidth information from before RWSD started. Here's how Nyx does it... https://gitweb.torproject.org/nyx.git/tree/nyx/graph_panel.py#n244 Unfortunately I'm still a bit of an Angular noob so I can't comment much on those bits. Arturo: do you have any thoughts? Otherwise, here's some feedback on the code! ============================================================ run_client.py ============================================================ 23 settings = dict( 24 template_path=os.path.join(os.path.dirname(__file__), "client/templates"), 25 static_path=os.path.join(os.path.dirname(__file__), "client/static"), 26 autoescape=None, 27 ) 28 handlers = [ 29 (r"/", MainHandler), 30 ] 31 cyclone.web.Application.__init__(self, handlers, **settings) Very minor thing, but little odd using dict() that way. This could also be... handlers = [ (r"/", MainHandler), ] cyclone.web.Application.__init__(self, handlers, { template_path: os.path.join(os.path.dirname(__file__), "client/templates"), static_path: os.path.join(os.path.dirname(__file__), "client/static"), autoescape: None, }) Again, minor and up to you. run_server.py has the same. This is similar to what I do all throughout my codebases... https://gitweb.torproject.org/nyx.git/tree/nyx/graph_panel.py#n71 ------------------------------------------------------------ 37 reactor.listenTCP(int(config.get('client.port')), Application()) Actually, you don't need the int() if you provide a default. If you call... config.get('client.port', 9051) ... then the config will give you an int, and emit a warning if the config has something else... https://stem.torproject.org/api/util/conf.html#stem.util.conf.Config.get Same in run_server.py. ============================================================ run_server.py ============================================================ 35 if(dual_mode()): Good idea on this config option. In python you don't use parentheses for conditionals, unless you're doing some grouping. Speaking of which, might I suggest baking pyflakes and pep8 checks into your project? Even if you don't have unit tests yet these can speed development by catching minor issues, and help the codebase have a more uniform style. Stem provides a couple utilities that should make this easy. Here's an example of using them... https://gitweb.torproject.org/nyx.git/tree/run_tests.py Oh, and it'll catch the trailing whitespaces that's slipped in. ;) % grep -R ' $' rwsd/* | grep -v 'Binary file' | wc -l 17 ------------------------------------------------------------ 45 @uses_settings 46 def main(config, dual = True): The 'dual = True' argument is unused. You use the dual_mode() util function instead. ------------------------------------------------------------ 87 except: 88 log.msg("unable to attach listeners, controller off") 89 except: 90 log.msg("unable to start tor controller from rwsd") _conn_listener() is a neat approach. I like it. Generally it's good idea to both only catch the exception types you need, and include the exception in the message so there's some hint for troubleshooting. The second, for instance, is in effect just calling stem.connection.connect(), which only raises ValueErrors (for invalid arguments)... https://stem.torproject.org/api/connection.html#stem.connection.connect Seeing how you use it here you probably want Controller.from_port() instead. As we discussed earlier connect() prints errors to stdout and returns None if it can't connect. However, you're not checking if it returns None so the second try/catch will hit an AttributeError. I suspect there *might* be a bug around double attaching listeners when tor is connected then reconnected, but not sure. ============================================================ util/__init__.py ============================================================ 49 def msg(message, config, **attr): Unused, but feel free to leave it alone if you plan on using it later. ============================================================ server/handlers/main.py ============================================================ Your run_client.py defines a MainHandler but then it seems you have an unused copy of it here too. Since run_server.py uses it too maybe drop it from run_client.py and use this instead? ============================================================ server/handlers/status.py ============================================================ 14 def _handle_status_event(controller, state, timestamp): 15 if state == State.CLOSED: 16 output = {'status': 'off'} 17 else: 18 output = {'status': 'on'} 19 20 send_data(WebSocketType.STATUS, output) Certainly fine, but can condense this if you'd like. def _handle_status_event(controller, state, timestamp): send_data(WebSocketType.STATUS, {'status': 'off' if state == State.CLOSED else 'on'}) ============================================================ server/handlers/graph.py ============================================================ 24 if read_total and write_total: 25 output.update({'read_total': read_total}) 26 output.update({'write_total': write_total}) No need to call update() for single values. This is the same as... if read_total and write_total: output.update['read_total'] = read_total output.update['write_total'] = write_total Same for more calls below. ============================================================ server/handlers/base.py ============================================================ 33 def init_websockets(): 34 global WEBSOCKETS 35 WEBSOCKETS = {} 36 for ws_type in WebSocketType: 37 WEBSOCKETS.update({ws_type: []}) Could also be... def init_websockets(): global WEBSOCKETS WEBSOCKETS = dict([(ws_type, []) for ws_type in WebSocketType]) ------------------------------------------------------------ 40 def get_websockets(ws_type = None): 41 global WEBSOCKETS 42 if ws_type: 43 if WEBSOCKETS[ws_type]: 44 return WEBSOCKETS[ws_type] 45 else: 46 return None 47 else: 48 return WEBSOCKETS The inner conditional made me pause for a second until I realized it's to convert empty lists to None. Are you familiar with dictionary's get() method? It allows you to specify a default, and might allow this to be improved a bit. def get_websockets(ws_type = None): websocket = WEBSOCKETS.get(ws_type, []) return websocket if websocket else None Also, you only need the 'global' keyword if you're doing assignment. Your init_websockets() is the only function that needs it. ============================================================ client/static/css/* client/static/font/* ============================================================ Perfectly fine, but our readme should say we're bundling a copy of angular, bootstrap, and awesome. Also, please note their licenses. I assume bundling is the usual approach for this? ============================================================ client/static/img/body-bg.png ============================================================ Is this just a solid color? If so, any reason it's an image rather than a css background color property? ============================================================ client/static/js/* ============================================================ Please separate our custom javascript from bundled modules. This way it's clear what is ours verses a copy. ============================================================ client/static/js/bandwidthGraph.controller.js ============================================================ 9 function bandwidthGraph($scope, bandwidthWebsocket) { 10 activate(); 11 $scope.readData.data = bandwidthWebsocket.read_data; 12 $scope.writtenData.data = bandwidthWebsocket.written_data; Ahh, so we're only using read_data and written_data. Our bandwidth handler is doing a bit of extra work each second to fetch additional data from tor. Fine for now, but we should later drop those GETINFO calls if they remain unused. Is the activate() getting called on every bandwidth event? On first glance looks like $scope.readData and $scope.writtenData are getting reset each time. ============================================================ client/templates/index.html ============================================================ 10 <link href="http://fonts.googleapis.com/css?family=Open+Sans:400italic,600italic,400,600" rel="stylesheet"> ... 15  16  Fine for now, but cross domain fetches to google (googleapis.com and googlecode.com) are likely a no-go for our final version. Also, it might also be unwise to link to Google Code since it's being phased out... https://code.google.com/p/support/wiki/ReadOnlyTransition Doesn't matter in the short term (being read-only is, of course, fine) but sounds like that may go away eventually. ------------------------------------------------------------ 19 <style> 20 .chart { 21 width: 100%; 22 height: 300px; 23 } 24 </style> Should we start our own application.css in static for things like this? No doubt this'll just be the first of many. ------------------------------------------------------------ 68 <div class="main"> 69 <div class="main-inner"> 70 <div class="container"> 71 <div class="row" ng-controller="bandwidthGraph"> ... Angular supports templates which store html snippets. Essentially partials. Maybe that would help break this up? It would be nice if our base index.html was dead simple, and pulled in modular components which do the actual work.

4 6

Summary of meek's costs, July 2015
by David Fifield 05 Aug '15

05 Aug '15

Here's the summary of meek's CDN fees for July 2015. App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 November 2014 $224.67 + $362.60 + $0.00 = $587.27 December 2014 $326.81 + $417.31 + $0.00 = $744.12 January 2015 $464.37 + $669.02 + $0.00 = $1133.39 February 2015 $650.53 + $604.83 + $0.00 = $1255.36 March 2015 $690.29 + $815.68 + $0.00 = $1505.97 April 2015 $886.43 + $785.37 + $0.00 = $1671.80 May 2015 $871.64 + $896.39 + $0.00 = $1768.03 June 2015 $601.83 + $820.00 + $0.00 = $1421.83 July 2015 $732.01 + $837.08 + $0.00 = $1569.09 -- total by CDN $5497.73 + $6346.26 + $0.00 = $11843.99 grand total The big event last month was an outage of meek-azure that was caused by a mistake during an account migration: https://lists.torproject.org/pipermail/tor-talk/2015-July/038487.html The outage is unfortunately still ongoing, although there's been progress in getting it fixed (I opened a ticket with Microsoft support and they have to migrate things manually). In the meantime, you can use Tor Browser 5.0a4, which uses a newly configured CDN endpoint. The number of users dropped below 3000, perhaps because of the meek-azure outage. https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… If you want to set up your own bridge and CDN instance without rate limiting, I can help you do it. Here are some docs to look at: https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtorunameek-server… https://trac.torproject.org/projects/tor/wiki/doc/meek#GoogleAppEngine https://trac.torproject.org/projects/tor/wiki/doc/meek#AmazonCloudFront https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure == App Engine a.k.a. meek-google == Instance hours were up sharply, over 40%, I don't know why. Here is how the Google costs broke down: 2934 GB $352.11 7598 instance hours $379.90 Compared to the previous month: 2807 GB $336.87 5299 instance hours $264.96 https://globe.torproject.org/#/bridge/88F745840F47CE0C6A4FE61D827950B06F9E4… == Amazon a.k.a. meek-amazon == Number of requests was up 8% while bandwidth was down 11%. Asia Pacific (Singapore) 155M requests $187.04 1034 GB $137.11 Asia Pacific (Sydney) 1M requests $2.46 5 GB $0.66 Asia Pacific (Tokyo) 28M requests $34.08 157 GB $20.10 EU (Ireland) 198M requests $238.14 1124 GB $86.91 South America (Sao Paulo) 7M requests $16.02 50 GB $11.94 US East (Northern Virginia) 71M requests $71.71 395 GB $30.90 -- total 463M requests $549.45 2768 GB $287.62 https://globe.torproject.org/#/bridge/3FD131B74D9A96190B1EE5D31E91757FADA1A… == Azure a.k.a. meek-azure == The meek-azure outage started on July 20. You can see it clearly in the attached graph, where bandwidth dropped almost to zero. If you are affected by this outage, you should try Tor Browser 5.0a4, which uses a working CDN endpoint for meek-azure. You can also manually change the configuration in other versions of Tor Browser: https://lists.torproject.org/pipermail/tor-talk/2015-July/038496.html https://trac.torproject.org/projects/tor/ticket/16634 https://onionoo.torproject.org/bandwidth?fingerprint=AA033EEB61601B2B7312D8… Estimated bandwidth use this month: 2015-07 1974 GB Compared to last month: 2015-06 3038 GB https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8… Earlier reports in this series: https://lists.torproject.org/pipermail/tor-dev/2014-August/007429.html https://lists.torproject.org/pipermail/tor-dev/2014-October/007576.html https://lists.torproject.org/pipermail/tor-dev/2014-November/007716.html https://lists.torproject.org/pipermail/tor-dev/2014-December/007916.html https://lists.torproject.org/pipermail/tor-dev/2015-January/008082.html https://lists.torproject.org/pipermail/tor-dev/2015-February/008235.html https://lists.torproject.org/pipermail/tor-dev/2015-March/008427.html https://lists.torproject.org/pipermail/tor-dev/2015-April/008596.html https://lists.torproject.org/pipermail/tor-dev/2015-May/008767.html https://lists.torproject.org/pipermail/tor-dev/2015-June/008932.html https://lists.torproject.org/pipermail/tor-dev/2015-July/009030.html

1 0

Is anyone using tor-fw-helper? (Was Re: BOINC-based Tor wrapper)
by Nick Mathewson 05 Aug '15

05 Aug '15

Yawning's mail below reminds me: I am considering removing the C implementation of tor-fw-helper from the tor distribution, and recommending Yawning's pure-Go implementation instead. But before I do this, I'd like to get some sense of whether folks are shipping tor-fw-helper today, or using it in practice. On Jul 21, 2015 11:26 AM, "Yawning Angel" <yawning(a)schwanenlied.me> wrote: > > On Wed, 22 Jul 2015 01:06:41 +1000 > teor <teor2345(a)gmail.com> wrote: > > > > > > On 20 Jul 2015, at 11:11 , Serg <std.serg(a)gmail.com> wrote: > > > > > >> How do you plan to map ports on NAT devices? > > > > > > If it can't be done automatically using UPnP, This must be done > > > manually. No alternative cases. > > > > Our experience is that most routers' UPnP / NAT-PMP implementations > > don't work well with (our) automated tools. So this would have to be > > done manually, significantly reducing the pool of available > > volunteers. > > Just chiming in here. This may well work for a good number of users, > but the support overhead for when it fails is utterly gigantic because > certain brands of consumer routers have extremely poor UPnP/NAT-PMP > implementations. > > The usual symptom of a poor implementation is "the router crashes" but > certain other behaviors have been documented in the past by people > trying to use UPnP in ways that are spec compliant such as "the router > crashes and requires a NVRAM reset", "random port mappings get > obliterated", "the UPnP/NAT-PMP stack on the router crashes" etc. I wonder how commercial software handles these cruddy routers. Do they restrict themselves to a tiny part of the spec? Do they probe for problematic firmware, and maintain a list of unreliable versions? [I am very glad it is not our job to maintain such a list.] -- Nick

8 20

curve25519_donna vs. crypto_scalarmult_curve25519?
by Steve Snyder 05 Aug '15

05 Aug '15

Given a contemporary release of Tor with a contemporary version of OpenSSL, under what circumstances is the intrinsic curve25519_donna() preferred over the libsodium/NaCl crypto_scalarmult_curve25519(), or vice versa? Does it come down to 32-bit vs. 64-bit? Or CPU instruction sets detected at build time? Or has libsodium/NaCl been deprecated altogether and just not removed from the configure script? I'm trying to determine if installation of libsodium in a Tor build environment will yield a "better" Tor binary. Thanks.

2 1

5th status report for OnioNS
by Jesse V 04 Aug '15

04 Aug '15

Hi everyone, As I stated in my last status report, I promised to work on server-to-server communication in preparation for a beta test. Quite a bit of work was done in this area, with the result that the server-server protocols are now working as intended and fairly reliably. The changes include: * Ability to bind to a specific IPv4 address. This is useful not only in servers with multiple interfaces, but allows two instances of OnioNS-server to run simultaniously on localhost, which is great for testing and debugging. * Improved server-side logging and diagnostic information. Each network session has it's own identification number, which makes it easy to keep track of events and conversations. * Rewrote the networking code responsible for retransmitting information such as new Records. The servers now correctly sends Records to subscribers. * A Mirror server now reestablishes the network connection with a Quorum server if the Quorum server drops from the network. * Many bug fixes, addressing numerous issues with crashes, networking issues, and serialization faults. With these changes, the OnioNS project is in a pretty good state. Here's an overview of the system's order of operations: 1) A single Quorum server starts up and listens on a specific IP and port. It's a TCP server and waits for JSON-encoded messages. 2) A Mirror server starts up, connects with and subscribes to the Quorum server. 3) A hidden service operator generates a claim on a domain name (say "example.tor") and optionally some subdomains. This claim is represented in the Record data structure. 4) The operator sends the Record over a Tor circuit to the Quorum server, who inspects it, caches it, and sends it to all subscribers, which is the single Mirror node. 5) The Mirror inspects the Record, caches it, and sends it to all subscribers, but here it doesn't have any. 6) A client starts up the Tor Browser with the OnioNS software installed. This means that the starting of the Tor Browser also triggers the launching of the OnioNS software: a binary and a Python script. 7) The user types in "example.tor". Their Python script detects the pseudo-TLD and performs a query lookup to the Mirror node, who replies with the Record. 8) The OnioNS-client software inspects the Record, extracts the hidden service address, and passes the address back to the Stem script. 9) The Stem script rewrites the original stream request from step 7 to this HS address and tells Tor to attach the stream to some circuit. 10) Tor attaches the stream with the effect that the hidden service loads in the Tor Browser. All of these pieces are now in place and generally work as intended without requiring any user intervention. The step of separating the responsibility into two different servers is now behind me, which when coupled with the working subscriber-based server-server communication, gives me many options to move forward towards a distributed system. I have a couple of annoyance-level bugs to fix but a prototype is very near. I will be shortly resume building packages and will currently be supporting Ubuntu, Mint, Debian, and Fedora on i386, amd64, and armhf. As a final note, a quick thanks to George for the well-written commit-reveal-consensus proposal. As he stated in his introduction, I certainly need that in order to integrate OnioNS with the Tor network. Jesse V.

1 0

CompCert C compiler
by Mansour Moufid 04 Aug '15

04 Aug '15

Hi everyone, This is just to let you know that Tor compiles without modification using the CompCert C compiler. This week I'll run it in the "C interpreter" to see what happens. http://compcert.inria.fr/man/manual004.html#cinterp Mansour

1 0

[Measurement Team] Next IRC meeting happens on Wednesday, Aug 5, 14:00 UTC in #tor-project
by Karsten Loesing 03 Aug '15

03 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team on Wednesday, August 5, 2015, 14:00 UTC in #tor-project https://www.timeanddate.com/worldclock/fixedtime.html?iso=20150805T14 Last week's meeting only had two participants, and while I had a really good time chatting with Philipp, I think it's safe to suggest the same agenda for this week: - Introductions, problems, products, priorities: any feedback, remarks, comments on what we did in the previous four weeks - 1-1-1 task exchange: you get 1 minute to describe a task that would take somebody else roughly 1 hour and that they will do for you within 1 week (review a document, write some analysis code, fix a small bug, etc.; better come prepared to get the most out of this; give 1, take 1) - Misc/discussion: whatever comes up during the meeting If you think this can be fun, please join us at the meeting! Talk to you on Wednesday! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVv8ZVAAoJEJD5dJfVqbCrJuAH/2wSlJn8v3m7SDy4kzBEyA5Y lSItMFAn8Q+p6zd4aCkeBxMFUaEJZ8qpNPuq7m8Nv+L5lDAMISpjn8D9z7cH4qLb HGM+Y6oHZwX+e/o/Xj6iVEG8MvJVXB2l1QhXynohGDpJoMX8Lj/lff1bDdt19n2f 5cAULUH5xtFKf4l9XZ7gRgRW+iIZZ3NdI08A/8uZT6PU/rvoKHN9j/52gUIAM+mB j0Vr6xIW38fC3O3N8CnlVmoXglTiuLXJ0HC56VPbGlKRU/Al1pM2M1vk+6ddsi7q 9zcB3qqd485Oj8GFeOUS238GEBawrQk61prKh1xS58Vdji/XfPB/i7vuDgs0Pms= =L7j1 -----END PGP SIGNATURE-----

1 0

Relay Web Dashboard - Summer of Privacy
by Cristobal 31 Jul '15

31 Jul '15

Hello everyone, This summer I'll be working on a Relay Web Dashboard as part of Tor's Summer of Privacy [1]. The goal of this project is to develop a web application to monitor Tor relays. A good part of the back-end code will be based on what nyx [2] currently does (using stem [3]). You can take a look at my SOP proposal here [4] to get a better idea of what I'm planning to do. TL;DR : use Javascript to fetch information from a 'Relay API'. This 'Relay API' will use stem to collect data from the relay, keeping in mind that the idea is to follow a 'read-only' approach, in other words: just monitoring (at least for now). On the first half of SOP I'll be working on making this app based on nyx features. On the second half I'm planning to add new features if necessary, and for that I'd be very interested in hearing your feedback and ideas, specially if you are a relay operator and you think there are features that will help you with the task of running a relay. I hope this project would be of help to relay operators community by giving them a secure, useful and easy-to-use tool for their relays. I'll be informing you about my progress with bi-weekly reports to this list. I'm also on IRC by the nickname @clv Looking forward to hear from you! Best regards, Cristobal GPG: 2ACA 8DD4 444E 358F B72E 8C3C 7196 690D 9E03 CDFD [1] https://trac.torproject.org/projects/tor/wiki/doc/gsoc [2] https://gitweb.torproject.org/nyx.git [3] https://stem.torproject.org/ [4] https://leivaburto.github.io/sop-proposal

4 4

The Shadow Simulator will soon use cooperative threading to better support plug-ins
by Rob Jansen 31 Jul '15

31 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Shadow! Hello Tor! For the last couple of weeks, I have been overhauling the way Shadow interacts with plug-ins, and I want to make sure you (and others developing/using Shadow plug-ins) are aware of the upcoming changes. I am enhancing Shadow to support the following two capabilities: 1. Run plug-ins that make blocking system calls 2. Run plug-ins that create and use pthreads To achieve this, I am using a user-space cooperative threading library called pth: http://www.gnu.org/software/pth/ Pth works by storing and swapping stack states using makecontext and swapcontext (see man pages), so that we can intelligently switch back to Shadow's execution stack when the plug-in makes blocking libc function calls, and switch back to the plug-in stack only when its file descriptors are waiting for I/O or timers have expired. This same technique allows us to support would-be plug-in pthreads as application layer pth threads instead, which will help us avoid expensive kernel context switches. This will be especially useful/efficient when running thousands of nodes simultaneously, which normally would consume thousands of pthreads which are not Shadow aware. I have modified the pth library to be reentrant and thread-safe using caller-supplied states and thread-specific data, which I needed because Shadow itself runs with multiple simulator worker threads. Cool, huh!? So what does this mean? With this fancy new approach, we must still build each plug-in using LLVM/Clang in order to make use of Shadow's cool state-swapping trick, but we may no longer need to do other customization, particularly those historically needed for programs that block or use threads. Also, with these changes, Shadow's "API" has been removed, and Shadow now just calls the "main" function symbol in each plug-in directly, and the plug-in need not know anything about Shadow. I'm excited about these changes, and hope they will improve support for new plug-ins while also reducing maintenance in the long term. So far I have Shadow's built-in traffic generator running correctly with the new approach, and am now working on Tor. None of this code is public yet, but if you are interested in an example of how this would work or want some early access to the code, drop me a message off-list. Cheers! Rob - -- Rob Jansen, Ph.D. Computer Scientist Center for High Assurance Computer Systems U.S. Naval Research Laboratory rob.g.jansen(a)nrl.navy.mil robgjansen.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVu4lYAAoJEO3Z5w0UVGXoASAP/3qjW0551xxnrLwWQcrXhbiN cf7hryzU7vDzKRkdzzNbEive0JFZhDONbruJ5Lcx1BW4/uvFZ1emW0FuZFri1m7b xWW6Pp43cMDGeIaMzmWZ9UAea59wirFk/C47R/jDBkXWnZpz5Arc1DjryPbj2LqN oPcfd9JDyE9zk2Y0sSytYt3IulKA62ZOV7+WbIwhHUTj70OgXFvVLhLMMVgOBEDO rHWxDg/+5mC8WqEg4L7lS8/ivAjr1YboA4PV0uSPzgZ+208iQBbsF3DoCG/8D9kY 83xpX/+3aGdWl7XjrncpA5x7gt392fX/3EL9k8lUYu2PKPaOWmJ0/xWbGoXGJOhA epAWPr95X7DFzpcsS59sq6usDeiltFllzfxgA5TbDsUgVwOa9227ygYtK/MVifi6 gYkpZzC6YEMDR6id0ZOwwqYKTsx1Sxomyz30w5iAp1l+Grb10bhUZlfqsNx9PkuI HdBMfvNziApSOQBge36QwskGFlJobfGdpL5w0yep1MSmBJCLVSCopCllLVcbDzQX ipbjmHjJXHNaIL7DHm073VJe2XAjcoMPHHs/nhq0vTgrMFGMDsNvMJ7+66xz3iwZ V3WUjEP0fPjgGZ8MTWj2HjGOQyENa5yAmAiBJUosg1fzgeinushWfE+Zm4m0sVEJ BJttAL/8SnI4DpbIqq6e =c1wf -----END PGP SIGNATURE-----

1 0

Unreachable hidden service by some clients
by Liste 31 Jul '15

31 Jul '15

I was open some hidden service to do an experiment: All work fine. After a day all hidden service on a single server are unreachable from another server used as client. After some hous all hidden server become reachable. Some time when the hidden services are unreachable, they return to work when tor restart. What's going on? We are under attack?

2 1

onionoo.tpo stuck at 2015-07-29 07:00
by nusenu 30 Jul '15

30 Jul '15

2 1

Roster introduction
by Virgil Griffith 29 Jul '15

29 Jul '15

Hello everyone. This is my first report on the Roster project and I wanted to give you all an introduction what it is and where it's going. I'm interested in seeing Tor grow. Current work towards this is tor2web and now Roster. Roster is the rebranded continuation of the "Torati" proposal which I first mentioned here: https://lists.torproject.org/pipermail/tor-dev/2014-June/006975.html In short the gist is to: * Socially incentivize operators to run relays. * Make the operator experience more compelling. * Gamify operating a Tor relay. The main difference between Roster and Globe/Atlas is that Roster provides information at the level of *operators*, not individual relays. In Roster information is aggregated and metrics are summed across all relays of a family. The idea is that when you run a relay, you generate nerd points and badges. And then when people Google your name/alias, they will see how many nerd points+badges you have and they will be in awe of your epic geek-street-cred. In addition to improving operator experience, there are proposals for encouraging operators to do things Tor management like them to do such as upgrading to the latest Tor version and/or probably setting up their Families. E.g., a badge for using the latest/recommended Tor software. That's the gist of it. I will be spending most of my time on tor-relays@ and talking with operators there. So if you want to follow day-to-day stuff subscribe there. Main things accomplished so far: * Setup the basic website at: http://www.tor-roster.org/ * I have an assistant whom I've taken under my wing. His name is Sean Saito <saitosean(a)ymail.com>. He's a Computer Science student at Yale-NUS here in Singapore. He wishes to become more involved in The Tor Project and this is his first Tor-related experience. * We also have discussed with the tor-relays@ list candidate badges. Are interested in additional badge proposals. --- https://lists.torproject.org/pipermail/tor-relays/2015-June/007228.html That's it so far. -Virgil

3 5

[Measurement Team] Next IRC meeting happens tomorrow, Jul 29, 14:00 UTC in #tor-project
by Karsten Loesing 28 Jul '15

28 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team tomorrow on Wednesday, July 29, 2015, 14:00 UTC in #tor-project http://www.timeanddate.com/worldclock/fixedtime.html?iso=20150729T14 Two weeks ago we created a list of existing measurement-related products and last week we brainstormed what tools we would want to exist if none of these existed yet. Logs of all past meetings are available here: http://meetbot.debian.net/tor-project/2015/tor-project.2015-07-08-14.06.log… http://meetbot.debian.net/tor-project/2015/tor-project.2015-07-15-14.00.log… http://meetbot.debian.net/tor-project/2015/tor-project.2015-07-22-14.00.log… While I found the last two meetings extremely productive, I want to suggest a slightly looser-defined agenda this week: - Introductions, problems, products, priorities: any feedback, remarks, comments on what we did in the previous three weeks (for example, I'm planning to present a roadmap document based on the two pads we worked on in the past two weeks) - 1-1-1 task exchange: you get 1 minute to describe a task that would take somebody else roughly 1 hour and that they will do for you within 1 week (review a document, write some analysis code, fix a small bug, etc.; better come prepared to get the most out of this; give 1, take 1) - Misc/discussion: whatever comes up during the meeting If you think this can be fun, please join us at the meeting! Talk to you tomorrow! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVt5O9AAoJEJD5dJfVqbCrqVUH/jKEjckSOEY+1hOpz7cyPXFr E6Z7L64gDSUlCJ68YeADA5C8Y1kG6Pzkhb+Z7zGigJp7ZdEWI8xLbhUtXcgE6cQY 9pyqYd+IK/zNrSdUTgHEfpfHF0sAyHCgMcUMuNQ0Vt82IFxyWef30MJm/w6jvis8 v5iFRLbDut1YZ+xXmm/Y6YyyXxCuSPE/rKxQUbIXFAqf3Nz4207tC4VF9h53vKeF aZr5fnZC6j3cdt0QbPi3vBYMsw9oU0Z9HDpleEh639uEM07wq7wamBvvOKJioNtT 0IcwlDoCDx5ldyZsCNE9aOdVzwkzDjYBRytgNJUHzTyh+yjmFzlIR3a5H8KTVrI= =FCO3 -----END PGP SIGNATURE-----

1 0

Tor Browser/Tor Applications Team Meeting temporarily moved to Tuesday 18:00 UTC
by Mike Perry 26 Jul '15

26 Jul '15

The Tor Browser team meeting will be temporarily moved this week to Tuesday (July 28th) at 18:00 UTC, due to scheduling conflicts for Georg and me. Because of an additional conflict with the Tor Patch Workshop, we will likely be using #tor-project on irc.oftc.net instead of #tor-dev, as well. We're also expanding the meeting in general to open it up to anyone who is working on user-facing Tor client applications (such as Tor Birdy, Tor Messenger, Ricochet, GetTor, Satori, etc). If you work on something user-facing and want to discuss UI/UX, censorship circumvention configuration, or any related topics, please join us! The meeting format is described here: https://lists.torproject.org/pipermail/tbb-dev/2014-February/000000.html -- Mike Perry

1 0

Proposal 249: Allow CREATE cells with >505 bytes of handshake data
by Nick Mathewson 23 Jul '15

23 Jul '15

Filename: 249-large-create-cells.txt Title: Allow CREATE cells with >505 bytes of handshake data Authors: Nick Mathewson Created: 23 July 15 Status: Draft 1. Summary There have been multiple proposals over the last year or so for adding post-quantum cryptography to Tor's circuit extension handshakes. (See for example https://eprint.iacr.org/2015/008 or https://eprint.iacr.org/2015/287 .) These proposals share the property that the request and reply for a handshake message do not fit in a single RELAY cell. In this proposal I describe a new CREATE2V cell for handshakes that don't fit in a 505-byte CREATE2 cell's HDATA section, and a means for fragmenting these CREATE2V cells across multiple EXTEND2 cells. I also discuss replies, migration, and DoS-mitigation strategies. 2. CREATE2V and CREATED2V First, we add two variable-width cell types, CREATE2V and CREATED2V. These cell formats are nearly the same as CREATE2 and CREATED2. (Here specified using Trunnel.) struct create2v_cell_body { /* Handshake type */ u16 htype; /* Length of handshake data */ u16 hlen; /* Handshake data */ u8 hdata[hlen]; /* Padding data to be ignored */ u8 ignored[]; }; struct created2v_cell_body { /* Handshake replay length */ u16 hlen; /* Handshake reply data */ u8 hdata[hlen]; /* Padding data to be ignored */ u8 ignored[]; }; The 'ignored' fields, which extend to the end of the variable-length cells, are reserved. Initiators MAY set them to any length, but MUST fill them with zero-valued bytes. Responders MUST ignore them, regardless of what they contain. When a CREATE2V cell is generated in response to a set of EXTEND2 cells, these fields are set by the relay that receives the EXTEND2 cells. (The purpose of the 'ignored' fields here is future-proofing and padding.) 3. Fragmented EXTEND2 cells Without changing the current EXTEND2 cell format, we change its semantics: If the 'HLEN' field in an EXTEND2 cell describes a handshake data section that would be too long to fit in the EXTEND2 cell's payload, the handshake data of the EXTEND2 cell is to be continued in one or more subsequent EXTEND2 cells. These subsequent cells MUST have zero link specifiers, handshake type 0xFFFF, and handshake data length field set to zero. Similarly, if the 'HLEN' field in an EXTENDED2 cell would be too long to fit into the EXTENDED2 cell's payload, the handshake reply data of the EXTENDED2 cell is to be continued in one or more subsequent EXTENDED2 cells. These subsequent cells must have the handshake data length field set to zero. These cells must be sent on the circuit with no intervening cells. If any intervening cells are received, the receiver SHOULD destroy the circuit. 4. Example So for example, if we are a client, and we need to send a 2000-byte handshake to extend a circuit from relay X to relay Y, we might send cells as follows: EXTEND2 { nspec = 2; { node ID for Y, taking 22 bytes. } { node address for Y, taking 8 bytes } htype = {whatever the handshake type is.} hlen = 2000 hdata = { the first 462 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the next 492 bytes of the handshake } } EXTEND2 { nspec = 0; htype = 0xffff; hlen = 0; hdata = { the final 62 bytes of the handshake } } Upon receiving this last cell, the relay X would send a create2v cell to Y, containing the entire handshake. 5. Migration We can and should implement the EXTEND2 fragmentation feature before we implement anything that uses it. If we can get it widely deployed before it's needed, we can use the new handshake types whenever both of the involved relays support this proposal. Clients MUST NOT sent fragmented EXTEND2 cells to relays that don't support them, since this would cause them to close the circuit. Relays MAY send CREATE2V and CREATED2V cells to relays that don't support them, since unrecognized cell types are ignored. 6. Resource management issues This feature requires relays and clients to buffer EXTEND2 cell bodies for incoming cells until the entire CREATE2V/CREATED2V body has arrived. To avoid memory-related denial-of-service attacks, the buffers allocated for this data need to be counted against the total data usage of the circuit. Appendix A. A rejected idea for migration In section 5 above, I gave up on the idea of allowing relay A to extend to relay B with a large CREATE cell when relay A does not support this proposal. There are other ways to do this, but they are impressively kludgey. For example, we could have a fake CREATE cell for new handshake types that always elicits a "yes, keep going!" CREATED cell. Then the client could send the rest of the handshake and receive the rest of the CREATED cell as RELAY cells inside the circuit. This design would add an extra round-trip to circuit extension whenever it was used, however, and would violate a number of Tor's assumptions about circuits (e.g., by having half-created circuits, where authentication hasn't actually been performed). So I'm guessing we shouldn't do that.

1 0

[Patch] or/config.c for MSVC
by Gisle Vanem 23 Jul '15

23 Jul '15

This gcc-centric macro in or/config.c doesn't work well in MSVC v16/18: #define COMPLAIN(args...) \ STMT_BEGIN log_warn(LD_CONFIG, args); STMT_END I suggest it should be patched like this: --- a/config.c 2015-05-06 22:22:09 +0000 +++ b/config.c 2015-05-06 23:15:57 +0000 @@ -2571,8 +2571,8 @@ #define REJECT(arg) \ STMT_BEGIN *msg = tor_strdup(arg); return -1; STMT_END -#define COMPLAIN(args...) \ - STMT_BEGIN log_warn(LD_CONFIG, args); STMT_END +#define COMPLAIN(args, ...) \ + STMT_BEGIN log_warn(LD_CONFIG, args, ## __VA_ARGS__); STMT_END /** Log a warning message iff <b>filepath</b> is not absolute. * Warning message must contain option name <b>option</b> and ------- All recent compilers supports '__VA_ARGS__'? -- --gv

3 5

☎ Second Computer Graphics, Multimedia and Image Processing - 2015 Malaysia
by Conference Alert 23 Jul '15

23 Jul '15

The Second International Conference on Computer Graphics, Multimedia and Image Processing (CGMIP2015) Universitas Siswa Bangsa Internasional Jakarta, Indonesia October 29-31, 2015 http://sdiwc.net/conferences/cgmip2015/ cgmip15(a)sdiwc.net ---------------------------------------------- CALL FOR PAPERS, WORKSHOP and SPECIAL SESSIONS ---------------------------------------------- Research topics not limited to: - 3D imaging - Case studies and emerging technologies - Color and texture - Computational geometry - Computer art and entertainment (including games) - Case studies - Classification and clustering techniques - Compression methods - Computer animation - Curves and meshes - e-Learning applications and computer graphics - Emerging technologies - Emerging display technologies - Face recognition, face detection, and gesture recognition - Fractal geometry and applications - Graphics algorithms and applications - Graph theory in image processing and vision - Human-computer interfaces - Image compression, coding, and encryption - Image feature extraction - Image geometry and multi-view geometry - Immersive virtual reality - Interactive digital media - Simulation and virtual reality - Software tools for virtual reality - Surface modeling - Virtual environments - Virtual laboratories - Virtual reality, visualization, and education - Visualization All registered papers will be included in SDIWC Digital Library, and in the proceedings of the conference. All submitted papers will be reviewed by a minimum of two reviewers. The published proceedings will be indexed in ResearchBib, in addition, they will be reviewed for POSSIBLE inclusion within the INSPEC, EI, DBLP, Microsoft Academic Research, ResearchGate, and Google Scholar Databases. Important Dates =============== Submission Deadline: September 29, 2015 Notification of Acceptance: 2-4 weeks from the submission date Camera Ready Submission: October 19, 2015 Registration Deadline: October 19, 2015 Conference Dates: October 29-31, 2015

1 0