<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 10 Sep 2015, at 17:01, isis <<a href="mailto:isis@torproject.org" class="">isis@torproject.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Hey all,<br class=""><br class="">I have a working implementation of proposal #188, [0] which specifies a<br class="">mechanism by which tor's (rather accidental) loose-source routing feature is<br class="">utilised by Bridges in order to transparently inject a Bridge Guard into all<br class="">client circuits. (See #7144. [1])<br class=""><br class="">Currently, I am updating the text in proposal #188 to match my implementation,<br class="">and I am trying to decide what to do about the two types of Bridge ORPort<br class="">reachability testing. Here's the text I've written so far to explain the<br class="">issues:<br class=""><br class="">(In the following, "Alice" is an OP, "Bob" is a Bridge, "Guillaume" is<br class="">Bob's chosen Entry Guard, and "Charlie" is a random Middle node.)<br class=""><br class=""><blockquote type="cite" class="">4.4. Bridge Reachability Testing<br class=""><br class=""> Currently, a Bridge's reachability is tested both by the Bridge<br class=""> itself (called "self-testing") and by the BridgeAuthority.<br class=""><br class="">4.4.1. Bridge Reachability Self-Testing<br class=""><br class=""> Before a Bridge uploads its descriptors to the BridgeAuthority, it<br class=""> creates a special type of testing circuit which ends at itself:<br class=""><br class=""> Bob -> Guillaume -> Charlie -> Bob<br class=""><br class=""> Thus, going to all this trouble to later use loose-source routing in<br class=""> order to relay Alice's traffic through Guillaume (rather than<br class=""> connecting directly to Charlie, as Alice intended) is diminished by<br class=""> the fact that Charlie can still passively enumerate Bridges by<br class=""> waiting to be asked to connect to a node which is not<br class=""> contained within the consensus.<br class=""></blockquote></div></blockquote><div><br class=""></div><div>Extending to an ORPort not in the consensus can also be used to enumerate single onion services (prop252).</div><div>Any defences could apply to both, and if they are indistinguishable, single onion services could provide cover for bridges.</div><div>(Except, of course, for the defence of a single onion service being a relay. That doesn’t help bridges.)</div><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><br class=""> We could get around this option by disabling self-testing for bridges<br class=""> entirely, by automatically setting "AssumeReachable 1" for all Bridge<br class=""> relays… although I am not sure if this is wise.<br class=""><br class="">4.4.2. Bridge Reachability Testing by the BridgeAuthority<br class=""><br class=""> After receiving Bob's descriptors, the BridgeAuthority attempts to<br class=""> connect to Bob's ORPort by making a direct TLS connection to the<br class=""> Bridge's advertised ORPort.<br class=""><br class=""> Should we change this behaviour? One the one hand, at least this<br class=""> does not enable any random OR in the entire network to enumerate<br class=""> Bridges. On the other hand, any adversary who can observe packets<br class=""> from the BridgeAuthority is capable of enumeration. <br class=""></blockquote><br class="">So, my current questions are:<br class=""><br class=""> 1. Bridges only do reachability self-testing in order to warn their operators<br class=""> that the Bridge (or firewall or whatever) might be misconfigured, correct?<br class=""> Is there any other reason (or future reason) why self-testing is<br class=""> important/useful?<br class=""><br class=""> 2. How should the self-testing be changed?<br class=""><br class=""> 2.a. First, if there aren't any other reasons for self-testing: Is Bridge<br class=""> reachability self-testing actually helpful to Bridge operators in<br class=""> practice? Don't most Bridge operators just try to connect, as a<br class=""> client, to their own Bridge to see if it's working correctly? (This<br class=""> is what I usually do, at least…)<br class=""><br class=""> If it's not useful to most Bridge operators, can we just disable<br class=""> self-testing for all Bridges? (And, should we disable it only for<br class=""> Bridges who are using Bridge Guards, or all of Bridges regardless?)<br class=""><br class=""> 2.b. If it is useful to people, then the best way I can think of so far to<br class=""> keep it, but refactor it to be safer, would be to create a circuit<br class=""> like:<br class=""><br class=""> Bridge → Guard → Middle → OtherMiddle → Guard → Bridge<br class=""><br class=""> Clearly, that circuit is just a little bit insane… but we can't do:<br class=""><br class=""> Bridge → Guard → Middle → Guard → Bridge<br class=""><br class=""> because the Middle would refuse to extend back to the previous node<br class=""> (all ORs follow this rule). Similarly, it would be stupid to do:<br class=""><br class=""> Bridge → Guard → Middle → OtherMiddle → Bridge<br class=""><br class=""> because, obviously, that merely shifts the problem and accomplishes<br class=""> nothing. But is there something smarter I could do?<br class=""></div></blockquote><div><br class=""></div><div>I quite like this idea, and a 5-hop circuit is below the 8-hop limit.</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""> 3. Should we change how the BridgeAuthority tests Bridge ORPort reachability?<br class=""> If so, how?<br class=""></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""> 4. If I'm going to refactor all of this, are there other (future) things I<br class=""> should take into account?<br class=""><br class=""> For example, if self-testing is disabled for Bridges, and, due to #7349,<br class=""> [2] the BridgeAuthority isn't testing reachability either, then how will<br class=""> the BridgeAuthority know if (any of) the Bridge's PTs are reachable?<br class=""> (One solution might be to, in that case, have the BridgeAuthority lie and<br class=""> tell BridgeDB that such Bridges were reachable, letting BridgeDB do the PT<br class=""> reachability testing.)<br class=""><br class="">Please help me brainstorm a way out of this mess!<br class=""><br class="">[0]: <a href="https://gitweb.torproject.org/torspec.git/tree/proposals/188-bridge-guards.txt" class="">https://gitweb.torproject.org/torspec.git/tree/proposals/188-bridge-guards.txt</a><br class="">[1]: <a href="https://bugs.torproject.org/7144" class="">https://bugs.torproject.org/7144</a><br class="">[2]: <a href="https://bugs.torproject.org/7349" class="">https://bugs.torproject.org/7349</a><br class=""><br class="">Best Regards,<br class="">-- <br class=""> ♥Ⓐ isis agora lovecruft<br class="">_________________________________________________________<br class="">OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35<br class="">Current Keys: <a href="https://blog.patternsinthevoid.net/isis.txt" class="">https://blog.patternsinthevoid.net/isis.txt</a><br class=""><br class="">_______________________________________________<br class="">tor-dev mailing list<br class=""><a href="mailto:tor-dev@lists.torproject.org" class="">tor-dev@lists.torproject.org</a><br class="">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev<br class=""></div></blockquote></div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Tim Wilson-Brown (teor)</div><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">teor2345 at gmail dot com<br class="">PGP: 968F094B (ABFED1AC & A39A9058 expire 15 Sep 2015)<br class=""><br class="">teor at blah dot im<br class="">OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F (From 1 Sep 2015)</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
<br class=""></body></html>