- tor-dev - lists.torproject.org

Proposal 286: Controller APIs for hibernation access on mobile
by Nick Mathewson 08 Dec '17

08 Dec '17

Filename: 286-hibernation-api.txt Title: Controller APIs for hibernation access on mobile Author: Nick Mathewson Created: 30-November-2017 Status: Open 1. Introduction On mobile platforms, battery life is achieved by reducing needless network access and CPU access. Tor currently provides few ways for controllers and operating systems to tune its behavior. This proposal describes controller APIs for better management of Tor's hibernation mechanisms, and extensions to those mechanisms, for better power management in mobile environments. 1.1. Background: hibernation and idling in Tor today We have an existing "hibernation" mechanism that we use to implement "bandwidth accounting" and "slow shutdown" mechanisms: When a Tor instance is close to its bandwidth limit: it stops accepting new connections or circuits, and only processes those it has, until the bandwidth limit is reached. Once the bandwidth limit is reached, Tor closes all connections and circuits, and all non-controller listeners, until a new accounting limit begins. Tor handles the INT signal on relays similarly: it stops accepting new connections or circuits, and gives the existing ones a short interval in which to shut down. Then Tor closes all connections and exits the process entirely. Tor's "idle" mechanism is related to hibernation, though its implementation is separate. When a Tor clients has passed a certain amount of time without any user activity, it declares itself "idle" and stops performing certain background tasks, such as fetching directory information, or building circuits in anticipation of future needs. (This is tied in the codebase to the "predicted ports" mechanism, but it doesn't have to be.) 1.2. Background: power-management signals on mobile platforms (I'm not a mobile developer, so I'm about to wildly oversimplify. Please let me know where I'm wrong.) Mobile platforms achieve long battery life by turning off the parts they don't need. The most important parts to turn off are the antenna(s) and the screen; the CPU can be run in a slower mode. But it doesn't do much good turning things off when they're unused, if some background app is going to make sure that they're always in use! So mobile platforms use signals of various kinds to tell applications "okay, shut up now". Some apps need to do online background activities periodically; to help this out, mobile platforms give them a signal "Hey, now is a good time if you want to do that" and "stop now!" 1.3. Mostly out-of-scope: limiting CPU wakeups when idle. The changes described here will be of limited use if we do not also alter Tor so that, when it's idle, the CPU is pretty quiet. That isn't the case right now: we have large numbers of callbacks that happen periodically (every second, every minute, etc) whether they need to or not. We're hoping to limit those, but that's not what this proposal is about. 2. Improvements to the hibernation model To present a consistent interface that applications and controllers can use to manage power consumption, we make these enhancements to our hibernation model. First, we add three new hibernation states: "IDLE", "IDLE_UPDATING", "SLEEP", and "SLEEP_UPDATING". "IDLE" is like the current "idle" or "no predicted ports" state: Tor doesn't launch circuits or start any directory activity, but its listeners are still open. Tor clients can enter the IDLE state on their own when they are LIVE, but haven't gotten any client activity for a while. Existing connections and circuits are not closed. If the Tor instance receives any new connections, it becomes LIVE. "IDLE_UPDATING" is like IDLE, except that Tor should check for directory updates as appropriate. If there are any, it should fetch directory information, and then become IDLE again. "SLEEPING" is like the current "dormant state we use for bandwidth exhaustion, but it is controller-initiated: it begins when Tor is told to enter it, and ends when Tor is told to leave it. Existing connections and circuits are closed; listeners are closed too. "SLEEP_UPDATING" is like SLEEP, except that Tor should check for directory updates as appropriate. If there are any, it should fetch directory information, and then SLEEP again. 2.1. Relay operation Relays and bridges should not automatically become IDLE on their own. 2.2. Onion service operation When a Tor instance that is running an onion service is IDLE, it does the minimum to try to remain responsive on the onion service: It keeps its introduction points open if it can. Once a day, it fetches new directory information and opens new introduction points. 3. Controller hibernation API 3.1. Examining the current hibernation state We define a new "GETINFO status/hibernation" to inspect the current hibernation state. Possible values are: - "live" - "idle:control" - "idle:no-activity" - "sleep:control" - "sleep:accounting" - "idle-update:control" - "sleep-update:control" - "shutdown:exiting" - "shutdown:accounting" - "shutdown:control" The first part of each value indicates Tor's current state: "live" -- completely awake "idle" -- waiting to see if anything happens "idle-update" -- waiting to see if anything happens; probing for directory information "sleep" -- completely unresponsive "shutdown" -- unresponsive to new requests; still processing existing requests. The second part of each value indicates the reason that Tor entered this state: "control" -- a controller told us to do this. "no-activity" -- Tor became idle on its own due to not noticing any requests. "accounting" -- the bandwidth system told us to enter this state. "exiting" -- Tor is in this state because it's getting ready to exit. We add a STATUS_GENERAL hibernation event as follows: HIBERNATION "STATUS=" (one of the status pairs above.) Indicates that Tor's hibernation status has changed. Note: Controllers MUST accept status values here that they don't recognize. The "GETINFO accounting/hibernating" value and the "STATUS_SERVER HIBERANATION_STATUS" event keep their old meaning. 3.2. Changing the hibernation state We add the following new possible values to the SIGNAL controller command: "SLEEP" -- enter the sleep state, after an appropriate shutdown interval. "IDLE" -- enter the idle state "SLEEPWALK" -- If in sleep or idle, start probing for directory information in the sleep-update or idle-update state respectively. Remain in that state until we've probed for directory information, or until we're told to IDLE or SLEEP again, or (if we're idle) until we get client activity. Has no effect if not in sleep or idle. "WAKEUP" -- If in sleep, sleep-update, idle, idle-update, or shutdown:sleep state, enter the live state. Has no effect in any other state. 3.3. New configuration parameters StartIdle -- Boolean. If set to 1, Tor begins in IDLE mode.

5 8

Student project to work on IPv6 support (was: [tor-relays] About relay size)
by Santiago R.R. 06 Dec '17

06 Dec '17

(Moving this thread from tor-relay) El 03/10/17 a las 14:25, teor escribió: > > > On 3 Oct 2017, at 10:57, Roman Mamedov <rm(a)romanrm.net> wrote: > > > > On Tue, 3 Oct 2017 09:53:46 -0400 > > teor <teor2345(a)gmail.com> wrote: > > > >>> For interposing dual-protocoled nodes along the way, how many do there > >>> have to be for it to become "not too limiting"? > >> > >> This is one of the questions we need researchers to answer. > > > > I can't help but feel you are overcomplicating this. > > > > Clients create a circuit by randomly picking 3 nodes out of the all-nodes > > pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over > > IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are > > IPv4-only, the whole selection can be thrown away and repeated. > > > > That way IPv6-only relays could get some usage on a totally random basis, with > > no compromises and no restraining "of the next hop based on the previous one", > > not hurting anonymity. Clients just need to know which nodes are IPv4-only, > > IPv6-only or dual-stack, to not attempt unworkable combinations, discarding > > them instead. > > Discarding unworkable combinations and restraining node choices seem > equivalent to me, although the relay weights may be different. > > > And as there are more and more dual-stack or IPv6-only relays, the "throw > > away" step will be needed less and less often. > > If you think this will work and is safe for client anonymity, then the next step > is to write a tor proposal. Having a concrete design could help with > analysing the anonymity implications as well. > > I think IPv6-only relays are a lower priority than better IPv6 and dual-stack > client support, and IPv6-only bridge support But we could do both in the > same release. Hello tor-dev, With my colleague JC Bach (in CC), we have proposed a last-year student project to address IPv6-related issues in Tor for the upcoming semester, at IMT Atlantique engineering school. There will be two students working on it. It is hard to say now how far we will arrive, especially because this is our first approach to Tor entrails. So this message is to say we have good chances to come back here looking for help :-) Cheers, -- Santiago

2 4

Rebooting work on proposal #247 (guard discovery)
by George Kadianakis 06 Dec '17

06 Dec '17

Hello Mike, I'm finally getting out of the prop224/microdescriptor bug pile, and getting more time to start working on guard stuff like prop247 again. I'm planning to spend a few days next week to regain knowledge on prop247. I'll check out the notes from the Wilmington hackfest, re-read my old simulator's code, etc. I know you have thought more about prop247 the past months, and it would be great if you could brief me up on any updates that I should know about. Specifically I'm wondering if you have any new insights on how the proposed prop247 changes interact with Tor's guard algorithm (prop271)? Also any other things I should know about from your work on the performance simulator? Perhaps ideas about performance, topology or path restrictions? I'm hoping that such updates might help me boot up faster! Cheers! :-)

2 2

Names for your Onions: Onion addresses in SSL certificates
by heddha 06 Dec '17

06 Dec '17

Dear list, I wrote an addon as a PoC for idea 3 of the blogpost in [0]. The idea was to extend the Tor Browser by a means of reading out the C/O/S/L fields of the SSL certificate, and, if a website contains an onion address in one of those fields, to automatically redirect users to it. As the web-extensions API doesn't contain a means of reading out certificate information [1], I implemented it as an add-on. You can find it here: [2]. As stated in the blog post, all fields mentioned above could theoretically be filled with an onion address. Unfortunately, I found a large drawback: A certificate from Letsencrypt doesn't contain the C/S/O/L fields, as Letsencrypt performs a validation of required fields only, and the subject field isn't required. All unvalidated fields are by default not included in the certificate [3]. It is therefore not possible to include an onion address in the proposed fields using Letsencrypt; these are only filled when extended validation is performed (during which the correctness of the entries seems to be validated as well). Non-organisational suppliers of websites will therefore not be able to include their onion addresses in their normal certificate, which will most likely limit the amount of certificates containing onion addresses to a few larger organisations (if any). To make this idea actually usable for a large amount of people, one would have or to use another field, the content of which is neither checked nor deleted from a certificate, or introduce a new field =) Kind regards, heddha [0]: https://blog.torproject.org/cooking-onions-names-your-onions [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1322748 [2]: https://github.com/heddha/sslOnions [3]: https://community.letsencrypt.org/t/maintain-subject-records-country-etc-in…

1 0

Start contributing to Tor
by Aruna Maurya 04 Dec '17

04 Dec '17

I am new to the community and would like to contribute and help along. I did a complete read up on how the Tor browser works, but I would like to delve in more and get acquainted with the code base, so that I understand and learn a lot in the process. I already cloned and built the Tor(core) and TorBrowser from source for easy understanding and primarily as it would help me to reproduce bugs as I work on them. Any further guidance is appreciated. Thankyou for spending the time to read this through. -- Regards, Aruna Maurya, CSE,B.tech, Blog <https://themindreserves.wordpress.com/> | Medium <https://medium.com/@arunamaurya>

3 4

Running Tor with a 15MB memory limit
by Nathan Freitas 04 Dec '17

04 Dec '17

I am currently supporting the iCepa project, an effort to get Tor to run as a Network Extension VPN on iOS. https://github.com/iCepa/iCepa The good news is that, after a long time, we have the whole thing somewhat working. The bad news is that after browsing a few pages through Tor, the extension is shutdown due to going over the extremely tiny 15MB available heap. More on this at: https://forums.developer.apple.com/thread/73148 https://developer.apple.com/documentation/networkextension My question is, does anyone else have experience running Tor within some extreme memory limits? Any guidance on configuring torrc for this? Any thoughts on build flags or changes that might reduce memory usage? We have already identified that the new compression features available in recent versions of Tor consume more memory, and we may have to disable those for now, for instance. Thanks for any thoughts! +n

2 1

Privacy Pass
by bancfc＠openmailbox.org 29 Nov '17

29 Nov '17

Hi. Are there any plans to include Privacy Pass addon in Tor Browser by default? Privacy Pass is the result of some great work by Ian and his team at University of Waterloo to spare Tor users the torture of solving infinite captchas from Cloudflare.[0][1] [0] https://privacypass.github.io/team/ [1] https://blog.cloudflare.com/privacy-pass-the-math/

4 3

[release] [protocol] Onionoo 4.4-1.8.0
by iwakeh 28 Nov '17

28 Nov '17

Hi there! Onionoo's protocol was extended and has a minor version jump to 4.4. Download available at: https://dist.torproject.org/onionoo/4.4-1.8.0/ Main protocol changes (also summarized in [0]): The version field, which was introduced in 4.1, is now available for bridges, too. The "recommended_version" parameter is provided as an additional search parameter. Details can be found in [1a], [1b], and [2]. The changes are already deployed on all onionoo.torproject.org instances and the update included an upgrade of the geoip data used in Onionoo. Reminder: a major *upcoming version* jump 5.0 lies ahead. Take note of the field "next_major_version_scheduled":"2017-12-17" in documents. Please direct comments and questions to the metrics-team mailing list [3]. Cheers, iwakeh [0] https://metrics.torproject.org/onionoo.html#versions_4_4 [1a] https://metrics.torproject.org/onionoo.html#details_relay_recommended_versi… [1b] https://metrics.torproject.org/onionoo.html#details_bridge_recommended_vers… [2] hhttps://metrics.torproject.org/onionoo.html#parameters_search [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Tor and DNS
by N6Ghost 25 Nov '17

25 Nov '17

hi all, saw an open item in the tor projects, about dns and other resource record types. this got me thinking about just trying to understand Tor and DNS. for what I gather so far, is Tor and dns is only about "a" records and quad records "aaaa", thats pretty much it. i think PTR also but just whats need for hostname lookup. I am assuming this means tor clients, and tor browsers but have yet to validate that. any other info on this would be helpful. still trying to dig around and find where the data may be. -N6Ghost

1 0

rendezvous on non-OR circuit with purpose Acting as rendevous
by Ian Goldberg 23 Nov '17

23 Nov '17

I just restarted my node, and saw this in the log: Nov 23 14:07:21.000 [warn] Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending) What does this mean? I'm a little worried someone out there is playing games with the protocol...

2 1