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 -> BobThus, 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.
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?
3. Should we change how the BridgeAuthority tests Bridge ORPort reachability? If so, how?
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.t... [1]: https://bugs.torproject.org/7144 [2]: https://bugs.torproject.org/7349
Best Regards,
On Thu, 10 Sep 2015 07:01:58 +0000 isis isis@torproject.org wrote:
- Should we change how the BridgeAuthority tests Bridge ORPort
reachability? If so, how?
- 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.)
All of this seems to me like we need to sit down somewhere (in meatspace or online), map out how the current system of:
* Clients * Bridges * Bridge Guards * The Bridge Authority
fits together, and figure out how it can be redesigned in a way that is more inline with how things work now/need to work now (PTs were not a thing when this started being one of the bigger stumbling blocks).
Regards,
Yawning Angel transcribed 2.7K bytes:
On Thu, 10 Sep 2015 07:01:58 +0000 isis isis@torproject.org wrote:
- Should we change how the BridgeAuthority tests Bridge ORPort
reachability? If so, how?
- 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.)
All of this seems to me like we need to sit down somewhere (in meatspace or online), map out how the current system of:
- Clients
- Bridges
- Bridge Guards
- The Bridge Authority
fits together, and figure out how it can be redesigned in a way that is more inline with how things work now/need to work now (PTs were not a thing when this started being one of the bigger stumbling blocks).
Regards,
-- Yawning Angel
Sounds like something we could work on at the dev meeting? :)
On 10 September 2015 at 02:01, isis isis@torproject.org wrote:
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…)
Yes it is helpful; no I don't/can't always do that. IPv6 is one issue*. Finding the correct incantation is another**. =)
-tom
* Yes I know I can get free IPv6 tunnels from tunnelbroker, no I don't want to; it is complicated. ** See my email from earlier this summer about piecing everything together to test a bridge.
On 10 Sep 2015, at 17:01, isis isis@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 -> BobThus, 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:
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?
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.
- 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.
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!
Best Regards,
♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt
tor-dev mailing list tor-dev@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)
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 -> BobThus, 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.
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.
- 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).
¹ Sorry, but — after having to type that twice — that name sucks.
Best Regards,
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 -> BobThus, 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).
- 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)
Tim Wilson-Brown - teor transcribed 19K bytes:
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:
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.
- 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!
On 12 Sep 2015, at 17:26, isis isis@torproject.org wrote:
...
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.
...
¹ Sorry, but — after having to type that twice — that name sucks.
“double onion services” - I see what you mean.
What about “dual onion services”? Or even “dual onion”?
It’s shorter, and means the same thing.
I’ll stop bikeshedding now.
Tim
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)
-
isis -
Tim Wilson-Brown - teor -
Tom Ritter -
Yawning Angel