- tor-dev - lists.torproject.org

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 21 Jun '16

21 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 19 Jun '16

19 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

[GSoC] Tails Server - status report 3
by segfault 17 Jun '16

17 Jun '16

Hi everyone, this is the third status report on the Tails Server GSoC project. I had to omit the previous report because personal difficulties were getting in the way. So here is what I achieved in the last four weeks: * Revamp the GUI * Replace the status panel with a config panel * Add a loading window * Implement the persistence feature * Refactor the code * Many more changes in the code, you can look at my commit messages if you want more details * Keep discussing the design of the GUI on the Tails-UX mailing list The prototype is actually working now. The persistence feature works without dirty hacks now, because anonym kindly implemented a new feature in Tails' persistence (regular files can be bind-mounted now). Because Tails Server now relies on this feature, it will only work properly in this patched Tails version. I will integrate Tails Server in this branch and send a link to a nightly ISO image on tor-dev and tails-dev in the next few days, so you can test it. Next up is some more polishing of the GUI and writing a short documentation to be able to do some initial user tests. And then there are still a lot of features to implement, like autostarting the services, onion address regeneration, client authentication (not necessarily in scope of the GSoC, but I want it anyway), and many more. And I will have to refactor the code some more. Cheers!

1 0

Re: [tor-dev] [GSoC 2016] Orfox - Report 2
by Nathan Freitas 17 Jun '16

17 Jun '16

On Thu, Jun 16, 2016, at 10:37 PM, Tom Ritter wrote: > On 16 June 2016 at 18:45, Amogh Pradeep <amoghbl1(a)gmail.com> wrote: > Is a code audit the most efficient and reliable way to look for proxy > leaks? (At least at this stage?) I think he means a few things by this, or at least we have a few tasks underway: - mentor (me) reviewing code quality and implementation choices for how proxy features were added - inspection of esr45 Android Java code for new network code and other potentially leaky / deanon features - review of tor browser, noscript and other mobile relevant extensions for portability to android > I would do dynamic analysis by setting up a bridge and a proxy, > exercising lots of different functionality of the app (HTTP, HTTPS, > FTP, update checking, safebrowsing disabling/enabling, extension > installation, extension update checking, extension calls to third > party APIs, etc), and looking for any traffic not going to the single > bridge configured. We use NoRoot firewall on Android for doing this in a quick manner. It is like LittleSnitch. Thanks for the feedback Tom!

1 0

[GSoC 2016] Orfox - Report 2
by Amogh Pradeep 17 Jun '16

17 Jun '16

Hey guys, This is my second status report for GSoC 2016. I’ve finally managed to rebase things to ESR 45.2.0 :D [0]. But unfortunately, I think that what it is build on is unstable, so we don’t have an ask ready yet. I will continue to work on this, and hopefully have a successful build soon. Next up is a code audit. Once we have a stable application built on ESR 45, I can move on to the code audit phase. In this phase, I would go through the android code, looking for all the network code, and making sure that it is proxied fine. Hope you guys have a fun weekend. Best, Amogh Pradeep amoghbl1(a)gmail.com [0] https://github.com/amoghbl1/tor-browser/tree/orfox-tor-browser-45.2.0esr-6.…

2 1