tor-dev

tor-dev@lists.torproject.org

3581 discussions

Re: [tor-dev] [GSoC] CONIKS for Tor Messenger - status report #3
by Huy Vu Quoc 03 Jul '16

03 Jul '16

Hi everyone, This is my third status report on the CONIKS for Tor Messenger project. These are things that I have been doing in the last two weeks: 1. Continue implementing the Merkle prefix tree module. Currently, the STR source code are under review. This module takes a lot of time since it is probably the biggest components. There are a lot of discussions over the development to make sure everything is on right track (e.g. the proof of absence …) 2. Continue working on libconiks library. This library currently consists of several modules: - CONIKS server construction from config file - TLS socker listener - Request handler I submitted a pull request for the registration implementation [1]. 3. Registration implementation (Tor Messenger-specific module). This work includes both server & client modules: - Server modules: the registration bot acts as a proxy between the client and the CONIKS server. Account verification is performed by comparing the fingerprint (base64 encoded) included in registration request and the DM sent to CONIKS twitter account. - Client modules: the client module consists of a preferences UI and coniks module which sends the request. Currently, the policies setting of each user is stored in a sqlite database. (source code of client module is pushed to [2]) - The server will return base64 encoded string of the temporary binding (TB). This would be changed when we start working on monitoring & key lookup modules. (i.e. returning more data along with TB) - The verification message (Twitter direct message) format is: ?CONIKS?b64Encode(fingerprint) The registration protocol can be illustrated as follows: Client - Registration bot (listening on port 3000) - CONIKS server (listening on port 3001) 1. Client sends a DM to CONIKS Twitter handle 2. Client sends a registration request to registration bot 3. Registration bot verifies the request 4. If it is valid, the bot forwards the request to the CONIKS server 5. The server returns a TB for the requested user 6. The bot forwards the TB to the client. The source code is available for review [3]. After some discussions with my mentors (Arlo and Marcela), we also came up with an improved account verification scheme. In the original proposal, the client would send the public key to the registration bot and the signed public key to the twitter handle. However, that doesn't always make much sense, since the Merkle tree really stores an opaque blob, not just a key. The verification protocol could be simplified by letting the client send the fingerprint to both registration bot and the twitter handle. Then we can do a comparison these two messages for the verification. The new verification scheme seems more effective in case of Tor Messenger and OTR protocol. Best, Huy — [1] https://github.com/coniks-sys/libconiks-server-go/pull/3 [2] https://github.com/c633/ctypes-otr/tree/coniks-registration [3] https://github.com/c633/tor-messenger-coniks/pull/1

1 1

[GSOC 16] Ahmia status update #3
by Ismael R 03 Jul '16

03 Jul '16

Hi everyone, I'm working on ahmia.fi, the hidden service search engine and you're reading status update #3. Since last time, I've been moving forward with the django "rewrite". A little context: The current main goal of the project is too regroup all data related to search into our elasticsearch index (sites content, tor2web stats) so we can use it to give better search results. Since I'm focusing on the django part, I'm removing a lot of search logic which is now done by elasticsearch. For instance, banned websites will be store in our main index and elasticsearch will filter them before returning search results. This is a different behaviour from now, where banned websites are stored in a PostgreSQL database and filtered at the django level. I'm also taking advantage of this rewrite to accomplish the following goals: - Compartimentalize what should be in apps : I plan to do three apps : search, stats and api - Remove deprecated code/files - Remove every linter error/warning : I worked on this one, but some warning could not be remove without a rewrite. - Update django version : We are using Django 1.7 which is not supported anymore. - Use a more coherent url scheme (while keeping retro-compatibility) - Use a more coherent API behaviour (also while keeping retro- compatibility) - Write more tests to verify correctness After this rewrite, we will have three apps in our Django website: Search will focus on pages related to search results, querying our index to get results. It will be later improved with !bang syntax or some other keywords to specify a date range, a specific .onion website, etc. Stats will focus on statistic visualization (most popular .onion, etc). It could be later improved with a "Ahmia trend" interface to view searches over time. Api will focus on the API part of the website. I have a couple ideas but will discuss them in a later report. During the next two weeks, I will continue my work on this rewrite. See you in two weeks :) Ismael

2 1

[GSoC '16] Exitmap Improvements Project - Status Report #3
by Mridul Malpotra 02 Jul '16

02 Jul '16

Hi everyone! For the past week, I have shifted my focus to the main sub-project of continuous scanning in Exitmap. What we'll be trying to achieve is having the Exitmap utility running in the background and running the various modules. This report recounts one week worth of work since my 2nd report was on 26th June. Work done: --------------- 1. Wire-framed the structure of how continuous scanning will work. Major components that will be focused on are (a) Periodically updating the network consensus to scan for new or previously invisible exit nodes for malicious behaviour, (b) A mechanism that keeps a close eye on some exit nodes while does not care much for nascent exit relays or well established guard nodes, and (c) Add as much randomization as possible for these scans to make it more difficult for a malicious exit relay to distinguish regular traffic from scanner activity. 2. IRC meeting with my primary mentor Philipp Winter (phw) to discuss some of the features and how will go about implementing them. Some points arrived at from the discussion: a. Need to create an asynchronous element for periodically fetching consensus data and to integrate the element with the existing Exitmap functionality. b. Find a way to update the Tor micro-descriptors and use new consensus for the modules. I still need to find a way to programmatically force the Tor client to update its consensus at the moment specified. Damian Johnson (atagar) advised me to use the FetchDirInfoEarly parameters that helps. If anyone has any more information about this, it would help a lot. I will be scouring through the control-spec for the same. c. Create an algorithm to give more weightage to some exit nodes from consensus depending on what the criteria is. We need to come up with a selection mechanism that selects nodes visible in the say 0-24 hours time frame but is not a node that has just come or has been around the Tor network for some time. Some research still needed on this aspect. Have a great weekend everyone! -- Mridul (mtyamantau) ============================= PGP keyID: 0xb716e33ab6d0a653

1 0

Improving hidden services on mobile phones
by George Kadianakis 02 Jul '16

02 Jul '16

Hey list, just for the record, during the past weeks we've been discussing how to improve hidden services hosted on mobile phones in this here trac ticket: https://trac.torproject.org/projects/tor/ticket/16387 Discussion has also spilled over ticket #18620. The discussion also has a design aspect as some suggested improvements would require protocol changes, hence I'm informing this list in case some people are interested in jumping in and participating. For example, for some use cases it might make sense to have an HS -> IP cell INTRODUCE2_ACK that acknowledges the receipt of INTRODUCE2 cells, so that the IP knows that the intro circuit is active and the HS received the introduction request before sending out its own INTRODUCE_ACK to the client. That's because mobile hidden services are unstable and their intro circuits break frequently, causing reachability issues. See the second part of https://trac.torproject.org/projects/tor/ticket/16387#comment:8 for more background. Have a good day :)

3 2

[GSoC16] Expand Nyx - Status Report 3
by Sambuddha Basu 02 Jul '16

02 Jul '16

Hi everyone, This is the third report for the 'Expand Nyx' project for GSoC 2016. I have been working on the following things since the past 2 weeks: * Added the basic interpreter panel. The interpreter panel now, internally uses Stem's interpreter panel. * Added help options to the interpreter panel. Appropriate error is shown when non-recognizable commands are entered. * The ANSI output from Stem's interpreter panel is now formatted to show appropriate color and attributes. * A scroll-bar has been added to the interpreter panel. The interpreter panel code that was added by me, can be seen at: https://github.com/sammyshj/nyx/pull/11 In the next weeks, I will be working on adding the history validation and tab completion for the interpreter panel. Hope everyone has a fun weekend! Thanks, Sambuddha

1 0

[GSoC] Tails Server - status report 4
by segfault 02 Jul '16

02 Jul '16

Hi everyone, this is the fourth status report on the Tails Server GSoC project. First off: There are nightly images of Tails with integrated Tails Server available for download [1]. Some notes if you want to test it: - Installation of the first service will take several minutes, because the APT package lists have to be downloaded - If you boot the image in a VM, the loading spinners won't spin. I couldn't yet figure out why. - The Gobby Service's status does not turn to "stopped", it remains in "deactivating" [1] http://nightly.tails.boum.org/build_Tails_ISO_feature-5688-tails-server/bui… Here is what I did in the last two weeks: * Work on the GUI * Implement three different approaches to edit the options. Discuss each of them on the tails-ux mailing list. Start conducting short user tests to get some data on which approach provides the best UX. * Implement a status line (this replaces the loading window I implemented previously) * Group the options * Rework the displayed connection info * A lot of smaller improvements * Use stem to create ephemeral hidden services instead of editing torrc * Implement reset of the onion address * Make Gobby Server work * Integrate Tails Server into Tails * Fix a lot of issues Next up is (still) writing a short documentation for the upcoming user tests. Then I will begin to conduct the user tests. Also, the autostart and client authentication features are still not implemented. And I plan to include some doxygen-like specification in the code. Cheers.

1 0

RelayAwards - incentives
by nusenu 01 Jul '16

01 Jul '16

> - We started this > website because we believe that competition can make more operators > improve their relay by following best practice. This would make the > whole Tor-network better if we have straight guidelines. > https://www.relayawards.com/ If it is about competing operators then you should aggregate an operator's tor instances not care to much about single tor instances of a given operator? You might just team-up with http://tor-roster.org/ Creating incentives for a high uptime would create incentives to run relays insecurely (never upgrade, never reboot, run vulnerable software longer). I wouldn't give away awards for low uptimes either - just leave it out of the equation? With over 94% CW [1] being routed by Linux relays, why is it good to run more Linux relays? I'd say create incentives for non-Linux relays. [1] https://github.com/ornetstats/stats/blob/master/o/os_share.txt How about anti-incentives? -5 for relays @ OVH added after a certain point in time?

1 0

[GSOC16] Fingerprint Central - Status report n°3
by Pierre Laperdrix 01 Jul '16

01 Jul '16

Hi everyone, Here is my third status report for my GSOC project. https://github.com/plaperdr/fp-central 1 - Following my last report, I've added the following elements to Fingerprint Central: - A page that detects the current level of the security slider of the Tor browser - A page that looks if the current fingerprint is "acceptable" compared to the Tor guidelines. This feature will evolve in the future to be more complete and to provide more feedback to users. - Support of users without JavaScript - Improvements of the code of the main FP page so that it reduces server load (by storing locally the information of the current fingerprint) I've also added support of Promises so that computation-heavy tests can be run without blocking the whole collection process. The added test on the AudioContext API is the first one to make use of that feature. 2 - We will launch a beta next week of FP Central to get early feedback on the project. Any ideas and suggestions will be welcome so that the website will be the best it can be for both users and developers. The server is online but I'm still making some final tweaks and bug fixes so that the launch will be smooth. I'll send an email early next week to this mailing list to inform everyone when it'll be ready. My goal in the next two weeks is to launch the beta of the website and start working on a great statistics page along with a more complete version of the "acceptable fingerprint" page. Have a great week-end, Pierre

1 0

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

30 Jun '16

On Thu, Jun 30, 2016, at 03:49 PM, Spencer wrote: > > Amogh Pradeep: > > we have a new logo for Orfox :D > Is there a reason for the malalignment of the stroke? ... because perfection is boring? ... because I had five minutes to do it? ... because there is a secret hidden meaning? You choose! :) Otherwise, will look into it. > And that one permission 'Download files without notification', or is > this out of the scope of your work? Is there a ticket or thread on this?

2 1

[GSoC 2016] Orfox - Report 3
by Amogh Pradeep 30 Jun '16

30 Jun '16

Hey guys, These are the things that I’ve done in the past couple of weeks. 1) Finish the network audit. I’ve managed to comb through the Firefox for android code to find all the network code in the java layer. [0] The good news here is that the Java layer has now been reduced to using 2 network libraries instead of 3. This is a result of one of our patches going upstream. [1] 2) Stable build with ESR45. I’ve finally managed to get Orfox building fine on ESR45. APK [2] There are still a few quirks that we need to work out, after which we should be able to get an official build out. This APK is highly experimental at the moment, please use it just for testing purposes only. 3) Conversation with Mozilla team. I had a nice chat with mozilla about the java network code in firefox. [3] To try to find what might be useful for them as well, this way, we could send more code upstream. And it also helps with judging what we must do next. 4) Orfox Logo update. Thanks to Nathan, we have a new logo for Orfox :D [4] We had to replace our old one as it looked too much like Mozilla’s fox. Best, Amogh Pradeep amoghbl1(a)gmail.com [0] https://trac.torproject.org/projects/tor/ticket/19519 <https://trac.torproject.org/projects/tor/ticket/19519> [1] https://bugzilla.mozilla.org/1169421 <https://bugzilla.mozilla.org/1169421> [2] http://people.torproject.org/~amoghbl1/fennec-45.2.0.en-US.android-arm.apk <http://people.torproject.org/~amoghbl1/fennec-45.2.0.en-US.android-arm.apk> [3] http://logs.glob.uno/?c=mozilla%23mobile&s=28+Jun+2016&e=29+Jun+2016 <http://logs.glob.uno/?c=mozilla#mobile&s=28+Jun+2016&e=29+Jun+2016> [4] http://imgur.com/Ys502Bx <http://imgur.com/Ys502Bx>

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev