[tor-dev] Bridge Guards (prop#188) & Bridge ORPort Reachability Tests
isis at torproject.org
Fri Oct 30 16:02:29 UTC 2015
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
>>>> 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
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
Current Keys: https://blog.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1240 bytes
Desc: Digital signature
More information about the tor-dev