On 12 Sep 2015, at 17:26, isis <isis@torproject.org> wrote:

Tim Wilson-Brown - teor transcribed 23K bytes:

On 10 Sep 2015, at 17:01, isis <isis@torproject.org> wrote:

4.4.1. Bridge Reachability Self-Testing

 Before a Bridge uploads its descriptors to the BridgeAuthority, it
 creates a special type of testing circuit which ends at itself:

     Bob -> Guillaume -> Charlie -> Bob

 Thus, going to all this trouble to later use loose-source routing in
 order to relay Alice's traffic through Guillaume (rather than
 connecting directly to Charlie, as Alice intended) is diminished by
 the fact that Charlie can still passively enumerate Bridges by
 waiting to be asked to connect to a node which is not
 contained within the consensus.

Extending to an ORPort not in the consensus can also be used to enumerate
single onion services (prop252).  Any defences could apply to both, and if
they are indistinguishable, single onion services could provide cover for
bridges.  (Except, of course, for the defence of a single onion service being
a relay. That doesn’t help bridges.)

For single onion services, hiding the location/IP of the server shouldn't
matter much, since the operator has opted into less server-side anonymity.
(That is, it doesn't matter if an adversary can enumerate them, since they are
services like Facebook and Blockchain.info which have chosen to be quite
public.)

However, for "double onion services" — or whatever we're calling the thing that
is (historical) hidden services 2.0 — your point is a good one; I'm starting to
realise more and more that defences for "double onion services"¹ are possibly
defences for bridges and vice versa.

Except that double onion services don’t need an open ORPort at all.
Due to the rendezvous mechanism, they connect like a client, rather than like a bridge.

  2.b. If it is useful to people, then the best way I can think of so far to
       keep it, but refactor it to be safer, would be to create a circuit
       like:

           Bridge → Guard → Middle → OtherMiddle → Guard → Bridge

       Clearly, that circuit is just a little bit insane… but we can't do:

           Bridge → Guard → Middle → Guard → Bridge

       because the Middle would refuse to extend back to the previous node
       (all ORs follow this rule).  Similarly, it would be stupid to do:

           Bridge → Guard → Middle → OtherMiddle → Bridge

       because, obviously, that merely shifts the problem and accomplishes
       nothing.  But is there something smarter I could do?

I quite like this idea, and a 5-hop circuit is below the 8-hop limit.

Okay, thanks!  I'll keep this in mind as a self-testing manoeuvre we might want
to enable for both HSes and bridges.  Hopefully there's something smarter than
"Yo! Throw some extra hops in that shit!", but if it works it works, I guess.

Well, this is “onion" routing after all… extra hops are the core of our anonymity
design(s).

3. Should we change how the BridgeAuthority tests Bridge ORPort reachability?
  If so, how?

The bridge authority could connect via a 3-hop path, but that would suffer
from the same issues as bridge reachability self-testing - the bridge
authority extending to an ORPort not in the consensus would reveal the bridge
to the last hop.

But the bridge authority could choose a set of guards (vanguards?, last-hop
guards?) for this purpose, reducing the chances that one is an adversary.

I started thinking about this idea, but discarded it due to thinking: "Why
expose the bridges to other nodes at all, now that we have bridge guards?"

If anything, I suppose we could consider having the BridgeAuthority simply use
its guards to connect to bridges… but still something feels wrong.  I feel like
this whole bridge testing system needs a giant rethinking and overhaul — rather
than simply bolting more nodes on top of a thing which doesn't really do what
we want anyway (i.e. testing PT reachability).

Do you mean that the bridge authority should receive and use the bridge’s
guards, or the bridge authority’s guards?

If the authority already knows each bridge’s IP and ORPort, I guess that it’s
ok for it to know the bridge’s guards.

But this does seem very complicated for a design that doesn’t actually test PT
reachability (which is what we want).

Tim (teor)

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP: 968F094B (ABFED1AC & A39A9058 expire 15 Sep 2015)

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F (From 1 Sep 2015)