Re: [tor-dev] Student project to work on IPv6 support (was: [tor-relays] About relay size)

[teor]

Hi,

How are these student projects working out?
Is there anything we can do to help?

(There is no need to identify the students, unless they want to be named
on a public mailing list.)

> On 19 Oct 2017, at 01:57, teor  wrote:
> 
>> On 14 Oct 2017, at 01:06, Santiago R.R.  wrote:
>> 
>>> El 12/10/17 a las 12:22, teor escribió:
>>> 
>>> On 12 Oct 2017, at 09:15, Santiago R.R.  wrote:
>> 
>> …
>>> 
>>> 
>>>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.
>>> 
>>> …
>>> 
>>> This is great! We would like some help with Tor's IPv6 support.
>>> And we are happy to help you and your students.
>>> 
>> …
>> 
>>> How many students?
>> 
>> There will be two.
>> 
>>> How much time?
>> 
>> From now until mid-March. Students will have 135h in their schedules to
>> work on their projects.
>> 
>>> What are your goals for the project?
>> 
>> For now, it's still open, but addressing IPv6 support. We should limit
>> the scope soon, according to open related tickets that could be feasible
>> to work on.
>> 
>>> How much do you expect to get done?
>> 
>> At least, choose a couple of easy-tagged IPv6 tickets, and close them.
>> However, it's difficult to state on this right now.
> 
> 135h is enough to submit a small, one-line change to get used to the tor
> patch process, and then do something more substantial with some testing.

Have the students tried small patches?
How did they go?

> (Snip)

Here's how your students (or you) can find tickets and get help with patches:

>>> Our bug tracker is:
>>> https://trac.torproject.org/
>>> 
>>> We are also in #tor-dev IRC on irc.oftc.net.

It might be worth reminding your students that replies on IRC can take hours.
Some people are disappointed when they don't get an instant reply.

>>> Please ask questions early, and ask often!
>>> We would love to help you help tor.

T___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal 286: Controller APIs for hibernation access on mobile

[Michael Rogers]

On 05/12/17 22:18, teor wrote:
> 
>> On 6 Dec 2017, at 05:12, Michael Rogers  wrote:
>>
>> If the service needs to fetch a consensus and microdescs before it can
>> respond to a rendezvous cell, the delay could be far longer than the
>> difference in latency between a mobile phone and a laptop. So my point
>> is that the client will be able to tell that the service was woken from
>> idle by the rendezvous cell, which might have implications for the
>> service's anonymity.
>>
>> For example, it lets the client know that the service isn't running on
>> the same device as another service the client recently connected to,
>> otherwise the device wouldn't have been idle. Maybe that's unavoidable,
>> or not worth avoiding, but I just wanted to flag the issue.
> 
> We try to avoid attacks like this.
> Or, if we can't, we try to minimise their effect.
> 
> But when multiple onion services or clients share a tor instance, they also
> share the state of the consensus, directory documents, and guards.
> 
> Our best answer is probably: "don't share a tor instance if you want
> unlinkable onion services".
> 
> Or: "don't IDLE if you want unlinkable onion services".
> (Also, never lose your network connection.)

Sounds reasonable. Maybe something to this effect could be added to the
proposal, so app developers know what to expect in terms of linkability?

Could a long delay between receiving a rendezvous cell and responding
cause any other issues? For example, is there a high probability of the
client timing out before the service has fetched enough directory info
to be able to respond? If so, maybe it's worthwhile for the service to
be more proactive about keeping its directory info fresh?

>> Maybe I've misunderstood the proposal, but I thought the intent was that
>> Tor wouldn't fetch anything in IDLE mode, and wouldn't automatically
>> change from IDLE to IDLE_UPDATING - it would need a SLEEPWALK signal to
>> tell it to change to IDLE_UPDATING, and then it would automatically
>> change back to IDLE when it was done.
> 
> LIVE fetches directory documents so it always has a live consensus.
> IDLE fetches directory documents just often enough to stay online.
> SLEEP fetches nothing.

OK, so I guess the use case for SLEEPWALK is telling Tor to fetch a live
consensus and microdescs when it otherwise wouldn't have done - i.e. it
allows the controller to manage the freshness of the directory info?

But I'm really just guessing here. Nick, can you clarify?

>> Rather than the controller picking an interval, would it be better for
>> Tor to specify (maybe in its response to the IDLE signal) when it next
>> needs to be woken?
> 
> Or, "the latest time it can be woken to have directory documents with
> property X", where X is some combination of:
> * a live consensus
> * a reasonably live consensus
> * enough non-expired descriptors to build circuits

Yup, I think that makes sense - it achieves [what I guess is] the
purpose of SLEEPWALK while keeping knowledge about *why* Tor needs to be
woken at that time encapsulated within Tor, which is an improvement.

>>> So if IDLE doesn't meet your needs, it would help us to know why. If
>>> there's enough demand for it, it may be better to add a "WARM" state,
>>> where Tor checks for directory documents whenever a consensus
>>> expires, and otherwise acts like IDLE.
>>
>> Within the scope of this proposal that sounds like a good solution. But
>> if we're looking ahead to changes that allow the device to sleep without
>> shutting down Tor or disabling its network connectivity, then the
>> controller will need to be responsible for managing sleeps and wakeups,
>> which fits better with [my guess as to the intent of] the SLEEPWALK
>> mechanism than a WARM state.
> 
> We do need a use case here :-)
> 
> And yes, I agree that the controller should be able to manage wakeups.

OK, I have two use cases. They go beyond the scope of this proposal
because they're also concerned with CPU wakeups, but I'm not sure we can
really design the controller API without considering CPU wakeups at all.

The first use case is saving power by putting the device to sleep, while
keeping a hidden service available.

"Sleep" on Android is similar to suspend on Linux (for recent Android
kernels it's identical). User-space code is paused and the kernel only
responds to a limited set of interrupts, including network activity and
alarms.

Entering this state without disabling Tor's network connectivity causes
it to panic when the device wakes up - its libevent timers don't fire
during sleep, so it thinks the clock has jumped. Just suppressing that
panic reaction doesn't seem like a good idea. It would be better if we
could warn Tor that the device is about to sleep, so it should stop
building circuits and making connections, and should expect the clock to
jump. This was my original motivation for asking for an "idle mode".

If Tor tells the controller when it needs to be woken then the

Re: [tor-dev] Rebooting work on proposal #247 (guard discovery)

[George Kadianakis]

Mike Perry  writes:

> George Kadianakis:
>> 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.
>

Hey, and thanks for the reply!

> I was not involved in with Prop271, so I am not deeply familiar with it.
> However, it has several things we do not need. In particular, the plan
> for prop247 still is to treat consensus information as the official
> notion of vanguard reachability, so there is no need to try to determine
> censorship, firewall, or local network reachability information. If a
> node is in the consensus, it stays in our vanguard set and does not get
> replaced until it actually leaves the consensus. This is consistent with
> how the consensus is currently used for interior hops, and mitigates
> path bias attacks.
>
> If it is dead-simple to use only the consensus uptime portions of
> prop271 without the reachability code, I could be convinced of that. But
> as it is, the rotation times do not need to be as long as guards, and
> the implementation simplification here is attractive. Plus, nodes that
> fall completely out of the consensus periodically like this are probably
> bad choices anyway..
>
> What do you think?
>  

Sounds plausible.

I'm slightly worried that not tracking transient reachability status
might cause situations where all the L2 guards are temporarily down and
hence brings complete the service/client to complete halt. I'm not sure
how likely this is to happen, and it surely depends on L2 size and L2
node selection parameters.

I have not thought about the engineering aspects of this. I think
bending the prop271 code to do this might be a PITA. But I'm also not
sure if not using the guard layer is gonna be easier either. I imagine
there will be engineering complexities either way here. Will try to
figure this out in the coming weeks.

>> 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?
>
> Yes. I have decided to simplify everything as much as possible. I am
> going with a mesh topology for the prop247 performance tests (via
> https://bugs.torproject.org/13837,  https://bugs.torproject.org/23101
> and https://bugs.torproject.org/24487). That is the simplest option to
> implement and test for performance, and intuitively seems to have
> almost as good security properties as the bin version (unless your
> security simulator tells us otherwise).
>

Sounds reasonable!

> I am also aiming for these high-level design goals, most important
> first:
>
> 0. All service-side circuits use 3 hops of vanguards.
> 1. Hidden services should avoid trivially disclosing their third
>vanguard to a non-network adversary (ie one that is not running nodes
>but that is watching either HSDESCS or connecting to the service).
>This means their paths look like this:
>S - G - L2 - L3 - HSDIR
>S - G - L2 - L3 - Intro
>S - G - L2 - L3 - M - Rend
> 2. Clients should avoid revealing their third vanguard hop to services
>and to nodes that have information about which service they are
>accessing. This means that their paths look like this:
>C - G - L2 - L3 - M - HSDIR
>C - G - L2 - L3 - M - Intro
>C - G - L2 - L3 - Rend
> 3. Clients use 3 hops of vanguards for all hidden service circuits.
>
> If we do all of these, it will mean that we will have long path lengths
> (8 hop rends), but it also means that it is easy to reason about
> linkability and information disclosure. My thinking is that we should do
> the performance tests with the safest option first (ie: all of these
> goals), and see exactly how bad it is, and then make compromises if it
> turns out to be much worse performance than status quo.
>
> In the event of bad performance, I would alter property #3 before
> messing with property #2, and alter #2 before property #1, but I could
> be talked into a different strategy, or driven to one based on data.
>

Sounds reasonable.

In general, I imagine that this feature is gonna be opt-in initially
which makes me worry less about performance in the beginning.

Also, I'm currently not too afraid of guard discovery attacks for the
client-side, which might mean that we can let the vanguard feature as
optional for much longer time for clients (bringing the hop count to 7).
>
> I have not written up the set of performance experiments I intend to run
> 

[tor-dev] Names for your Onions: Onion addresses in SSL certificates

[heddha]

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-certificate-from-csr/31185


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev