[tor-dev] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests

[isis]

Tim Wilson-Brown - teor transcribed 19K bytes:
>> On 12 Sep 2015, at 17:26, isis <isis at torproject.org> wrote:
>>> Tim Wilson-Brown - teor transcribed 23K bytes:
>>>> On 10 Sep 2015, at 17:01, isis <isis at torproject.org> wrote:
>>>> 
>>>>   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).

Okay, I added this part to the bridge reachability self-testing section of
prop#188 earlier today.


>>>> 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?

Sorry, I meant the BridgeAuth'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.

Hrm.  Perhaps it's not okay for the BridgeAuth to connect to bridges through
their bridge guards?

My reasoning here is that, if you're a bridge guard, we want it to look (as
much as possible) like you're actually the entry guard for a normal client.
Having the BridgeAuth suddenly connect to you, and ask you to connect to
something you think is actually a client would look pretty weird.

Thanks for the great feedback!

-- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1240 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151030/a5eccd36/attachment.sig>