- tor-dev - lists.torproject.org

Building tbb-4.0a1-build2 fails
by tor-admin 06 Aug '14

06 Aug '14

Hi, when I try to build ttb-4 I run into an error on compiling openssl. I was able to compile previous versions of tbb. Any idea what I am missing for ttb-4? Thanks & regards, torland --- Building utils-linux for lucid i386 --- Stopping target if it is up Making a new image copy Formatting 'target-lucid-i386.qcow2', fmt=qcow2 size=11811160064 backing_file='base-lucid-i386.qcow2' encryption=off cluster_size=65536 Starting target Checking if target is up Preparing build environment Updating apt-get repository (log in var/install.log) Installing additional packages (log in var/install.log) Grabbing package manifest Creating build script (var/build-script) Running build script (log in var/build.log) ./bin/gbuild:21:in `system!': failed to run on-target setarch i386 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError) from ./bin/gbuild:122:in `build_one_configuration' from ./bin/gbuild:224 from ./bin/gbuild:219:in `each' from ./bin/gbuild:219 from ./bin/gbuild:217:in `each' from ./bin/gbuild:217 make: *** [build-alpha] Error 1 from ../../gitian-builder/var/build.log gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -DTERMIO -O3 -fomit- frame-pointer -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 - DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM - DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM - DGHASH_ASM -c -o x86cpuid.o x86cpuid.s x86cpuid.s: Assembler messages: x86cpuid.s:8: Error: invalid instruction suffix for `push' x86cpuid.s:9: Error: invalid instruction suffix for `push' x86cpuid.s:10: Error: invalid instruction suffix for `push' x86cpuid.s:11: Error: invalid instruction suffix for `push' x86cpuid.s:13: Error: invalid instruction suffix for `pushf' x86cpuid.s:14: Error: invalid instruction suffix for `pop' x86cpuid.s:17: Error: invalid instruction suffix for `push' x86cpuid.s:18: Error: invalid instruction suffix for `popf' x86cpuid.s:19: Error: invalid instruction suffix for `pushf' x86cpuid.s:20: Error: invalid instruction suffix for `pop' x86cpuid.s:130: Error: invalid instruction suffix for `pop' x86cpuid.s:131: Error: invalid instruction suffix for `pop' x86cpuid.s:132: Error: invalid instruction suffix for `pop' x86cpuid.s:133: Error: invalid instruction suffix for `pop' x86cpuid.s:145: Error: invalid instruction suffix for `pop' x86cpuid.s:147: Error: relocated field and relocation type differ in signedness x86cpuid.s:161: Error: invalid instruction suffix for `pop' x86cpuid.s:163: Error: relocated field and relocation type differ in signedness x86cpuid.s:169: Error: invalid instruction suffix for `pushf' x86cpuid.s:170: Error: invalid instruction suffix for `pop' x86cpuid.s:174: Error: invalid instruction suffix for `push' x86cpuid.s:175: Error: invalid instruction suffix for `push' x86cpuid.s:192: Error: invalid instruction suffix for `pushf' x86cpuid.s:193: Error: invalid instruction suffix for `pop' x86cpuid.s:223: Error: invalid instruction suffix for `pop' x86cpuid.s:225: Error: relocated field and relocation type differ in signedness x86cpuid.s:253: Error: invalid instruction suffix for `push' x86cpuid.s:262: Error: invalid instruction suffix for `pop' x86cpuid.s:270: Error: invalid instruction suffix for `push' x86cpuid.s:289: Error: invalid instruction suffix for `pop'

2 2

3.6.3-meek-2 bundles that can use the Amazon CloudFront CDN
by David Fifield 05 Aug '14

05 Aug '14

I made some test meek bundles that are capable of using the Amazon CloudFront CDN as a backend, in addition to Google App Engine that was supported before. https://people.torproject.org/~dcf/pt-bundle/3.6.3-meek-2/ https://trac.torproject.org/projects/tor/wiki/doc/meek#AmazonCloudFront To test it, go to the pluggable transport screen, and choose "meek-amazon" from the selection box. meek is a pluggable transports that hides the true destination of your communication (a Tor bridge) by hiding it behind a different domain name. When you select meek-amazon from the list, your traffic will appear to a censor to be going to the domain a0.awsstatic.com, but will actually be going to a Tor bridge on cloudfront.net. I signed up for the Amazon Web Services free tier, which limits use to 50 GB and 2 million HTTP requests per month. Please feel free to use it, but don't depend on it not going away. If it becomes too expensive, we'll have to shut it down until we can find a way to fund operation long-term. (The same goes for App Engine, BTW.) David Fifield

2 3

Using a Tap for Tor's Homebrew recipe to increase confidence in source code authenticity
by Mark Rushakoff 05 Aug '14

05 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I noticed that in the instructions for using Homebrew to install Tor on OSX, the instructions say: > As with any application, you should make sure it came unmodified from the orginal source. Unfortunately, Homebrew does not come with integrated verification for downloads, and anyone could submit a modified Tor! If you use a [Brew Tap](https://github.com/Homebrew/homebrew/wiki/brew-tap), you can have a separate repository (which must be on Github) to track the Tor formula. I believe that if the Tor Project owns that repository, there should be higher confidence that a user installing Tor with Homebrew is installing the intended source code, so long as the user runs `brew install TheTorProject/tor/tor` (instead of just `brew install tor`, which will use the formula in the main Homebrew repo). If this sounds like something the devs desire, I have a tap repository ready to go at https://github.com/mark-rushakoff/homebrew-tor. It includes the tor.rb formula from Homebrew, including its full history. If you fork it to the Tor project (or perhaps Github offers a way for me to transfer ownership), then only someone affiliated with Tor will be able to approve changes to where Homebrew retrieves source code to build Tor. The only extra work in adopting this solution would be finding a way to "deprecate" or redirect the main recipe under Homebrew. I'm not familiar enough with Homebrew to provide direction on that topic, unfortunately. Mark Rushakoff -----BEGIN PGP SIGNATURE----- Version: OpenPGP.js v0.6.1-dev Comment: http://openpgpjs.org wsBcBAEBCAAQBQJT4G8NCRDqKXFAudXBCAAAcKYIAJwa99tJQOHxvzn1DyDW DZD+ktBrAg0pZ4FEE58+n2KiH1hzeHGuhLh4mLlsD30CGlDqtjmYKiU7VR/P g9jsQTawqmACI5KQkMkOMkdBKsjKfNwCaLxA7mdSoCHsRcmSKhQH++rg1Bli JiQrHgi9DihNrUku2/Km7leiurBrKED1KK2KAJ9mKnVMF2iRjcV//VQ9Nbtp WJp92mydyTnBEGYQPrt6M57WZjYvrkvYV1/eHYZpulrGcPAcXzDYnHgRhRPL 9bolbQhwyPWU6gvEdLC/+NAlCpN1Lfd/RFCyhksgVr6RT8GJFSdpjg1UVkw4 U/63nEVJR8cF0boBtUWQReQ= =baFT -----END PGP SIGNATURE-----

1 0

carml: tasty treats from your Tor
by meejah 05 Aug '14

05 Aug '14

I've got a first super-alpha release of this thing that's been sitting around for a while. Turns out "sanitize a bit" turns into "refactor some things" and so forth... Anyway, carml does various command-line things with Tor and I thought it might be useful to others (plays nicely with grep, pipes, etc). I would really love feedback on whether the "downloadbundle" command is doing the right thing with certificate-checks. https://github.com/meejah/carml https://carml.readthedocs.org/en/latest/ You can "pip install carml" to try it out. Recommend doing this in a virtualenv: virtualenv trycarml ./trycarml/bin/pip install carml ./trycarml/bin/carml help To check signatures first, instead download the WHL file and associated signature from PyPI, gpg --verify it and then replace "install carml" with "install path/to/.whl" above. Some other things to try: carml downloadbundle --extract --system-keyring echo "hello darkweb" | carml pastebin wait for a new consensus to be published, dump it and exit: carml events --once NEWCONSENSUS Currently, the defaults work with a system Tor (i.e. localhost port 9051). Probably I'll change this to be TBB defaults. To connect to a Tor Browser Bundle instance, do this: carml --connect tcp:localhost:9151 monitor It is written using Twisted and txtorcon. Thanks, meejah

3 4

GSoC: making tor daemon using more cores
by Белоус Михаил 04 Aug '14

04 Aug '14

Hi all, This my first report since my return, from millitary camp. Last week I have been watching tor daemon code and make little refactor. I think I found place where I can use my threadpool to make daemon multicore. I'm going to implement it as soon as I disquise my idea with Nick. Cheers, Mikhail

1 0

Needed improvements to the PT website
by George Kadianakis 03 Aug '14

03 Aug '14

Hello list, in my monthly status report [0] I mentioned that some PT-related parts of the website are in need of improvement. As a response, a few people sent me a private email asking me what kind of improvements I was thinking about. Instead of replying individually, I decided to send a mail to this list. Here are some of the needed improvements: - In the past, our main PT page was the obfsproxy page: https://www.torproject.org/projects/obfsproxy.html.en However, now that the scene is growing and the obfsproxy fad is shrinking, the main PT page should actually be: https://www.torproject.org/docs/pluggable-transports.html.en . Users, bridge sysadmins and researchers who want to learn about PTs will probably encounter that page. I suggest we optimize that page towards users and bridge syadmins and let researchers get their information from the "unofficial" wiki page: https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports - To make the PT page a bit more end-user-friendly, we could remove non-Tor-deployed PTs from the list, like Stegotorus, Skypemorph and Dust. These are better suited for the wiki, I think. Things that users see in the PT page should be ready to use. Also, it would be great if there was a "How to use PTs" document linked by the "Download PT bundles" section. Unfortunately, I don't think there is such a document atm. Sheried wanted to write one (with screenshots etc.) but I'm not sure if it was ever made. - To make the PT page a bit more bridge-sysadmin friendly, we could link to a "How to become an obfsbridge" document. Currently, the only such document is linked from the obfsproxy page: https://www.torproject.org/projects/obfsproxy.html.en#instructions and it only suggests installing obfsproxy. Nowadays, such a guide should also be guiding readers to install fteproxy. And Real Soon Now it will need to be guiding readers to install Yawning's obfs4proxy or gobfsproxy. Also, weasel read the guide and was not very happy. For example, the guide _suggests_ using pip as root, this is probably not sound advice and some workaround should be found. - Another document that is needed for bridge sysadmins is a "Best practices for running obfsbridges" document. Such a document could have the following advices: - Which PTs should be installed. - How to install ExtORPort and geoip. - How to find geoip stats from your bridge. - How to check whether your bridge and PTs are used. - How to enable logging in your PTs and general debugging tips. - etc. There are probably other improvements that could be suggested, but this is a good start, I think. Also, those tasks don't have any tickets at the moment. Please feel welcome to make tickets if you'd like, or I can do it at a later time :) BTW, I don't know much about UI or product marketing (#11501), so my advices might be totally off :) [0]: https://lists.torproject.org/pipermail/tor-reports/2014-August/000608.html

1 0

GSoC : Rewrite Tor Weather (Status Update 5)
by Sreenatha Bhatlapenumarthi 03 Aug '14

03 Aug '14

Hi all, This report includes my 4th status update as well. Here is a list of things I've been working on regarding the weather rewrite project. - Fixed some django/database issues that were causing errors(seen with Debug=True in settings) during user subscription in the weather webform. - Added a config option to consider the deployment time only in production mode. This was causing an issue previously because not many relays are filtered(considered recent) due to the presence of deploy time in the consideration criteria. - Made use of django's setup_environ method to ensure the standalone backend scripts running as cron jobs can operate with the proper settings. - Updated the daily script to ensure Tshirt emails are not sent to relay operators more than once. For the changes made, check out https://github.com/meejah/tor-weather/pull/10/ Here's what I'll be working on in the coming weeks. - Squash any remaining bugs with the backend scripts. - Get rid of previous mechanism of fetching data like listeners, updaters etc. - Write down test cases for various usage scenarios(e.g., check if emails are being sent to subscribers) within the vagrant environment. Cheers, Sreenatha

1 0

[GSoC] Consensus diffs - Fifth report
by Daniel Martí 03 Aug '14

03 Aug '14

Hello everyone, This is the fifth status report of my Google Summer of Code project, which is to implement consensus diffs for Tor. My mentors - Sebastian and Nick - and myself usually hold meetings on IRC on wednesday at 16h UTC. As described in my last report, I have spent the past couple of weeks integrating my work into the main Tor repository. It builds fine with the rest, all gcc/clang warnings were solved (mostly just C89 declaration errors) and all make check-spaces warnings were also fixed. You can see the result on the repository I created a few weeks ago on github [1]. You want the branch 'consdiff-1', where you will find src/or/consdiff.{h,c} and src/test/test_consdiff.c. I also added some very basic logging, so that the public consdiff_* functions will log what went wrong when returning NULL. I used LD_GENERAL for now, which I assume is wrong - suggestions welcome. I also simplified some bits for easier readability and usage, which can be found in the commit history. But most notably, I improved the docs and comments. The idea is to be able to stumble upon consdiff.c for the first time and be able to understand what it does, how and why in just a few minutes. It's hard to tell whether I did a good job at that - criticism very much appreciated. Most of that happened during the first week, as I was on a quick holiday during the second. Nick gave me some pointers on how to continue with the integration, and that's what I'll be doing in the next few days. The first thing to do is figure out a way to store multiple consensuses on disk, to be used to fetch and create diffs accordingly. There are now just over two weeks left, but I am confident that I can finish all the coding early enough to be able to test the whole thing properly. Regards. [1] https://github.com/mvdan/tor -- Daniel Martí - mvdan(a)mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C

2 2

GSoC Stegotorus status update
by Noah Rahman 02 Aug '14

02 Aug '14

Following closely on the heels of my last email ( https://lists.torproject.org/pipermail/tor-dev/2014-July/007248.html) I updated the pluggable transports meeting on Friday to the following effect: - Have identified somewhat of a performance regression in the PDF module and am continuing to see if I can find the source. - Finishing moving the Javascript over and am writing slimmer unit tests for it.

1 0

Hidden service don't work or work???
by Liste 02 Aug '14

02 Aug '14

After tor update the hidden service doesn't work: Client: [notice] Closing stream for '[scrubbed].onion': hidden servie is unavailable (try again later). Server: [notice] Tor 0.2.4.23 (git-417f0cacd726e549) opening log file. [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. [notice] We now have enough directory information to build circuits. [notice] Bootstrapped 80%: Connecting to the Tor network. [notice] Bootstrapped 85%: Finishing handshake with first hop. [notice] Bootstrapped 90%: Establishing a Tor circuit. [notice] Tor has successfully opened a circuit. Looks like client functionality is working. [notice] Bootstrapped 100%: Done. Not work. [notice] New control connection opened. [notice] New control connection opened. [notice] New control connection opened. Unstable. It stil work after change identity (command via control port), but is unstable. Sometime work and sometime doesn't work! (The time clock is ok).

1 0

Tor GSOC Fog Status Report #5
by quinn jarrell 02 Aug '14

02 Aug '14

H, Since the last status report, I've worked on a couple of things - Refactored the fog client code - worked on ticket #12614 [0] This is my second to last GSOC report. For the last two weeks I'll be working on getting a working version of #12614 in and cleaning/adding tests to the fog code. Quinn [0] https://trac.torproject.org/projects/tor/ticket/12614

1 0

[GSoC 2014] Revamp GetTor status update #5
by Israel Leiva 02 Aug '14

02 Aug '14

Hi all! This is my fifth status update for the Revamp GetTor GSoC project. I'll try summarize what I've done so far. If you have any comments, please tell me. Achievements: [*] New file structure of the current work. All modules now inside a gettor package. Everything is cleaner now. [*] Major code cleaning, better comments and error handling. Created exceptions for possible issues on every module. Created new module with utilities for the core module and the others (smtp and xmpp so far). [*] Created XMPP module. It receives messages and reply with links in the given locale (if specified; english by default). [*] Added info about built-in pluggable transports; if somebody mention pt, pluggable transports, obfs, obfsproxy, we reply him/her with additional info about the built-in pluggable transports (dummy message for now). [*] Added sha1 info of packages along with the dropbox links. Goals until next (last) bi-weekly report: [+] Solve pending issues on XMPP module [+] Test SMTP module on a mail server. [+] Create a basic Twitter module. [+] Create basic documentation of what was done during gsoc. As always, you can check what's been done on [0]. Have a nice weekend! [0]: https://github.com/ileiva/gettor/tree/master/src Best, -- israel

1 0

[GSoC] HTTPS Everywhere Secure Ruleset Updater Report
by Red 01 Aug '14

01 Aug '14

Hello everyone! Sorry about the fact that I haven't made a report in a few weeks. It's been a busy time for me. With that said, I have been getting quite a bit of work done on my project to build a secure ruleset updating mechanism for the HTTPS Everywhere Firefox browser extension. In my last report, I talked about the fact that I had been struggling with finding an appropriate solution to the problem of generating an appropriate signature on (the digest of) the update information provided by an update.json file. The problem was brought to some other core developers and it was decided that we would use an existing tool included in recent versions of the NSS tools. Since then, I have been working to integrate my updater into the existing HTTPS Everywhere codebase, which had involved quite a bit of refactoring. I have succeeded in getting the mechanism functional in the extension and have also taken care of keeping the master branch I was working off of up to date. This means that my feature will be able to be pulled into the newly released HTTPS Everywhere 5.0 development release as soon as it's been even more thoroughly tested! I am once again having an issue with signature verification. My mentor, Yan, had found a method of (as described above) using NSS tools to generate a signature that the Mozilla XPCOM component designed to do so could understand and verify. I have not been able to successfully repeat this process in a way that produces a signature that my ruleset updating mechanism has been able to verify the authenticity of the signature produced. The good news is that once this issue is resolved, the feature should be working just right and all that will remain will be to: 1. Add some elements to the UI to configure the updater. 2. Reset some preferences that were provided defaults for testing purposes. 3. Add another simple test to the ruleset update authenticity check to verify that the source URL is an EFF domain. I don't anticipate that these will be difficult changes at all. You can follow my progress by watching my fork of the repository on github and keeping an eye on the branch I am developing: https://github.com/redwire/https-everywhere/tree/rulesetUpdating As always, constructive feedback and ideas are always welcome! Thanks, Zack

1 0

Orbot & Orfox - GSoC bi-weekly report 5
by Amogh Pradeep 01 Aug '14

01 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Status Report 5 August 1st, 2014. Things I did the past couple of weeks: 1) Trying to fix leaks: After finding out that the browser has a dns leak, I went ahead and tried to look for the causes of this leak and came across https://bugzilla.mozilla.org/show_bug.cgi?id=942652 , which stated that not all parts of the browser use the proxy settings. This may or may not be causing the leaks but it is something that has to be fixed for sure, hence I'm trying to get advice on how to go about it. 2) Stripping out the unnecessary parts of fennec: This is something that I have started working on but things seem to be a little harder than I expected, but I'll keep at it. 3) Contributing to Mozilla: As we are using the fennec browser, I felt like helping the Mozillians a bit and hence I worked on a few bugs there and landed about three of them. More to come: - - Trying to fix the dns leak. - - Helping out Mozilla more. - - Working on Orbot a little. -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJT2/5NAAoJELm/SSKdtjUk6/AH/j8GnaMtK1bG7HW78g5p26DU MzVjn/QVDkjTpX0hsFeWzZ9k3vzRWHF5SI2QUFWQCaezTfyJa0WLhj2dpQvLGqVQ y7Nymx+klyNu1Tm/nQt20Hxn7fH04RVdfB+8DmXnp6f/Qerubqqeusw8JvBBh8HX ErhYDrmcAjwRpz7ZOimvO/yMGSfxjPbtcEO+27CSuhXnApckjL0FxFo/T46Kzc4b aPLGZp/oLJ50ThMOCEtb7ZH0gzBmX9EO37vVcZIeB0qMadqTs6PEi77/gHLh+jvB IQ20YRUDTIktG12gDS2/bvQBdroGQFc2m4aOVieSJ6izVV4uyE8qRUgcjjYok0w= =XgSw -----END PGP SIGNATURE-----

1 0

Proposal 236 and the guardiness of a guard
by George Kadianakis 01 Aug '14

01 Aug '14

One of the aims of proposal 236 is to reduce the period of inactiveness when a relay becomes a guard (see 'Phase three' of [0]). This phenomenon will become worse when the lifetime of the guard gets increased to 9 months, so we need to find a good fix. Proposal 236 tries to make young guards more likely to be picked as middle nodes by clients: this way their guard inactivity will be compensated by working as middle nodes . This is specified in section 1.3 of proposal 236 [1] and you can read a discussion about this in [2]. I quote here the most relevant part of that section: A guard N that has been visible for V out of NNN*30*24 consensuses has had the opportunity to be chosen as a guard by approximately F = V/NNN*30*24 of the clients in the network, and the remaining 1-F fraction of the clients have not noticed this change. So when being chosen for middle or exit positions on a circuit, clients should treat N as if F fraction of its bandwidth is a guard (respectively, dual) node and (1-F) is a middle (resp, exit) node. Let Wpf denote the weight from the 'bandwidth-weights' line a client would apply to N for position p if it had the guard flag, Wpn the weight if it did not have the guard flag, and B the measured bandwidth of N in the consensus. Then instead of choosing N for position p proportionally to Wpf*B or Wpn*B, clients should choose N proportionally to F*Wpf*B + (1-F)*Wpn*B. The relevant trac ticket is #9321 and I asked myself various engineering questions in [3]. These engineering questions can be ignored for now but they will need to resolved eventually. This email is more concerned with the research side of this task. I recently wrote a python script that calculates in how many consensuses a guard appears and then calculates the guard/middle weights and probabilities according to section 1.3 of proposal 236 [1]. The results were as expected for the biggest part. That is, new guards got a boost in their middle probabilities. You can see the output of my script here https://people.torproject.org/~asn/guards3/output and you can see boxplots of the guard and middle probabilities here: https://people.torproject.org/~asn/guards3/guard_boxplot.png https://people.torproject.org/~asn/guards3/middle_boxplot.png I mainly uploaded them so that the outliers probs are seen better. I also highlighted some snippets of the output at [4]. Here are some notes: - You can see that old guards (like RichardFeynman) see a shrinkage both on their guard and on their middle probabilities. This happens because both the total guard weight and the total middle weight get bigger [5], so their weight percentage gets smaller. - You can see that weird things happen to relays that are *both* a Guard and an Exit (like thevillage1 and TorLand1). Specifically, even for young guards, their middle probability gets decreased and their guard probability gets increased. This is especially visible for the village1 for which the guard probability gets increased by 0.008 making it the most probable guard of all, with probability 0.0101. This happens because of the Guard+Exit bandwidth weights [6]. Specifically, it happens because Wgd << Wgm. We should decide whether this behavior is a feature or a bug (it might be a feature, since we don't really want to overload exit nodes with middle traffic if they also happen to be young guards) - You can also see that for young guards (like freefrcv2), the feature works as intended: pumping up their middle probability. This is just an update on this task and any comments are welcome :) [0]: https://blog.torproject.org/blog/lifecycle-of-a-new-relay [1]: https://gitweb.torproject.org/torspec.git/blob/7bd906b6ecef7a0dcf3b420944da… [2]: https://lists.torproject.org/pipermail/tor-dev/2014-March/006571.html https://lists.torproject.org/pipermail/tor-dev/2014-April/006654.html [3]: https://trac.torproject.org/projects/tor/ticket/9321#comment:13 [4]: A685A493342B15476A8AA35CE2868B62C0331D6B in 22 out of 1966 consensuses (1%) (tingPLrice5) A685A493342B15476A8AA35CE2868B62C0331D6B: guard prob 0.00001466095664981207628234955862 -> 0.00001236359278611040906223472603 (delta: -0.00000229736386370166722011483259) A685A493342B15476A8AA35CE2868B62C0331D6B: middle prob 0.00001411262320417776315899083553 -> 0.00002313283079875486344342985726 (delta: 0.00000902020759457710028443902173) 2009F87590E626C98E1A5C8D08C23366C58B7951 in 46 out of 1966 consensuses (2%) (thevillage1) 2009F87590E626C98E1A5C8D08C23366C58B7951: guard prob 0.001799671590571654712486494434 -> 0.01018493194688813591277789142 (delta: 0.008385260356316481200291396986) (exit) 2009F87590E626C98E1A5C8D08C23366C58B7951: middle prob 0.002531389208535432867885203535 -> 0.00003970964677012672298440629596 (delta: -0.002491679561765306144900797239) (exit) B1A88CFED023588C713E42B9ABA0AD2A294BECCF in 470 out of 1966 consensuses (23%) (ChronosDaKnObNET) B1A88CFED023588C713E42B9ABA0AD2A294BECCF: guard prob 0.00002846894283361195170183376972 -> 0.0001308372445794862073501048856 (delta: 0.0001023683017458742556482711159) (exit) B1A88CFED023588C713E42B9ABA0AD2A294BECCF: middle prob 0.00004004395860053895959111507317 -> 0.000006418213054140890599306823457 (delta: -0.00003362574554639806899180824971) (exit) 2D958EED2BC8EB672187C99CF6A4D8D8EBDBE412 in 474 out of 1966 consensuses (24%) (freefrcv2) 2D958EED2BC8EB672187C99CF6A4D8D8EBDBE412: guard prob 0.00004462030284725414520715083057 -> 0.00003762832587077081018941003575 (delta: -0.00000699197697648333501774079482) 2D958EED2BC8EB672187C99CF6A4D8D8EBDBE412: middle prob 0.00004295146192575840961431993422 -> 0.00006073004942478721908966913122 (delta: 0.00001777858749902880947534919700) 4A5ADDBAC82BC071D9516FB01429A1CAD493D36C in 865 out of 1966 consensuses (43%) (monoversum) 4A5ADDBAC82BC071D9516FB01429A1CAD493D36C: guard prob 0.008658463528693363891387601646 -> 0.007301687043971002453421233128 (delta: -0.001356776484722361437966368518) 4A5ADDBAC82BC071D9516FB01429A1CAD493D36C: middle prob 0.008334628921307881865635891998 -> 0.01016060938520887622674424842 (delta: 0.001825980463900994361108356422) B7A4718F146139B8137BBD7CF2890AFA61C2BAB7 in 1065 out of 1966 consensuses (54%) (PPTOR0001) B7A4718F146139B8137BBD7CF2890AFA61C2BAB7: guard prob 0.00001880427048562853262301356431 -> 0.00001585765161696769857982280078 (delta: -0.00000294661886866083404319076353) B7A4718F146139B8137BBD7CF2890AFA61C2BAB7: middle prob 0.00001810097324014104405174911514 -> 0.00002026262077783844197435510639 (delta: 0.00000216164753769739792260599125) E1E922A20AF608728824A620BADC6EFC8CB8C2B8 in 1616 out of 1966 consensuses (82%) (TorLand1) E1E922A20AF608728824A620BADC6EFC8CB8C2B8: guard prob 0.001442840154510033519493482607 -> 0.002483448551109987826331785865 (delta: 0.001040608396599954306838303258) (exit) E1E922A20AF608728824A620BADC6EFC8CB8C2B8: middle prob 0.002029475830980993592356240765 -> 0.001118418926871964944505332348 (delta: -0.000911056904109028647850908417) (exi) 8699371415DC052A60BCA3AAD68E55D9B759CAE0 in 1858 out of 1966 consensuses (94%) (torrorist) 8699371415DC052A60BCA3AAD68E55D9B759CAE0: guard prob 0.000009508374059117252371523807943 -> 0.000008018417060557113123695710000 (delta: -0.000001489956998560139247828097943) 8699371415DC052A60BCA3AAD68E55D9B759CAE0: middle prob 0.000009152752005608042048765795507 -> 0.000006628989446427573975351367609 (delta: -0.000002523762559180468073414427898) 3FE4CF4366E128154E951FEBB3B448CC2F3E1EBA in 1966 out of 1966 consensuses (100%) (RichardFeynman) 3FE4CF4366E128154E951FEBB3B448CC2F3E1EBA: guard prob 0.0003304027187022866466529501978 -> 0.0002786287939478505230692028838 (delta: -0.0000517739247544361235837473140) 3FE4CF4366E128154E951FEBB3B448CC2F3E1EBA: middle prob 0.0003180453490216872711917499891 -> 0.0002132317299501384937260708373 (delta: -0.0001048136190715487774656791518) 7E43F05A970431239898FDDCE014B1BA5134703F in 1966 out of 1966 consensuses (100%) (PrivacyRepublic0003) 7E43F05A970431239898FDDCE014B1BA5134703F: guard prob 0.0002102202590710855289154482723 -> 0.0001772788598061129408325756509 (delta: -0.0000329413992649725880828726214) (exit) 7E43F05A970431239898FDDCE014B1BA5134703F: middle prob 0.0002956924463418544427572802405 -> 0.0001982453510501193425034660120 (delta: -0.0000974470952917351002538142285) (exit) [5]: total guard weight: 11176705.8531 new total guard weight: 13253526.12584313326551373350 total middle weight: 7945992.6321 new total middle weight: 11851828.99651449643947100714 [6]: Wme=0 # Weight for Exit-flagged nodes in the middle Position Wmd=867 # Weight for Guard+Exit flagged nodes in the middle Position Wmg=4063 # Weight for Guard-flagged nodes in the middle Position Wmm=10000 # Weight for non-flagged nodes in the middle Position Wgd=867 # Weight for Guard+Exit-flagged nodes in the guard Position Wgg=5937 # Weight for Guard-flagged nodes in the guard position Wgm=5937 # Weight for non-flagged nodes in the guard Position

4 5

Re: [tor-dev] DNS proposal for Tor hidden services
by Jesse Victors 01 Aug '14

01 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Tyrano, Thank you for your feedback. However, I'm not sure I fully understand your questions. Under my proposal, at least at this moment, if a domain ends with .tor (regex match) it is the human-name for a Tor hidden service and requires translation. The .tor domain, like .onion and the obsolete .exit, cannot be reached from outside Tor and will case an immediate DNS failure on the clearnet DNS system. As far as I know, the .tor domain is not in use in the clearnet, so I think I am safe in using it. If the .tor cannot be found, I don't like the idea of retrying it on the clearnet through the Tor exit, that just leaks the lookup and your objective too many times. If you are looking up X.tor, it's quite likely that you're interested in browsing X.tor, and that is a small compromise of your privacy. Leaking the .tor lookup on clearnet DNS servers also introduces a small possibility for timing attacks. On a different note, I'm sorry about the malformatting and the bad signature on my opening post. I'm not sure what happened there, but nothing other than formatting was amiss. - -- Jesse V. /CS, Network Security/ /Utah State University/ On 08/01/2014 03:39 AM, Tyrano Sauro <tyranosu(a)yahoo.co.nz> wrote: > Can we know a DNS for the normal HTTP of a hidden service? > If the onion hidden name cannot reach from outside of Tor then maybe use that? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCgBmBQJT277DXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAJu4H/R/aYKDAIdnJFh4UXQpt3kBm 60mevMh5E12a2a/SnW8R09jkzjKCoDhf2wQjiXjCnry/PLOBHoo3v/YZhe/jZxj/ xAyaPy1pmMaYHmGKlulV385nG80tBFrVXXCkk/9bOe6cU97izwDUyHQ/vrryPs60 WoVglAm3Zus9badQxfYOVl6hrn/vqp3IhZ9J8UEjzqPiRUM5p5Uv43zlGUmjNn6u JU+YFNj5NegAS884EFusz92jzgOeMK9GAcT4x3sYfHsy5StvZE7OZdIwz2gZJl6m zGOX7B17BIt8NkAcLAQgSLaVoKuYo2ajgW/i2vcLcg3WXtjCJ7znQUd27U42VUc= =zWU3 -----END PGP SIGNATURE-----

1 0

OnionMail: Some attack attempt by unknown scanner + Tor Network scanning.
by Liste 01 Aug '14

01 Aug '14

Into the OnionMail's federated network there are two exit/enter server that forward the email messages between tor network and the internet. These servers are: onionmail.info and onionmail.zapto.org The first is the mail exit server, the second is a server to do network testing and security check. We was recived some scanning from 198.143.173.188 and other chinese and russian proxy form jaunary to yesterday. The exit node of OnionMail has a correlation between hidden services and ip address. To prevent real correlation we are implementing a new deamon NTU: Network Terminator Unit. (A proxy between tor, internet and vice versa). Back to the point: The NTU project could be update to hide the hidden services rotating the connections between tor relay servers. We can create another layer to protect the hidden services real ip address using a protol like ATM. (Connection ID, relative to hop and *not use ip address* with Virtual Circuit Multiplexing). The server onionmail.zapto.org was over debugging and wireshark. We make available the logs if you need to lend a hand to understand what happened.

1 0

unsubscribe
by Patrick Reed 01 Aug '14

01 Aug '14

On Aug 1, 2014, at 7:39 AM, tor-dev-request(a)lists.torproject.org wrote: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Re: DNS proposal for Tor hidden services (Tyrano Sauro) > 2. New project idea (bomerino(a)tiscali.it) > 3. Re: Proposal 236 and the guardiness of a guard (George Kadianakis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 31 Jul 2014 20:40:46 -0700 > From: Tyrano Sauro <tyranosu(a)yahoo.co.nz> > To: "tor-dev(a)lists.torproject.org" <tor-dev(a)lists.torproject.org> > Cc: Ming Li <ming.li(a)usu.edu> > Subject: Re: [tor-dev] DNS proposal for Tor hidden services > Message-ID: > <1406864446.92726.YahooMailNeo(a)web163106.mail.bf1.yahoo.com> > Content-Type: text/plain; charset="utf-8" > > Can we know a DNS for the normal HTTP of a hidden service? > If the onion hidden name cannot reach from outside of Tor then maybe use that? > > > > ________________________________ > From: Jesse Victors <jvictors(a)jessevictors.com> > To: tor-dev(a)lists.torproject.org > Cc: Ming Li <ming.li(a)usu.edu> > Sent: Tuesday, 29 July 2014 6:03 PM > Subject: [tor-dev] DNS proposal for Tor hidden services > > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > Hello everyone, > > I have a proposal for Tor hidden services, which if it's a good idea > and workable I may be writing my Master's thesis on. My description > here is very early, and I would like to run it by you guys before I > continue further. I have already run it past Tor developers, but > have seen limited response, so I'm opening it up to a wider > audience. Basically, I propose integrating Namecoin into supporting > Tor relays, so as to provide a secure DNS service for .onion sites > within Tor itself. The result is that a human-readable address can > be translated into its .onion counterpart, analogous to a domain > name resolving into an IP address on the regular Internet, a square > of Zooko's Triangle conjecture. > > Namecoin has a nearly identical codebase to Bitcoin, but instead of > currency its primary focus is holding information, with a focus in > DNS. Domains in Namecoin have the .bit extension, and registrations > are secured with hashes in a blockchain. Anyone with the Namecoin > blockchain can look up information in it, and indeed there are > already Namecoin-supporting DNS servers that use the Namecoin > blockchain to look up registrations in it. These basic premises are > at the heart of my idea. Now, 3g2upl4pq6kufc4m.onion is the address > for the DuckDuckGo hidden service, but it's hard to remember: even > worse than a traditional IP address. Under my idea, a user could > type in duckduckgo.tor, would see a secure translation to > 3g2upl4pq6kufc4m.onion transparently and with masking, increasing > the usability and popularity of hidden services significantly. > > My plan is in the context of Tor, to use the .tor domain, so as to > not conflict with existing Namecoin registrations. The .onion > address is a hash of the hidden service's public key, so if I own > the private keys to 3g2upl4pq6kufc4m.onion, I should be able to sign > something (perhaps the Namecoin public DSA key) to prove my > ownership and set duckduckgo.tor.bit to point to > 3g2upl4pq6kufc4m.onion. I then upload this to the Namecoin network > as usual, (this costs 0.01 Namecoin) so that it becomes integrated > into the blockchain. So now duckduckgo.tor.bit points to > 3g2upl4pq6kufc4m.onion, and everyone with the blockchain knows it. > Global DNS propagation may take less than 15 minutes. Namecoin > domain registrations expire after 36,000 blocks (about 200 days) so > a registration would have to be renewed occasionally for it to still > remain. This is free to do, but ensures that domains don't endure > indefinitely. > > It's impractical for Tor users to download the Namecoin blockchain > in order to use this system, (even with Merkle trees) so instead > supporting Tor relays can hold a copy and the Tor client can send > out queries to them. At startup, Tor clients build several circuits > through the network in preparation for use. Now let's say the user > wants to look up duckduckgo.tor. To avoid spoofing attacks from a > malicious relay, Tor clients will query multiple relays and gain a > consensus. To do this, the Tor client generates three nonces, N1, > N2, and N3. It then picks three random relays, possible trusted > relays like guards, R1, R2, and R3. These relays have public RSA > keys K1, K2, and K3, respectively. For each of the three relays, the > Tor client takes the request for duckduckgo.tor, nonce Nj, and > encrypts the pair with the relay's public key Kj. Along with a > special new Tor flag specifying the use of this protocol, it then > sends the trio through the circuit to the middle relay. The middle > relay then queries the three relays. Each relay decrypts the request > using its private key, checks the blockchain for duckduckgo.tor.bit, > finds 3g2upl4pq6kufc4m.onion, and encrypts this answer with the > nonce, and sends it back, signing the result. The client receives > the answers, checks the signatures, decrypts the responses from the > three relays using the nonces, and compares the response. If all > three match, it then looks up 3g2upl4pq6kufc4m.onion in the > traditional way. If two or less match, it restarts with a different > set of three relays. If all three relays return that duckduckgo.tor > can't be found, it throws the standard DNS error message. > > So I am simply building on top of the existing Tor hidden service > infrastructure, not modifying it. I can write up a proposal for > torspec.git once I have more details. I've already taken Tor > 0.2.5.6-alpha code, installed Tor from source, and used Chutney to > set up a mini Tor network on localhost of 5 authorities, 10 relays, > and 1 client. That seems a good platform for development on this. > > What do you guys think about my proposal? Is this a good idea, and > feasible? Anything I should watch out for as I go forward? What > security threats exist that I should specifically defend against? > > Thank you for your time. > > - -- > Jesse V. > /CS, Network Security/ > /Utah State University/ > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQF8BAEBCgBmBQJT2BouXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB > RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yA98MH/ih8VMQ8ZaKInYDDe3HBiU/s > 9XBoGUT7ouXqnmtjSLjeTJjDfaNmLYBIRsAJTk8n/mJ7Zz9ld/5FW/QNKd1hAelE > wtL4hKyVhS70fWVkFqZTLLyeVHVbegJx5sF2YdkDD6cJDU//KNbXTCO7A1Bx9vOu > vPFoA+3ytlKcpx8HZn//k0mD7cB/dcS2GwSQmG2C+X0pWooJIsAJCgKyetbAaiHL > ub/sd6Sr0bgkItGOi9vlAdPo+p7nNMWVxQQPfNqzz1zQJzE3WRXpXKmIYAOtngWp > VT6SyrSkOmir/1+LN/s9d22VMaQKAzUVz21gbugBr64moeQW/IWbWBOQSbFA0J0= > =8zWV > -----END PGP SIGNATURE----- > > > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >

1 0

New project idea
by bomerino＠tiscali.it 01 Aug '14

01 Aug '14

Hi all, my name is Omar, I am 33 years old and I am an Italian IT Engineer, I have worked for more than 10 years in coding and now I am a Portfolio Manager. I am quite interesting in TOR and in the application related. I have these two following idea for new TOR related project (obviously if you think can be useful I would like to be the owner, to have the property right or I do not how work this...please give me more information regarding that): 1. the first idea is more related to OnionCoffee, due to the fact that I would like use this library to provide another kind of anonyms for android, and if possible why not for apple. What I mean is to create a "ping pong" signal with several different Base Station so that your current location is unknown or appear like if you are in several place in the same time if someone trying to follow your mobile and your physical movement, or through GPS or through the signal you exchange with your nearer base station where you smart phone is connected. this is help you to stay safe and located in several place and not in only one, so if people looking for you and map your physical movement they do not know where you are really located 2. the second idea is TOR related, because I know TOR manage the header of the package send by TCP protocol so that no one can trace your connection and I would like to create an encryption library that encode and decode all the content of the data exchanged in the payload with a quantum cryptography algorithm, that give you the chance to exchange data and if something happen during the connection (like someone try to attack your data) the data content change, like in the Heisenberg principle. Create a client java library that encode and decode all content that you want to encrypt, for example a private chat. This I dare say add a new level of anonymity in addition to the fact to hide you location and who you are: you hide the content of what you are doing. I would like to create this two kind of project having the copyright of the idea and becoming the owner of this two projects. Of course I need technical knowledge support to build this. In which way TOR organize these things or I have to think to everything? What do you think about that? Thanks for your advises on my idea. Regards Scopri istella, il nuovo motore per il web italiano. Istella garantisce risultati di qualità e la possibilità di condividere, in modo semplice e veloce, documenti, immagini, audio e video. Usa istella, vai su http://www.istella.it?wtk=amc138614816829636

1 0

DNS proposal for Tor hidden services
by Jesse Victors 01 Aug '14

01 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello everyone, I have a proposal for Tor hidden services, which if it's a good idea and workable I may be writing my Master's thesis on. My description here is very early, and I would like to run it by you guys before I continue further. I have already run it past Tor developers, but have seen limited response, so I'm opening it up to a wider audience. Basically, I propose integrating Namecoin into supporting Tor relays, so as to provide a secure DNS service for .onion sites within Tor itself. The result is that a human-readable address can be translated into its .onion counterpart, analogous to a domain name resolving into an IP address on the regular Internet, a square of Zooko's Triangle conjecture. Namecoin has a nearly identical codebase to Bitcoin, but instead of currency its primary focus is holding information, with a focus in DNS. Domains in Namecoin have the .bit extension, and registrations are secured with hashes in a blockchain. Anyone with the Namecoin blockchain can look up information in it, and indeed there are already Namecoin-supporting DNS servers that use the Namecoin blockchain to look up registrations in it. These basic premises are at the heart of my idea. Now, 3g2upl4pq6kufc4m.onion is the address for the DuckDuckGo hidden service, but it's hard to remember: even worse than a traditional IP address. Under my idea, a user could type in duckduckgo.tor, would see a secure translation to 3g2upl4pq6kufc4m.onion transparently and with masking, increasing the usability and popularity of hidden services significantly. My plan is in the context of Tor, to use the .tor domain, so as to not conflict with existing Namecoin registrations. The .onion address is a hash of the hidden service's public key, so if I own the private keys to 3g2upl4pq6kufc4m.onion, I should be able to sign something (perhaps the Namecoin public DSA key) to prove my ownership and set duckduckgo.tor.bit to point to 3g2upl4pq6kufc4m.onion. I then upload this to the Namecoin network as usual, (this costs 0.01 Namecoin) so that it becomes integrated into the blockchain. So now duckduckgo.tor.bit points to 3g2upl4pq6kufc4m.onion, and everyone with the blockchain knows it. Global DNS propagation may take less than 15 minutes. Namecoin domain registrations expire after 36,000 blocks (about 200 days) so a registration would have to be renewed occasionally for it to still remain. This is free to do, but ensures that domains don't endure indefinitely. It's impractical for Tor users to download the Namecoin blockchain in order to use this system, (even with Merkle trees) so instead supporting Tor relays can hold a copy and the Tor client can send out queries to them. At startup, Tor clients build several circuits through the network in preparation for use. Now let's say the user wants to look up duckduckgo.tor. To avoid spoofing attacks from a malicious relay, Tor clients will query multiple relays and gain a consensus. To do this, the Tor client generates three nonces, N1, N2, and N3. It then picks three random relays, possible trusted relays like guards, R1, R2, and R3. These relays have public RSA keys K1, K2, and K3, respectively. For each of the three relays, the Tor client takes the request for duckduckgo.tor, nonce Nj, and encrypts the pair with the relay's public key Kj. Along with a special new Tor flag specifying the use of this protocol, it then sends the trio through the circuit to the middle relay. The middle relay then queries the three relays. Each relay decrypts the request using its private key, checks the blockchain for duckduckgo.tor.bit, finds 3g2upl4pq6kufc4m.onion, and encrypts this answer with the nonce, and sends it back, signing the result. The client receives the answers, checks the signatures, decrypts the responses from the three relays using the nonces, and compares the response. If all three match, it then looks up 3g2upl4pq6kufc4m.onion in the traditional way. If two or less match, it restarts with a different set of three relays. If all three relays return that duckduckgo.tor can't be found, it throws the standard DNS error message. So I am simply building on top of the existing Tor hidden service infrastructure, not modifying it. I can write up a proposal for torspec.git once I have more details. I've already taken Tor 0.2.5.6-alpha code, installed Tor from source, and used Chutney to set up a mini Tor network on localhost of 5 authorities, 10 relays, and 1 client. That seems a good platform for development on this. What do you guys think about my proposal? Is this a good idea, and feasible? Anything I should watch out for as I go forward? What security threats exist that I should specifically defend against? Thank you for your time. - -- Jesse V. /CS, Network Security/ /Utah State University/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCgBmBQJT2BouXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yA98MH/ih8VMQ8ZaKInYDDe3HBiU/s 9XBoGUT7ouXqnmtjSLjeTJjDfaNmLYBIRsAJTk8n/mJ7Zz9ld/5FW/QNKd1hAelE wtL4hKyVhS70fWVkFqZTLLyeVHVbegJx5sF2YdkDD6cJDU//KNbXTCO7A1Bx9vOu vPFoA+3ytlKcpx8HZn//k0mD7cB/dcS2GwSQmG2C+X0pWooJIsAJCgKyetbAaiHL ub/sd6Sr0bgkItGOi9vlAdPo+p7nNMWVxQQPfNqzz1zQJzE3WRXpXKmIYAOtngWp VT6SyrSkOmir/1+LN/s9d22VMaQKAzUVz21gbugBr64moeQW/IWbWBOQSbFA0J0= =8zWV -----END PGP SIGNATURE-----

2 1

[DRAFT] Proposal: All Routers are Directory Servers
by Matthew Finkel 01 Aug '14

01 Aug '14

Hi All, Below is a draft proposal for making all relays also be directory servers (by default). It's almost ready for a number, but it can use some feedback beforehand (give or take a few days). Tonight I also found that Nick actually created a similar proposal a few moons ago (Proposal 185: Directory caches without DirPort). This new proposal may benefit from superseding that one, but I recommend they remain distinct proposals, for now. In general I'm not tied to any of the proposed names, so suggestions are welcome. Thanks! ======================================================================= Filename: directory-servers-for-all.txt Title: All routers are directory servers Author: Matthew Finkel Created: 29-Jul-2014 Status: Draft Target: 0.2.6.x Overview: (In practice we refer to the servers that mirror directory documents as directory servers, directory mirrors, and directory caches. Sometimes we also shorten directory to dir. This proposal attempts to consistently use directory server to refer to this functionality. We also typically use the term router and relay interchangably. This proposal uses (onion) router.) This proposal aims at removing part of the distinction between the router and the directory server. Currently operators have the options of being one of: an onion router, a directory server, or both. With the acceptance of this proposal the options will be simplified to being either only a directory server or a combined router and directory server. All routers will serve directory requests. Motivation: Fetching directory documents and descriptors is sometimes a non-trivial operation for clients. If they do not have a consensus then they must contact a directory authority (until directory sources are added or clients are able to use a fallback consensus). If they have a consensus and have at least one entry guard then the client can query that guard for documents. If the document isn't available then after a period of time the client will attempt to retry downloading it. If the entry guard isn't a directory server, as well, a directory server and/or directory guard must be chosen (based on the server having an open DirPort) and queried for the document. At a minimum, this has a potential performance impact, at worst it's an attack vector that allows for profiling clients and partitioning users. With the orthogonally proposed move to clients using a single guard, the potential performance bottleneck and ability to profile users could be increased. If the client selects an entry guard and it is not a directory server then the client may select a distinct directory guard which will leak client behavior to a second node. In the case where the client does not use guards, it is important to have the largest possible amount of diversity in the set of directory servers. In a network where every router is a directory server, the profiling and partitioning attack vector is reduced to the guard (for clients who use them), which is already in a privileged position for this. In addition, with the increased set size, relay descriptors and documents are more readily available and it diversifies the providers. Design: The changes needed to achieve this should be simple. Currently all routers download and cache the majority of router documents in any case, so the slight increased memory usage from downloading all of them should have minimal consequences. There will be necessary logical changes in the client, router, and directory code. Currently directory servers are defined as such if they advertise having an open directory port. We can no longer assume this is true. To this end, we will introduce a new server descriptor line. "tunnelled-dir-server" The presence of this line indicates that the router accepts tunnelled directory requests. For a router that implements this proposal, this line MUST be added to its descriptor if it does not advertise a directory port, and MAY be added if it also advertises an open directory port. In addition to this, routers will now download and cache all descriptors and documents listed in the consensus, regardless of whether they are deemed useful or usable, exactly like the current directory servers. All routers will also accept directory requests when they are tunnelled over a connection established with a BEGIN_DIR cell, the same way these connections are already accepted by bridges and directory servers with an open DirPort. Directory Authorities will now assign the V2Dir flag to a server if it supports a version of the directory protocol which is useful to clients and it has at least an open directory port or it has an open OR port and advertises "tunnelled-dir-server" in its server descriptor. Clients choose a directory by using the current criteria with the additional qualification that a server only needs the V2Dir status flag instead of requiring an open DirPort. When the client chooses which directory server it will query, it checks if the server has an open directory port and uses begindir if it does not. This will minimize the increased number of clients that prefer begindir over direct connections and thus also minimizes the additional overhead on the network from clients establishing OR connections for directory requests. Security Considerations and Implications: Currently all directory servers are explicitly configured. This is necessary because they must have a configured and reachable external port. However, this is a restriction and results in a reduced number of directory servers on the network. As a result, this could allow an adversary to control a significant fraction of the servers. By increasing the number of directory servers on the network the likelihood of selecting one that is malicious is reduced. Also, with this proposal, it will be more likely that a client's entry guard is also a directory server (as alluded to in Proposal 207). However, the reduced anonymity set caused when the guard does not have, or is unwilling to distribute, a specific document still exists. With the increased diversity in the available servers, the impact of this should be reduced. Another question that may need further consideration is whether we trust bad directories to be good guards and exits. Specification: The version 3 directory protocol specification does not currently document the use of directory guards. This spec should be updated to mention the preferred use of directory guards during directory requests. In addition, the new criteria for assigning the V2Dir flag should be documented. Considerations for Resource Constrained Hardware: If all routers become directory servers, they will choose to download all documents, regardless of whether they are useful, in case another client does want them. This will have very little impact on the "typical" router, however on memory constrained routers (Raspberry Pi and similar), every kilobyte allocated to directory documents is not available for new circuits. Should we add a config option that allows operators to disable being a directory server? Is it more worthwhile for them to serve these documents or to relay cells? Future Considerations: Should the DirPort be deprecated at some point in the future?

2 2

[android dev] probably a stupid noob question… but
by CJ 31 Jul '14

31 Jul '14

… how may I add netcipher lib to an Android Studio project? I've searched on the Net, but nothing seems to match my needs :( sorry for this stupid question, but I'm a bit stuck (yes, first android app, blah)… Cheers, C.

3 3

Pluggable transports meeting tomorrow (16:00UTC Friday 1st of August 2014)
by George Kadianakis 31 Jul '14

31 Jul '14

Hello brothers and sisters, just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks!

1 0

Centos 7
by obx 30 Jul '14

30 Jul '14

hi, is somebody working on a rpm for centos 7? Is there an ETA? Thanks in advance.

2 1

Email Bridge Distributor Interactive Commands
by Matthew Finkel 30 Jul '14

30 Jul '14

Hi everyone, A short time ago BridgeDB learned how to accept some more commands via email[0]. Below is an example of the current help/overview autoresponse email[1] that users receive (in English, we do have translations). These commands may not be optimal, so we'd love to be given feedback on this so we can improve it. Currently, with the recent changes, we require all commands begin with 'get' and then we check which keyword follows it ('bridges', 'transport', 'help', 'key', etc). This certainly makes the parsing logic easy (and I am a fan of KISS), but it may be true that this is a bit too strict and decreases its usability. Would it be better if we were more lax? For example, instead of requiring: 'get transport <TYPE>' we change this to: '[[get] transport] <TYPE>' Therefore the 'get' and 'transport' keywords are optional (and 'get' is only used if you use 'transport'). <TYPE> is the pluggable tranport method name you want the bridges to support. I think this simplifies the user interaction but I don't know if it's significant and to what extent most users care about this. It should be mentioned that prior to the recent changes, sending a blank email to bridges(a)bridges.torproject.org was equivilent to sending an email that contained 'get bridges' because we didn't actually check for 'get bridges' at all, we do this now, though. So, the questions I am posing to those in the community who has an opinion about this: What do you think? What problems do you currently have with this? How can this be improved? Thanks! Matt [0] https://trac.torproject.org/projects/tor/ticket/7550 [1] > Hey, <you>! Welcome to BridgeDB! > > > > COMMANDs: (combine COMMANDs to specify multiple options simultaneously) > get bridges Request vanilla bridges. > get transport [TYPE] Request a Pluggable Transport by TYPE. > get help Displays this message. > get key Get a copy of BridgeDB's public GnuPG key. > get ipv6 Request IPv6 bridges. > > Currently supported transport TYPEs: > obfs2 > obfs3 > scramblesuit > > > BridgeDB can provide bridges with several types of Pluggable Transports[0], > which can help obfuscate your connections to the Tor Network, making it more > difficult for anyone watching your internet traffic to determine that you are > using Tor. > > Some bridges with IPv6 addresses are also available, though some Pluggable > Transports aren't IPv6 compatible. > > Additionally, BridgeDB has plenty of plain-ol'-vanilla bridges - without any > Pluggable Transports - which maybe doesn't sound as cool, but they can still > help to circumvent internet censorship in many cases. > > [0]: https://www.torproject.org/docs/pluggable-transports.html > > -- > <3 BridgeDB > ______________________________________________________________________ > Public Keys: https://bridges.torproject.org/keys > This email was generated with rainbows, unicorns, and sparkles > for your(a)email.com on Sunday, 20 July, 2014 at 16:59:19. >

12 34