June 2016 - tor-dev - lists.torproject.org

[GSOC16] Fingerprint Central - Status report n°2
by Pierre Laperdrix 24 Jun '16

24 Jun '16

Hi everyone, Here is my second status report for my GSOC project. A little reminder that the repo is located on GitHub: https://github.com/plaperdr/fp-central 1 - I have progressed faster than I expected in the last two weeks. Here is everything that I have done: - Storage of fingerprints in a MongoDB database - Adding a small API to get statistics on stored variables - Adding support of hashed variables for faster stats computation - Adding collection of new attributes and support of HTTP headers - Adding support of translation with the start of a French version 2 - I also started development of a page to tell if a user has an "acceptable" fingerprint or not (I haven't pushed the code to GitHub yet). So far, I'm verifying that the screen resolution is in the correct bounds (i.e. not fullscreen) and that there are no plugins in the browser. If anyone has any idea that I could implement to help users have a less recognizable fingerprint, I'll be happy to add it. I have also added steps to follow to help people better configure their browser. 3 - I have tried to add a webpage where I can detect the level of the security slider. This way, I could give recommendations to users to maybe try a higher security level or it would be a way to know the distribution of Tor users on that feature. However, it has proven to be much harder than anticipated. * For "Medium-low", I verify that MathML is disabled. * For "High", I verify that there are either no JavaScript or no SVG elements. * I have troubles to detect the "Medium-High" level. I tried detecting the support of OpenType SVG fonts but it seems that I haven't found the right set of instructions to detect a difference. I'm using a font that I modified where I'm able to display a difference depending on the level of the security slider but I can't detect that difference through JavaScript. When SVG support is present, the displayed character is bigger than the HTML element but I can't detect that it is out of bounds. If anyone has any idea to detect the "Medium-high" level of the security slider, I'll be very happy about it. My goal in the next two weeks is to finish both the "acceptable fingerprint" page and the "slider" page. I also want to start working on a complete statistics page (outside of the main fingerprinting page). Hopefully, in two weeks, I'll have a version that is more complete and from there, I'll start digging into more complicated features like dealing with returning users. Have a great week-end, Pierre

3 6

Revisiting prop224 time periods and HS descriptor upload/downloads
by George Kadianakis 24 Jun '16

24 Jun '16

Hello, during March we discussed the cell formats of prop224: https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html The prop224 topic for this month has to do with the way descriptors get uploaded and downloaded, how this is scheduled using time periods and how the shared randomness subsystem interacts with all that. Here are some discussion topics. Lots of text on the first two, less text on the rest: - My main goal was to understand the prop224 sections [TIME-PERIODS] and [TIME-OVERLAP]. Those sections specify a system where hidden services decide in a probabilistic manner _when_ to publish their descriptor so that not all hidden services publish their descriptors at the same moment and cause a thundering herd that stampedes the network. For this to work, time is split into time periods of k hours each. A few hours before each time period, there is an overlap period where hidden services start publishing their _next_ descriptors to HSDirs, so that when the upcoming time period starts, all the HSDirs have already received the descriptors and are ready to serve them. Consider the overlap period at the end of time period #N. During that overlap period, hidden services publish their descriptors for future time period #N+1. In this case, hidden services also need to know the shared random value that will be active during time period #N+1, since it needs to be used to find the responsible HSDirs. This means, that the shared random value for time period #N+1 needs to be published _before_ the overlap period starts. This is not the case in current proposal 224, since time is split into time periods of 25 hours, which means that each day the start time shifts by one hour forward. Since the start/end times of the time periods keep on shifting, there will be cases where the right shared random value will not be accessible when the overlap period starts. So what to do? To fix this, I suggest we change the time period length to a day (24 hours). I also suggest we start time periods every day at 12:00 and finish after 24 hours same time, so that it works well with the current shared randomness schedule (where the new shared random value gets published at 00:00 every day). [It might actually be wiser to actually reverse those schedules: create the SRV at 12:00 and start the time period at 00:00] In any case, this is how this might look like: +------------------------------------------------------------------+ | | | 00:00 12:00 00:00 12:00 00:00 12:00 | | SRV#1 TP#1 SRV#2 TP#2 SRV#3 TP#3 | | | | $ |-----------$-----======|-----------$-----======| | | overlap12 overlap23 | | | +------------------------------------------------------------------+ Legend: [TP#1 = Time Period #1] [SRV#1 = Shared Random Value #1] So, this basically gives a space of 12 hours between the SRV generation and the start of the next time period. We can then easily fit an overlap period of 6 hours before the next time periods starts. In the above diagram, the "equal sign" segments are the overlap periods. 'overlap12' is the overlap period from TP#1 to TP#2. Do you think that's reasonable? And do you see any problems with changing the time period length from 25 hours to 24 hours? - So now that we have ironed out the time period stuff slightly, let's discuss the behavior that hidden services, clients and HSDirs should inherit. This email is quite long already so I'm going to go with examples, instead of formal specification. However, this stuff needs to go formally in the proposal IMO, so any help in formalizing it would be great. + Hidden Service behavior: Example 1: Our hidden service boots up at 14:00 of TP#1. In this case, we are nowhere close to the overlap period, so the hidden service should just publish its TP#1 descriptor to the HSDir hash ring using SRV#1 (which at that point should be in consensuses as "shared-rand-current-value"). The hidden service might also want to calculate its overlap OFFSET (as specified in [TIME-OVERLAP]) and schedule a time callback for publishing its TP#2 descriptors. Example 2: Our hidden service boots up at 03:00 of TP#1. That's outside of the overlap period again, but this time the hidden service needs to use the SRV from "shared-rand-previous-value" because the SRV was rotated at midnight. Example 3: Our hidden service boots up at 09:00 of TP#1. That's inside the overlap period, so the hidden service should calculate its overlap OFFSET and compare it with the current time. If it has not passed, then we are in the exact same case as Example 2. If the overlap OFFSET _has_ passed, then the hidden service needs to act as Example 2, and _also_ publish its TP#2 descriptors to a second set of HSDirs using SRV#2. I think these are all the cases for the hidden service, but I would like to formalize this in a way that can be written in the spec. Particularly, I'm not sure how to formalize which SRV to pick at a given time point. + Client behavior My current intuition with regards to client behavior is that they should always fetch descriptors from the HSDirs of the _current_ time period. They should not concern themselves with the overlap stuff _at all_. The overlap system is there so that by the time the new time period starts, all the HSDirs have received the descriptors and are ready to help the clients. Clients should never notice the overlap stuff happening. For this reason I think we can remove this paragraph from the spec: When a client is looking for a service, it must calculate its key both for the current and for the subsequent period, to decide whether the next period's key is valid yet. What do you think? + HSDir behavior Currently the spec says the following: Hidden service directories should accept descriptors at least [TODO: how much?] minutes before they would become valid, and retain them for at least [TODO: how much?] minutes after the end of the period. After discussion with David, we thought of chopping off the first part of that paragraph and not imposing any such weak restrictions for accepting descriptors (see #18332). We still have not decided about the second part of that paragraph, that is how long descriptors should be retained after the end of the period. We currently think clock skew is the only thing that can bring clients to the wrong HSDir after the end of the period. Maybe an hour is OK? David suggested 12 hours. The current Tor is doing 48 hours... Any ideas? And this half-assedly sums up the behaviors of clients/HSes and HSDirs with regards to descriptor uploads and downloads. What is missing, and do you agree that parts of this should be in the proposal? - We should revert the torspec commit: "prop224: avoid replicas with the same blinded key" https://gitweb.torproject.org/torspec.git/commit/?id=8df8c0584392240aa8fecb… It adds a whole lot of complexity to prop224 with no clear security benefit against realistic adversaries. Furthermore, the time period and descriptor download/upload logic of Tor gets very complicated with it. I discussed this with teor and special and found it reasonable. - The randomized revision-counter logic should also be simplified or even removed: https://gitweb.torproject.org/torspec.git/commit/?id=01119bf1291a40aa309dfb… I haven't looked much into this yet. If someone has thoughts please let me know. - We should use fresh salt every time we rebuild the descriptor, but not for every replica: https://gitweb.torproject.org/torspec.git/commit/?id=01e865d592ffcbb67a0e66… - teor says we should revert the double hashing here, and just use tor's random API: https://gitweb.torproject.org/torspec.git/commit/?id=93f47f4f4e7614d4b3debf… peace

5 25

[RELEASE] Torsocks 2.2.0-rc1
by David Goulet 24 Jun '16

24 Jun '16

Hi everyone! I'm releasing a long overdue version of torsocks 2.2.0 release candidate 1. Unfortunately, some other platforms than Linux can break so please let me know either by email or using https://trac.torproject.org what broke. Source: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.2.0-rc1.tar.bz2 Sig: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.2.0-rc1.tar.bz2.… Here is the ChangeLog: https://gitweb.torproject.org/torsocks.git/commit/?id=bcf6ae8c122afff1cfc6a… Worth noting the new command line option to specify the SocksPort address and port of the tor daemon: -a, --address HOST Specify Tor address -P, --port PORT Specify Tor port Also, if you are still experiencing issues with some applications, let me know which one specifically and try to be as detailed as possible with your report. Finally, if anyone with OS X knowledge could check this bug, it would be of great help because this is kind of a show stopper for OS X users that I would like to fix before the stable release. https://trac.torproject.org/projects/tor/ticket/17980 Now is also a good time to speak up if you want something in this release. Cheers! David

3 2

Re: [tor-dev] Freenet + Onioncat: Is the traffic welcome?
by konstant＠mail2tor.com 23 Jun '16

23 Jun '16

[konstant] arma: Do you give this a thumbs up? https://lists.torproject.org/pipermail/tor-dev/2016-June/011108.html [arma] not necessarily? how much traffic is it? [arma] "just add more traffic" mostly hurts tor, alas [arma] since it doesn't really improve security, and it slows it down [arma] if we had a way to add more traffic in a way that helped, that would be grand [konstant] arma: I can't give an exact estimate without working metrics. Freenet has 10KiB/s minimum bandwidth requirement. Optimistically the max. number of nodes in Tor will be around a hundred [konstant] Does this land on the heavy side? [arma] konstant: so 1MB/s of traffic. that's not so bad really. if a few of those freenode nodes set themselves up as tor relays, it would balance out. [arma] the main rule is that if you're going to add traffic to tor, run some relays to match [arma] for hidden services, that's 1MB/s of traffic onto 6 places, so 6MB/s [konstant] I know the seednodes will have 24/7 uptime so they are good relay candidates [konstant] Imma post your responses on the dev ML for posterity

1 0

TUF Repository for Tor Browser
by bancfc＠openmailbox.org 21 Jun '16

21 Jun '16

In light of the technical obstacles that prevent packaging Tor Browser (see below), I propose operating a repository that relies on The Update Framework (TUF) [0]. TUF is a secure updater system designed to resist many classes of attacks [1]. Its based on Thandy (the work of Roger, Nick, Sebastian and others). The advantage of this proposal is that (Tor based distros and others in general) can finally retire the TBB downloaders and shed the maintenance burden. Also there is no need to re-invent secure download mechanisms when there is a project that already covers this. *** Rehash of previous discussions on the topic: The major reasons why TBB is not in the Debian repository: * The reproducible build system depends on a static binary image of (then Ubuntu) which runs counter to Debian policy. * TBB is based on Firefox ESR and not Iceweasel which also runs into the "no duplicate source package" policy of Debian. Reasons for unavailability of TBB .deb in the Tor Project APT repository: * The break neck speed of development * Its not easily packaged and the amount of effort needed is better spent otherwise. *** [0] https://theupdateframework.github.io/ [1] https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md

5 6

getting reliable time-period without a clock
by Razvan Dragomirescu 20 Jun '16

20 Jun '16

Hello everyone, I am working on a smartcard-based hidden service publishing solution and since I'm tying the hidden service descriptor to the physical smartcard, I want to make sure that the host is not asking the smartcard to generate hidden service descriptors in advance, to be used when the card is no longer inserted into the host/reader. The smartcard has no internal clock or time source and it's not supposed to trust the host it's inserted into, so I need an external trusted source that indicates the current time period. I'm not 100% familiar with the Tor protocol (minus the hidden service parts I've been reading about recently), so is there any way to get a feel of what the network thinks is the current time or the current time-period? An idea would be to fetch the Facebook hidden service descriptor or some other trusted 3rd party hidden service at a known address and see if the time period given to the smartcard is valid for that Facebook descriptor too. An operator could set up one or more trusted hidden services to match against the time-period (inside the smartcard) before it signs a given descriptor. Is there an easier way? I _think_ I can download the current consensus and check signatures on it (who signs it? how do I verify these signatures?), then check the valid-after / valid-until fields inside. The problem with that is its size, it's about 1.6MB - a bit hard for the card to digest that much but doable in small chunks. Any hints would be appreciated. Thank you! Razvan -- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL

3 3

Onionoo AS Name
by Gareth Llewellyn 19 Jun '16

19 Jun '16

I've noticed a lot of ASNs are no longer showing their whois descr field in the Onionoo output. Is this expected?

3 4

[GSoC] CONIKS for Tor Messenger - 2nd status report
by Huy Vu Quoc 18 Jun '16

18 Jun '16

Hi everyone, This is my second status report on the CONIKS for Tor Messenger project. During the last two weeks I’ve been working on several things: 1. Continue implementing the Merkle prefix tree module and fix issues based on comments from Marcela, Arlo and Ismail. These are still some works need to be done including: - Using an abstract cryptography library [1] instead of specific primitives - Add hooks for storage backend [2]. Currently, I’m discussing with my mentors (Marcela and Arlo) about how to do it. 2. Spend time to studying current implementation of coname/dename [3, 4]. It would help me so much when I go to implement the CONIKS library (e.g., the server struct, server config and http front) 3. Work on some other modules of libconiks library (HTTP server and server config) 4. Implement the Twitter bot for registration protocol. I used a 3rd client library for Twitter APIs [5]. This bot uses the Twitter streaming APIs to listen for new coming registration message, as described in the account verification protocol. The source code of (3) and (4) is not pushed to the github repo yet since I’m still doing on these modules and they are not ready for integrating into the library. My focus on two next weeks is mainly to implement the registration protocol and continue refining the Merkle tree library. Best, Huy — [1] github.com/dedis/crypto/ [2] https://github.com/coniks-sys/libmerkleprefixtree-go/issues/4 [3] https://github.com/yahoo/coname [4] https://github.com/andres-erbsen/dename [5] https://github.com/dghubble/go-twitter

3 3

[GSoC16] Expand Nyx - Status Report 2
by Sambuddha Basu 18 Jun '16

18 Jun '16

Hi everyone, This is the second status report for the 'Expand Nyx' project for GSoC 2016. I have been working on the following things: * Updated --log commandline argument and startup.events. Previously, arcane strings were entered for --log commandline argument and startup.events. This has now been replaced by event names separated by commas. * Added the event description for event selection dialog box. Colors have been added and tests have been updated for the selection dialog box too. During the next week, I will be working on getting back the interpreter panel from the last release(1.4.5). Hope everyone has a fun weekend! Sambuddha

1 0

[GSOC 16] Ahmia status update #2
by Ismael R 17 Jun '16

17 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi everyone, I'm working on ahmia.fi, the hidden service search engine and you're reading status update #2. Since last time, here is what I've been working on: Improve project structure, code quality and documentation The three repositories I talked in status update #1 are ready [1][2][3], each one with an installation guide. I used static analysis to improve code format, remove duplicate code, and fix some bugs. Project automation - - For each push, code is automatically tested and analyzed with travis-C I. - - Requires.io tracks vulnerable or outdated requirements. - - Landscape.io estimate code quality on each push. Regroup all data to elasticsearch To improve search quality, more data attributes will be used, some of which are not yet in our index. We need to crawl more attributes and move search logic from Django to elasticsearch. During the next two weeks, I will focus on the django part. See you in two weeks! :) Ismael [1] https://github.com/ahmia/ahmia-site [2] https://github.com/ahmia/ahmia-crawler [3] https://github.com/ahmia/ahmia-index -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXZFpRAAoJEKhDKCOT41OSOxQP/0SpRWA5N6gQqolGWq534/It L1pMQpDlB56cd8a4h7XYdoxaYeC8lkfwT9K9LNGfLqraN1V+pK5Jay3rDiZ5R85W fFCcOlhrOkTP/302RBRFmQmHzR6/LeW7y2Hmn9IQhy4DcLUj5W/9+EKiwDjMOU/A ilmdU0D222m41lQlrBFMCt1ATJkBBgxsQMy40Cu/XSmVjAQE7vDk1t3NT1txG37T /1LlDmjK5kH8zGCxNwSvoPzvrQyCltT65xvO3WJx0HS+p1cQf6wBkHBYPob3Or+2 YdXnv/scQ+CKEkuJQvBOigPyK7e2fKu2O+RIYHEaycQtePfRzNSwW5TITysVL9Az +DHoBc+mK28Q7A1vNSc1jlcc4nckHH++WCiLx3o52HuuiVGnsEtzkEMKT88NVB74 UWmpW03PjqPT8C0Ntru78FiiBmnoHLvSm5i3rV9Ge2lNufBXTsG0hd5yFeVkmfdN BAtrrW1DMtiAvb8SARsYnYrcOwCnpKUeg9B5idpE9ZloWEj83PHk0o+5sL1zF3Oh i4l2Hc7RdHtHmsfV/yeexhFsVG6nBbIi0UHtDgyFwLLGq3+NQTkH5j0YWB3rIQiV MEIBIGq/9ltQ3+/T1ha+K0Jn6I4KO06c6gezvTHqLO8lAvsGRpDsOf3tED2IiIC8 hI4pcbGoep0CG+Xeps/d =Xri8 -----END PGP SIGNATURE-----

1 0