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

Fri Sep 11 23:45:38 UTC 2015

> On 10 Sep 2015, at 17:01, isis <isis at torproject.org> wrote:
> 
> Hey all,
> 
> I have a working implementation of proposal #188, [0] which specifies a
> mechanism by which tor's (rather accidental) loose-source routing feature is
> utilised by Bridges in order to transparently inject a Bridge Guard into all
> client circuits.  (See #7144. [1])
> 
> Currently, I am updating the text in proposal #188 to match my implementation,
> and I am trying to decide what to do about the two types of Bridge ORPort
> reachability testing.  Here's the text I've written so far to explain the
> issues:
> 
> (In the following, "Alice" is an OP, "Bob" is a Bridge, "Guillaume" is
> Bob's chosen Entry Guard, and "Charlie" is a random Middle node.)
> 
>> 4.4. Bridge Reachability Testing
>> 
>>   Currently, a Bridge's reachability is tested both by the Bridge
>>   itself (called "self-testing") and by the BridgeAuthority.
>> 
>> 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.)

>> 
>>   We could get around this option by disabling self-testing for bridges
>>   entirely, by automatically setting "AssumeReachable 1" for all Bridge
>>   relays… although I am not sure if this is wise.
>> 
>> 4.4.2. Bridge Reachability Testing by the BridgeAuthority
>> 
>>   After receiving Bob's descriptors, the BridgeAuthority attempts to
>>   connect to Bob's ORPort by making a direct TLS connection to the
>>   Bridge's advertised ORPort.
>> 
>>   Should we change this behaviour?  One the one hand, at least this
>>   does not enable any random OR in the entire network to enumerate
>>   Bridges.  On the other hand, any adversary who can observe packets
>>   from the BridgeAuthority is capable of enumeration.
> 
> So, my current questions are:
> 
> 1. Bridges only do reachability self-testing in order to warn their operators
>    that the Bridge (or firewall or whatever) might be misconfigured, correct?
>    Is there any other reason (or future reason) why self-testing is
>    important/useful?
> 
> 2. How should the self-testing be changed?
> 
>    2.a. First, if there aren't any other reasons for self-testing: Is Bridge
>         reachability self-testing actually helpful to Bridge operators in
>         practice?  Don't most Bridge operators just try to connect, as a
>         client, to their own Bridge to see if it's working correctly?  (This
>         is what I usually do, at least…)
> 
>         If it's not useful to most Bridge operators, can we just disable
>         self-testing for all Bridges?  (And, should we disable it only for
>         Bridges who are using Bridge Guards, or all of Bridges regardless?)
> 
>    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.

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

> 
> 4. If I'm going to refactor all of this, are there other (future) things I
>    should take into account?
> 
>    For example, if self-testing is disabled for Bridges, and, due to #7349,
>    [2] the BridgeAuthority isn't testing reachability either, then how will
>    the BridgeAuthority know if (any of) the Bridge's PTs are reachable?
>    (One solution might be to, in that case, have the BridgeAuthority lie and
>    tell BridgeDB that such Bridges were reachable, letting BridgeDB do the PT
>    reachability testing.)
> 
> Please help me brainstorm a way out of this mess!
> 
> [0]: https://gitweb.torproject.org/torspec.git/tree/proposals/188-bridge-guards.txt
> [1]: https://bugs.torproject.org/7144
> [2]: https://bugs.torproject.org/7349
> 
> Best Regards,
> --
> ♥Ⓐ isis agora lovecruft
> _________________________________________________________
> OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
> Current Keys: https://blog.patternsinthevoid.net/isis.txt
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150912/a301574d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150912/a301574d/attachment.sig>