- tor-dev - lists.torproject.org

[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