- tor-dev - lists.torproject.org

Adding depictor/stem to Jenkins
by Tom Ritter 05 Jul '16

05 Jul '16

Hi all, Hoping someone can help me out here... I'd like to add a job to jenkins that runs the depictor command (`python write_website.py`) whenever a commit is made to the dev repo master branch[0] OR stem's master branch. (If I could only have one I'd pick stem's.) Historically, one of the reasons consensus-health has lagged a little bit has been because in the past there was some tiny change in Stem that wound up breaking it. I don't think that's happened lately, but it's caused me to be conservative about upgrading stem, and usually the changes I need are the latest one added to master. A jenkins job would give me a bit more confidence and enable a bit more proactivity on fixing it for breaking changes. Who runs jenkins? What would I need to do to set this up? The good news is there's only three commands needed to go from zero to index.html: git clone https://git.torproject.org/user/tom/depictor.git cd depictor git clone https://git.torproject.org/stem.git ./write_website.py -tom [0] https://gitweb.torproject.org/user/tom/depictor.git/

2 2

A meta-package for Pluggable Transports?
by Nima Fatemi 05 Jul '16

05 Jul '16

It’s currently difficult for bridge operators to keep up with the changes in pluggable transports world. You’ve to be following tor development and censorship-war very closely to know which transport is needed currently and how to run them. There are many people who are still running vanilla bridges thinking they’re helping people in censored networks. Unfortunately those bridges are not anyone any good while burning operator’s resources. After some discussion on #tor-project a little while ago, the idea of having a meta-package that includes all or the most recent transports came up. Where people would install this meta package and it would automatically take care of the required steps to get the latest obfsproxy and set it up. From a UX perspective, ideally you’d set up a bridge with small and consistent steps like this: $ sudo apt-get install tor-bridge $ tor-bridge —-setup OR $ tor-bridge-setup and then it will automatically get the most recommended PT (eg obfs4), tor itself (if not installed), config your torrc, do a reachability test, publish the bridge to bridgdb automatically and give you the result in stdout: # Congrats! your bridge is up and running on $port # Your bridge is published in BridgeDB. # Thanks for fighting censorship! Additionally we can have more flags for different transports, ip, port and so on. For example if you want to run obfs4proxy on an specific port and not publish it, I imagine running something like this should get you there: $ tor-bridge-setup —-private —-obfs4 —-ip 1.2.3.4 —-port 5000 # Congrats! your bridge is up and running on port 5000 # You have chosen to not to publish your bridge. Users would need to manually copy and paste the following line in their Tor Browser to use your bridge. # # bridge obfs4 1.2.3.4:5000 C73ADBAC8ADFDBF0FC0F3F4E8091C0107D093716 cert=gEGKc5WN/bSjFa6UkG9hOcft1tuK+cV8hbZ0H6cqXiMPLqSbCh2Q3PHe5OOr6oMVORhoJA iat-mode=0 The purpose of this email is to see whether this is a good approach (if not, how can we improve it), and what is needed to move towards it. Feedback from everyone, specially packagers and relay operators are encouraged and welcome :) Best, -- Nima 0X58C4B928A3E218F6 | @mrphs "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall

5 9

Re: [tor-dev] A meta-package for Pluggable Transports?
by Valentin Sundermann 05 Jul '16

05 Jul '16

> I've heard that the Chinese government tests suspected bridges by > attempting to connect to them and seeing if they respond to the Tor > protocol. Whether China is actually doing this or not, it would not be a > terribly difficult thing for any competent censor to do. It was probably the talk from Philipp Winter at the 32c3. Just for reference on this list or people who find it interesting. I think there is no general answer for what should be the default config/setup for a bridge. Maybe a (ncurses) menu at the install would be the best. The menu could inform new bridge operators about what is good/bad and why or even what types of proxies are currently needed more. Or provide at least a link to a wiki article (which should be written :)) [1] https://media.ccc.de/v/32c3-7196-how_the_great_firewall_discovers_hidden_ci…

1 0

Fingerprint Central - Testers needed!
by Pierre Laperdrix 05 Jul '16

05 Jul '16

Hi everyone, As part of my GSOC project, the beta for Fingerprint Central is finally live! Here is the link: https://fpcentral.irisa.fr For the moment, we are interested in testing the core feature of the project which is the collection of fingerprints. Other features are in development and will be added when they are ready (notably, the statistics page). There are two main pages available now: - "View my fingerprint": On this page, you can execute the tests that have been added in Fingerprint Central. If you have JavaScript enabled, you can use the Dashboard to see the generated data and review them before you send it to our server. The "%" column indicates the percentage of collected fingerprints that share the same value as you. - "Tor": This page will give you several advice related to Tor guidelines and will try to detect the level of your security slider. We are interested in feedback and bug reports! If you feel something is missing or is not right, tell us so that we can improve the website. Unfortunately, we don't have data to correctly kickstart the database so the percentage shown to the first users won't be really interesting. Thanks in advance for your help! Pierre

1 0

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

[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 29 Jun '16

29 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

[GSoC '16] Status Report #2 - Exitmap Improvements Project
by Mridul Malpotra 27 Jun '16

27 Jun '16

Hey everyone. This is my second status report for the Exitmap improvements project. These 2 weeks, I was building up on the browser automation aspect to allow for browser interactions on Exitmap scans. These will better help disguise scanner activity against malicious exit nodes that might not act like an adversary when they detect scanner-like behavior in the client. Work and details: ----------------------- 1. I am using the Selenium WebDriver Python bindings to help in simulating browser actions. Have implemented some simple actions in Selenium and have also taken inspiration from the Tor Browser Selenium library suggested by the community. 2. Have included actions like opening a random number of links on the webpage in the same page, new tab or another window. Tried to get clickable elements of a webpage but facing some issues with dynamic pages where buttons do not enabled instantly. 3. Added browser_simulation.py that allows for a module to import the functions use the simulate() function with the intended URL to performs these operations. Some problems in these functions with some websites. Could be due to dynamic content. Needs to be fixed. Problems faced: ---------------------- 1. Major issue that I am facing is with the multiple invocations of the module for every exit node. The asynchronous calls are throttled due to the more serial Selenium calls to the TBB driver. I have not found a working solution for this as of now, which makes the tests running with browser automation to be much slower. 2. For some operations like opening tabs, I could not find defined library calls, leading to more hackier ways to complete these operations. This often leads to unexpected behavior and needs to be fixed. Future plans: ----------------- As continuous scanning is more important toward the project, I will be focusing on that for the moment and revisiting browser automation after I complete the former. My next report is due on 1st July. I also have submitted the report a week late due to unexpected complete disconnect from internet in the area I was at that moment for 6 days. This caused my work to stop for some time and I apologize for the irregularity. Immediately having shifted to a metropolitan city, I will ensure my reports will now be on time and work will progress without hindrance. Regards, -- Mridul ============================= PGP keyID: 0xb716e33ab6d0a653

1 0

TorBirdy 0.2.0: Sixth Beta Release
by Sukhbir Singh 27 Jun '16

27 Jun '16

We are pleased to announce the sixth beta release of TorBirdy and the first in the 0.2 series: TorBirdy 0.2.0. All users are encouraged to upgrade as this release fixes numerous security and privacy issues. Notable changes include fixing local timestamp disclosure in the date and the message-ID headers, as detailed in tickets #6314 [0] and #6315 [1]. The patch for sanitizing the date header is shipped [2] with TorBirdy. The patch for the message-ID header was submitted upstream [3] to Mozilla and merged in Thunderbird 45, and it is therefore recommended that you upgrade to Thunderbird 45 if possible. There are currently no known leaks in TorBirdy but please note that we are still in beta, so the usual caveats apply. If you are using TorBirdy for the first time, visit the wiki [4] to get started. Other changes in this release include: 0.2.0, 27 Jun 2016 * Bug #6314 [5]: Prevent local timestamp disclosure via Date header * Bug #6315 [6]: Prevent local timestamp disclosure via Message-ID header * Bug #13721 [7]: Fix usage of wrong locale * Bug #17426 [8]: Allow configuration of default email protocol * Bug #15459 [9]: Add support for deterministic XPI generation * Bug #11387 [10], #13006 [11]: Fix non-standard EHLO argument * Bug #17118 [12]: Allow manual account configuration for Gmail with OAuth2 * Bug #19031 [13]: Add and audit support for RSS reader * Bug #7847 [14]: Audit and update support for NNTP * Bug #10683 [15]: Update Thunderbird UI to reflect TorBirdy's state * Bug #19330 [16]: Set secure defaults for outgoing mail servers * Removed compatibility for older versions of Thunderbird and added support for Thunderbird 37+ * Added support for automatic configuration of Riseup email accounts * Updated various privacy and security settings (see commit 2bdeffbb [17] for a list of the changes) * Update translations for current languages Many thanks to Arthur Edelstein and the Tails Developers for this release! We offer two ways of installing TorBirdy -- either by visiting our website [18] (GPG signature [19]; signed by 0xB01C8B006DA77FAA) or by visiting the Mozilla Add-ons page [20] for TorBirdy. Please note that there may be a delay -- which can range from a few hours to days -- before the extension is reviewed by Mozilla and updated on the Add-ons page. (Packages for Debian GNU/Linux will be created and uploaded shortly.) [0] - https://bugs.torproject.org/6314 [1] - https://bugs.torproject.org/6315 [2] - https://gitweb.torproject.org/torbirdy.git/commit/?id=bfa822de6071e894dad3d… [3] - https://bugzilla.mozilla.org/show_bug.cgi?id=902580 [4] - https://trac.torproject.org/projects/tor/wiki/torbirdy [5] - https://bugs.torproject.org/6314 [6] - https://bugs.torproject.org/6315 [7] - https://bugs.torproject.org/13721 [8] - https://bugs.torproject.org/17426 [9] - https://bugs.torproject.org/15459 [10] - https://bugs.torproject.org/11387 [11] - https://bugs.torproject.org/13006 [12] - https://bugs.torproject.org/17118 [13] - https://bugs.torproject.org/19031 [14] - https://bugs.torproject.org/7847 [15] - https://bugs.torproject.org/10683 [16] - https://bugs.torproject.org/19330 [17] - https://gitweb.torproject.org/torbirdy.git/commit/?id=2bdeffbb [18] - https://dist.torproject.org/torbirdy/torbirdy-current.xpi [19] - https://dist.torproject.org/torbirdy/torbirdy-current.xpi.asc [20] - https://addons.mozilla.org/en-us/thunderbird/addon/torbirdy/ [Also on https://blog.torproject.org/blog/torbirdy-020-sixth-beta-release] -- Sukhbir

1 0

Help complete the list of official & community projects
by Nima Fatemi 27 Jun '16

27 Jun '16

Hi there, I'm working with some folks to compile a list of most active official and community projects we have. There are some projects listed on our volunteer page[1] but I'm not confident if the list is complete or even up to date. Please have a look at that page and let me know if your project is listed and it's not up to date, and definitely let me know if it's not listed at all. So if you've recently wrote a Tor library in a language only 5 people on this planet know about, this is a good chance for you to let us know of your project. :) Here's the information I need from you: Name of the project, along with a paragraph explaining the significance of the project and why it matters. Link to the project, and name or the handle of the maintainer. Examples: ====================================================================== ## Stem Stem is a Python controller library for Tor. With it you can use Tor's control protocol to script against the Tor process. https://stem.torproject.org/ maintainer: atagar ## OONI A free software, global observation network for detecting censorship, surveillance and traffic manipulation on the internet. https://ooni.torproject.org maintainer: ooni-team ====================================================================== [1] https://www.torproject.org/getinvolved/volunteer.html.en#Projects Alternatively we can create a new wiki page just for this projects, until #16576 is resolved. Except I'm only looking for active projects at this point. Happy Friday! -- Nima 0X58C4B928A3E218F6 | @mrphs "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall

8 7

RB Trees
by U+039b 25 Jun '16

25 Jun '16

Hello! I had a discussion with David Goulet about RB trees [0]. More particularly about the usage of RB trees for some Tor operations like [1] or HSDir cache. David said that Nick wants to use a FreeBSD implementation - is this one[2]? If it is, I think it could be hard for new contributors like me to maintain/write/debug code using it. Since inline functions are as fast as macros [3], is it conceivable to use functional implementation instead of macro implementation? If it is, I can propose a generic C implementation of RB tree. It seems that Tor uses some kind of hashmap [4]. What about using hashmaps with RB tree as bucket and thus ensure bounded time complexity? In some cases, it could be interesting to store RB tree nodes in hashmap to ensure lookup in O(1) while keeping entries sorted. Regards, L. [0] https://en.wikipedia.org/wiki/Red%E2%80%93black_tree [1] https://trac.torproject.org/projects/tor/ticket/13739 [2] https://github.com/freebsd/freebsd/blob/master/sys/sys/tree.h [3] https://gcc.gnu.org/onlinedocs/gcc/Inline.html [4] https://gitweb.torproject.org/tor.git/tree/src/common/container.h

1 0

Freenet + Onioncat: Is the traffic welcome?
by konstant＠mail2tor.com 25 Jun '16

25 Jun '16

I posted steps on how to connect Freenet nodes over Onioncat and Garlicat for Tor/I2P. I am looking to scale it into an Opennet inside Tor with a lot of peers: https://emu.freenetproject.org/pipermail/devl/2016-June/039056.html https://emu.freenetproject.org/pipermail/devl/2016-June/039059.html Is the extra traffic desirable in Tor? Reading asn's comment, I was under the impression that you are interested in adding higher latency traffic such as Freenet or mixnets for better anonymity: https://blog.torproject.org/blog/crowdfunding-future-hidden-services Using both projects in tandem can finally realize the vision of FreeHaven. You are the best at firewall circumvention, performance and accessing the web, Freenet supplies users with censorship resistant publishing and p2p services. There is a HotPETs 16 paper co-authored by George Danezis on renewing interest in anonymous storage networks: http://www0.cs.ucl.ac.uk/staff/M.Isaakidis/p/isaakidis-p2pstorageservices-h…

4 8

We need a new RPM maintainer
by Nick Mathewson 24 Jun '16

24 Jun '16

Hi, all! Ondrej Mikle, who has built our RPMs for a while, is no longer able to do so. (He isn't using RPM distros any more, doesn't have as much free time, and etc.) First: Thanks, Ondrej, for all your hard work! Here's the instructions he sent on how to do it (quoted with permission): {{{ Basically every part of the process is documented here: https://gitweb.torproject.org/user/hiviah/rpm-build-scripts.git/tree/README It's maybe not the best README, because the actual merge-and-build part is in the middle (but I always use it, otherwise I'd just forget all the necessary steps). Nevertheless, the introduction maybe necessary for someone not familiar with the process. The process in the short is: 0. have the environment ready (has to be done just once) 1. clone my own RPM fork which has RPM changes (https://gitweb.torproject.org/user/hiviah/rpm-tor.git) 2. Merge and build according to "MERGING REPO USED FOR RPM BUILDING FROM ORIGIN" 3. Download, review, sign the built RPMs (I used feddei.tpo VM for this, but you can have your own VM as I had last time since feddei.tpo was down) 4. upload to palmeri.tpo 5. distribute to everyone else via "static-update-component deb.torproject.org" on palmeri.tpo I could walk somebody through this, as I said, this is not rocket surgery, mostly attention to detail :) If there ever was a critical need for a special build due to some unforseen bug, I could still do it, but this is for exceptional case only. }}} The easiest way for RPMs to happen would be if somebody who already has a Tor LDAP account wants to step forward and volunteer for a while. It would be harder if this were somebody that we didn't know who volunteered: until our RPM process creates reproducible builds, we need to have some amount of trust in the person who creates them. There may be other issues here too. I am no packaging expert. :) best wishes, -- Nick Mathewson

6 7

[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