- tor-dev - lists.torproject.org

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

[GSOC16] Fingerprint Central - Cookies and localStorage
by Pierre Laperdrix 30 Jun '16

30 Jun '16

Hello everyone, I know the next status report is not due until next week but I wanted to get some feedback on how I use cookies and localStorage on FP Central. Right now, due the very short lifespan of cookies in the Tor browser, I don't use cookies as an identification mechanism but as an expiration/anti-pollution mechanism. Here is how it works: - For users without JavaScript, I put a cookie the first time a fingerprint is sent. This means that in the same session, no new fingerprint from the same user will be stored if he or she wants to see his or her own fingerprint again. If the user generates a new identity, he will be able to store a new fingerprint since no cookie will be present. - For users with JavaScript, I add a cookie when the test suite is run and I use localStorage to store data generated during the collection process. When the user sees his complete fingerprint with the percentage for each attribute, all the values are stored in localStorage. If the user gets back to the FP page page, it won't have to contact the server and the fingerprint will appear instantaneously by getting the stored copy from localStorage. The presence of data in localStorage prevents the user from sending his fingerprint a second time. The presence of the cookie acts as an expiration mechanism. If the cookie is still present, I consider the data in localStorage to be valid and the user cannot perform the collection process again. If the cookie has expired, I remove data present in localStorage and allow the user to execute the whole process again. I don't know if my approach is a good one but I wanted to use what is available to me in the browser to prevent too many fingerprints from being stored and to lessen as much as possible the server load. If anyone has suggestions on my use of cookies and localStorage, I'll gladly take them. Now, what I'm not really sure is: what about users who want to play with their browser and see the modifications done to their fingerprint? The way the site is built now prevents that. There are no buttons to force the collection process again. I see two alternatives here: add a "Force fingerprinting" button even though the database could be polluted or add a sort of "playground" webpage that is not connected to the database where the user can rerun the test suite as many times as he wants. Hopefully, if everything goes well on my end, I'll be able to launch a beta version of the website next week. We could see from there if everything is working well and if the limitations imposed on users are not too important. Have a great week-end, Pierre

3 2

HSFETCH fails on basic auth services
by Razvan Dragomirescu 30 Jun '16

30 Jun '16

Hello everyone, I seem to have found an issue (bug?) with the controller HSFETCH command - I can't seem to be able to fetch hidden service descriptors for services that use basic authentication. Tor appears to want to decrypt the introduction points for some reason and also fails to look at the HidServAuth directive. Connections (via SOCKS proxy for instance) to said service work fine, so Tor is configured correctly, but HSFETCH fails and Tor outputs this in the logs: *Jun 29 20:08:53.000 [warn] Failed to parse introduction points. Either the service has published a corrupt descriptor or you have provided invalid authorization data.* *Jun 29 20:08:53.000 [warn] Fetching v2 rendezvous descriptor failed. Retrying at another directory.* Is this a known issue? Is there another way to fetch the descriptor of a hidden service? I really don't want it to be published since I'm rewriting it anyway, but I need to fetch it somehow. I can use "PublishHidServDescriptors 0" to stop it from publishing the service at all but I have no idea how to fetch it from the local cache. Any controller commands for that? To summarize - HSFETCH appears to fail for hidden services with basic auth and I couldn't find a way to obtain the hidden service descriptor from the hidden service machine itself before publishing. Any advice would be appreciated. Thank you, Razvan -- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL

2 3

is the consensus document unpredictable / unique?
by Razvan Dragomirescu 29 Jun '16

29 Jun '16

Hello everyone, I couldn't find a detailed description of the Tor consensus, so I'm checking that my understanding of it is correct. Basically, would it be correct to assume that the consensus document (or a hash thereof) for a date in the future is an unpredictable value that will also be unique to all nodes inquiring about it at that time? I'm thinking of using a hash of the consensus document - like http://171.25.193.9:443/tor/status-vote/current/consensus - as a descriptor cookie in a hidden service. This way, an attacker cannot generate or publish a hidden service descriptor for the future (one with a correct cookie). A client can fetch the consensus at the time it wants to connect, hash it, then use that as the descriptor cookie to determine the correct descriptor id and decrypt the introduction point list. Does anyone see any issues with this? In my project, the hidden service private key is on a smartcard, so it can't be copied, you can only ask the smartcard to sign something with it for you - and I'm trying to prevent an attacker from generating hidden service descriptors in advance,to be used without the smartcard. If future descriptors depend on an unpredictable future value (the hash of the consensus at that time), an attacker can only generate descriptors for past and current time periods. Thank you, Razvan -- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL

5 14