Open topics of prop247: Defending Against Guard Discovery Attacks using Vanguards
Hello, here is some background information and summarizing of proposal 247 "Defending Against Guard Discovery Attacks using Vanguards" for people who plan to work on this in the short-term future. I include a list of open design topics (probably not exhaustive) and a list of engineering topics. Some engineering stuff can be done parallel to the design stuff. ==================== Background info ==================== * Proposal: https://gitweb.torproject.org/torspec.git/tree/proposals/247-hs-guard-discov... * Discussion: ** Initial prop247 thread: https://lists.torproject.org/pipermail/tor-dev/2015-July/009066.html ** Recent prop247 thread: https://lists.torproject.org/pipermail/tor-dev/2015-September/009497.html ** Reading group notes of prop247: https://lists.torproject.org/pipermail/tor-dev/2016-January/010265.html ==================== Design topics ==================== * Optimize proposal parameters ** Optimize guardset sizes ** Optimize guardset lifetimes and prob distributions (minXX/maxXX/uniform?) ** To take informed decision, we might need a prop247 simulator, or an actual PoC with txtorcon * HOW to choose second-layer and third-layer guards? ** Should they be Guards? middles? Vanguards? Serious security / load balancing implications! ** Can guardsets share guards between them or are they disjoint? Particularly third-layer sets ** background: https://lists.torproject.org/pipermail/tor-dev/2016-January/010265.html * HOW to avoid side-channel guard discovery threats? ** Can IP/RP be the same as first-layer guard? ** Can first-layer guard be the same as third-layer guard? ** background: https://gitweb.torproject.org/user/mikeperry/torspec.git/commit/?h=guard_dis... * Change path selection for IP circs to avoid third-layer guard linkability threats. ** Switch from [HS->G1->M->IP] to [HS->G1->G2->G3->IP] or even to [HS->G1->G2->G3->M->IP]. ** Consider the latter option for HSDir circs as well? ** background: https://gitweb.torproject.org/user/mikeperry/torspec.git/commit/?h=guard_dis... * Should prop247 be optional or default? ** Consider making it optional for a testing period? * How does prop247 affects network performance and load balancing? ** especially if it's enabled by default? ** Update load balancing proposal? * Correct behavior for multiple HSes on single host? * Does prop247 influence guard fingerprinting (#10969) and should we care enough? ==================== Engineering topics ==================== * What's a good entrynodes API to implement prop247? * What's a good state file API to implement prop247? * Write prop247 simulator to verify security goals and optimize proposal parameters (see above). * Write PoC with txtorcon! * Write PoC with little-t-tor! ============================================================
On Wed, May 17, 2017 at 02:51:48PM +0300, George Kadianakis wrote:
==================== Design topics ====================
* Optimize proposal parameters ** Optimize guardset sizes ** Optimize guardset lifetimes and prob distributions (minXX/maxXX/uniform?) ** To take informed decision, we might need a prop247 simulator, or an actual PoC with txtorcon
Thanks George. I've just looked through prop#247 and the past tor-dev threads. Another item to add to the design discussion list, unless it got resolved while I wasn't looking: * Do we do the vanguard design for *client* connections to onion services too? * And slipping further down that slope, how does this vanguard design compare to Mike's virtual circuit hopes for all user circuits: https://bugs.torproject.org/15458 We're going to have to think about scope for the meeting, so we cover all the breadth of things we ought to cover, without also letting it balloon into a "I think Tor should do X \forall X" week. In particular, I think it might be smart to sort through (make a list of) all the various attacks and concerns we want to consider, so we can optimize against them all without forgetting some. For example, based on what I've read so far, I'm planning to propose that we have one 3rd level vanguard for each 2nd level vanguard, since that way we have the option to rotate it most quickly (if we decide we want that), and the load balancing works out better than the other options I've heard (e.g. compared to choosing a slow 2nd level vanguard and then four 3rd level vanguards which don't help us much because the bottleneck is at the 2nd level). Oh, and finally, for those who don't know about phrases like "the downhill path algorithm", which was where many of these "multi hop guard" designs started, be sure to look through https://www.freehaven.net/anonbib/#ccs2011-trust Whew, --Roger
Hi George, On Wednesday 17 May 2017 05:21 PM, George Kadianakis wrote:
1.1. Visuals
Here is how a hidden service rendezvous circuit currently looks like:
-> middle_1 -> middle_A -> middle_2 -> middle_B -> middle_3 -> middle_C -> middle_4 -> middle_D HS -> guard -> middle_5 -> middle_E -> Rendezvous Point -> middle_6 -> middle_F -> middle_7 -> middle_G -> middle_8 -> middle_H -> ... -> ... -> middle_n -> middle_n
this proposal pins the two middles nodes to a much more restricted set, as follows:
-> guard_3A_A -> guard_2_A -> guard_3A_B -> guard_3A_C -> Rendezvous Point HS -> guard_1 -> guard_3B_D -> guard_2_B -> guard_3B_E -> guard_3B_F -> Rendezvous Point
Note that the third level guards are partitioned into buckets such that they are only used with one specific second-level guard. In this way, we ensure that even if an adversary is able to execute a Sybil attack against the third layer, they only get to learn one of the second layer Guards, and not all of them. This prevents the adversary from gaining the ability to take their pick of the weakest of the second-level guards for further attack.
I think this scheme works like if there are x number of third level guards, then they are divided into buckets of x/k number of guards each, where k is the number of second level guards. Now, I feel that dividing guards into buckets is a little pointless. Suppose we have 1000 possible third level guards, and 500 possible second level guards. We have to select 4 third level guards for each bucket, and 2 second level guard for each hidden service. Now even in this case the adversary has to do as much effort as before. What if the guards are divided into buckets, at least now the possible pool of third level guards in which the sybil attack is to be conducted get reduced. So the 1000 third level guards get divided into pool of 500 each. Hence easier to accomplish that attack, but for that the adversary has to allocate 2x resources if she wants to take advantage of that. So net result is zero. I haven't had my coffee, so please correct me if I'm wrong somewhere :) Regards, -- Jaskaran Veer Singh (jvsg) jvsg1303 at gmail dot com PGP 2814 3FB7 A32D 429B 092E 27F0 8AA3 C532 9E1A 6AD8
George Kadianakis wrote:
Hello,
here is some background information and summarizing of proposal 247 "Defending Against Guard Discovery Attacks using Vanguards" for people who plan to work on this in the short-term future.
Hello, I have discussed in Amsterdam briefly with David about this and want to further discuss it here where everyone can throw an eye on it. I have an idea to use a different technique that will replace the concept of vanguards and will only activate in case the hidden service might be under attack - I refer here to Hidden Service Guard Discovery Attack, which is currently fast, easy, (relatively, depending on adversary) cheap and effective. It will also address the load balancing questions we have in the context of using vanguards and make it much harder and more expensive for an adversary to mount a HS Guard Discovery attack. The main idea was discussed last year a little bit: https://lists.torproject.org/pipermail/tor-dev/2016-January/010291.html but its initial logic (banning a suspicious rendezvous point for a period of time) had some issues as pointed out by arma: https://lists.torproject.org/pipermail/tor-dev/2016-January/010292.html So, to mitigate those, we could do something different: Each hidden service server will keep in persistent memory the following information and always validate a rule before selecting the path for any rendezvous circuit: - total number of successfully established rendezvous circuits for the last 24 hours; - middle probability based on consensus weight fraction for each rendezvous relay in the list (if this value is less than 0.3, it defaults to 0.3); - hop 2 and 3 from the last circuit used to each rendezvous relay in the list; - number of successfully established rendezvous circuits per each rendezvous relay fingerprint in the last 24 hours. A table with the required columns would look like this: Fingerprint | Middle Prob | Last circ hop2,hop3 | num circs last 24 hrs A rendezvous relay is considered suspicious when the number of successfully established circuits in the last 24 hours per a certain rendezvous relay exceeds with more than x2 factor the number of expected circuits having that relay as rendezvous point. The number of expected circuits having a relay as rendezvous point is simply computed: n = total number of successfully established rendezvous circuits in the last 24 hours p = middle probability based on consensus weight fraction for a relay that is used as a rendezvous point / 100. Example: n = 1000 p = 0.032 / 100 = 0.00032 1000 * 0.00032 = 0.32. Let's further call this result Q. * If the result of this equation is < 5, we default to 5 (any relay is allowed to have at least 5 established rendezvous circuits in the last 24 hours). * If the result is not a whole number, we approximate to the next whole number regardless. (For example if the result is 5.03, we treat it as 6). The protection is triggered when the number of successfully established rendezvous circuits per a given rendezvous relay is greater than Q * 2. Part of an issue still remains: the attacker can grow the popularity of the hidden service (global number of established rendezvous circuits) by using dummy clients that build rendezvous circuits using random honest relays in order to grow the number of expected rendezvous circuits for his evil relay. At least this requires more resources, time and effort from the attacker, but maybe we can better mitigate it by setting a hard limit per fingerprint that will trigger the protection regardless the global number of established rendezvous circuits. It's hard to come with a right number here without relying on something dynamic (such as the total number of established circuits) - for example we currently have a relay with 0.8% probability in the consensus, this means that out of 1.000.000 rendezvous circuits, 8000 clients could have genuinely selected it as rendezvous point. It is very hard to come up with a proper estimation for how many total rendezvous circuits we expect in a given time frame. When a relay triggers it, instead of banning it and refusing to use it any longer, we just use hop 2 and hop 3 from the last circuit to further build new rendezvous circuits with this relay as rendezvous point for a random period between 24 to 72 hours. This ensures we mitigate the issue where the attacker DoS-es the HS by making all the relays in the consensus suspicious by hitting the limit for every relay, one by one. If during this period either hop 2 and hop 3 disappear from the consensus or fail to build circuits we replace the one missing or not being usable after one retry. Note that I suggest to only remember hop 2 and hop 3 because the Guard rotation period should be independent from this. It is assumed that the protection is not usually triggered, only in exceptional cases (a normal Tor client will just randomly pick rendezvous points based on middle probability, this should not be able to trigger the protection). In the exceptional cases where we reuse hop 2 and hop 3 of the last circuit for a 24 to 72 hours period, the load balancing issues shouldn't be a problem given we talk about isolated cases. One question: Are we creating an additional risk by keeping this additional information (hop2, hop3 of every rendezvous circuit) on the hidden service server side? How useful can this historic information be for an attacker that comes aware of the location of the hidden service? We already keep this information regarding the Guard. From my point of view this is irrelevant, given this information only becomes available after the location of the hidden service is already discovered (which is pretty much maximum damage). Thanks.
On 3 Jul 2017, at 06:02, s7r <s7r@sky-ip.org> wrote:
George Kadianakis wrote:
Hello,
here is some background information and summarizing of proposal 247 "Defending Against Guard Discovery Attacks using Vanguards" for people who plan to work on this in the short-term future.
Hello,
I have discussed in Amsterdam briefly with David about this and want to further discuss it here where everyone can throw an eye on it. I have an idea to use a different technique that will replace the concept of vanguards and will only activate in case the hidden service might be under attack - I refer here to Hidden Service Guard Discovery Attack, which is currently fast, easy, (relatively, depending on adversary) cheap and effective. It will also address the load balancing questions we have in the context of using vanguards and make it much harder and more expensive for an adversary to mount a HS Guard Discovery attack.
The main idea was discussed last year a little bit: https://lists.torproject.org/pipermail/tor-dev/2016-January/010291.html
but its initial logic (banning a suspicious rendezvous point for a period of time) had some issues as pointed out by arma: https://lists.torproject.org/pipermail/tor-dev/2016-January/010292.html
I recommend people interested in this proposal re-read the old thread. It contains several objections, many of which apply to this proposal as well.
...
A rendezvous relay is considered suspicious when the number of successfully established circuits in the last 24 hours per a certain rendezvous relay exceeds with more than x2 factor the number of expected circuits having that relay as rendezvous point.
Why 2x? Is it just a number you picked? In general, why the particular numbers in this proposal? Are they just guesses (most of our proposal numbers are), or are they evidence-based?
...
When a relay triggers it, instead of banning it and refusing to use it any longer, we just use hop 2 and hop 3 from the last circuit to further build new rendezvous circuits with this relay as rendezvous point for a random period between 24 to 72 hours. This ensures we mitigate the issue where the attacker DoS-es the HS by making all the relays in the consensus suspicious by hitting the limit for every relay, one by one.
Here's an attack that's enabled by this proposal: 1. Send lots of traffic through various rend points until you trigger the limit on a particular hop2 or hop3 or rend you control. 2. Stop sending traffic on that particular rend. 3. Observe encrypted client traffic/paths on hop2, hop3 or rend for 24 to 72 hours. 4. When hop2 or hop3 rotate, repeat from 1. This attack can be performed in parallel on multiple rend points for the same service, and only needs to succeed once. How much effort would it take to bind all the rend points in the consensus to a particular hop2, hop3 for a service? (I think the minimum answer is min(Q) * count(rend), or about 15000-20000 connections.) Why not just use this defence (slow hop2, hop3 rotation) all the time? If we did, that makes this attack pointless, because you can't keep rotating hop2, hop3 fast until you get the ones you want. Why not also use this defence (slow hop2, hop3 rotation) for clients? In the last thread, you said that clients can't be forced to make circuits. But with features like refresh and JavaScript, this just isn't true. In general, how do we know the suspicion thresholds are right? Also, in general, it is harder to test and maintain software that changes its behaviour in rare circumstances. That doesn't mean this is a bad design: just that it costs extra to do right and make sure it's right. How would you test this?
...
It is assumed that the protection is not usually triggered, only in exceptional cases (a normal Tor client will just randomly pick rendezvous points based on middle probability, this should not be able to trigger the protection). In the exceptional cases where we reuse hop 2 and hop 3 of the last circuit for a 24 to 72 hours period, the load balancing issues shouldn't be a problem given we talk about isolated cases.
How much would it cost an attacker to *not* make it an isolated case? Could an attacker bring down a relay by making multiple hidden services go through a hop2 or hop3? For example: 1. Perform the attack above until the victim relay is in the hop3 position (with a malicious rend point, the client knows hop3). 2. Repeat 1 with a different service and the same malicious rend point. Also, Tor2web with Tor2webRendezvousPoints will always trigger this case, as I said in response to the last proposal: (for "break" read "trigger on")
* This will break some Tor2Web installations, which deliberately choose rendezvous points on the same server or network for latency reasons. (Forcing Tor2Web installations to choose multiple RPs may be a worthwhile security tradeoff.)
https://lists.torproject.org/pipermail/tor-dev/2016-January/010293.html I won't repeat the entire thread here, but if this protection will always be triggered when Tor2webRendezvousPoints is on, please document that in the proposal, and talk about the load balancing implications. (Tor2webRendezvousPoints allows a Tor2web client to chose set rendezvous points for every connection. Please re-read the thread or the tor man page for details.)
One question: Are we creating an additional risk by keeping this additional information (hop2, hop3 of every rendezvous circuit) on the hidden service server side? How useful can this historic information be for an attacker that comes aware of the location of the hidden service?
It provides the entire path to the rendezvous point. This is useful for an attacker that knows the rendezvous point. It is also useful for an attacker whose priority is to locate clients, rather than locate the service.
We already keep this information regarding the Guard. From my point of view this is irrelevant, given this information only becomes available after the location of the hidden service is already discovered (which is pretty much maximum damage).
... to the hidden service, not necessarily its clients. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
Hello Tim, Thank you very much for the comments. Please see my inline answers as I think I didn't explain good enough, most of the issues are not actually a problem. teor wrote:
...
A rendezvous relay is considered suspicious when the number of successfully established circuits in the last 24 hours per a certain rendezvous relay exceeds with more than x2 factor the number of expected circuits having that relay as rendezvous point.
Why 2x? Is it just a number you picked?
In general, why the particular numbers in this proposal? Are they just guesses (most of our proposal numbers are), or are they evidence-based?
The numbers are not evidence based. I have picked the 2x factor to allow a margin for rare cases when genuine clients honestly pick a rendezvous relay more than its probability calculated considering its consensus weight. There is a nonzero chance this can (rarely) happen, because the probability calculation does not ensure 100% fixed accurate result so the 2x factor was chosen to minimize its impact as much as possible while maintaining a reasonable level of protection.
...
When a relay triggers it, instead of banning it and refusing to use it any longer, we just use hop 2 and hop 3 from the last circuit to further build new rendezvous circuits with this relay as rendezvous point for a random period between 24 to 72 hours. This ensures we mitigate the issue where the attacker DoS-es the HS by making all the relays in the consensus suspicious by hitting the limit for every relay, one by one.
Here's an attack that's enabled by this proposal: 1. Send lots of traffic through various rend points until you trigger the limit on a particular hop2 or hop3 or rend you control. 2. Stop sending traffic on that particular rend. 3. Observe encrypted client traffic/paths on hop2, hop3 or rend for 24 to 72 hours. 4. When hop2 or hop3 rotate, repeat from 1.
This attack can be performed in parallel on multiple rend points for the same service, and only needs to succeed once.
I am not sure I understand the attack. You cannot get to choose to trigger the limit on particulars hop2 and hop3. These are chosen by the hidden service server side (where the protection is implemented), they are chosen randomly, and when you trigger the limit on a particular rendezvous relay, the last hop 2 and hop 3 used to connect to that particular relay as RP are used for further new rend circuits only with that RP, circuits for other rendezvous relays that did not hit the limit are unaffected and chosen randomly as in normal conditions. If multiple rendezvous relays hit the limit at the same time, each one will have different hop 2 and hop 3 static paths for the given period. It is exactly like vanguards, except it is activated only under some conditions and we have different Vanguards for each suspicious rendezvous relay.
How much effort would it take to bind all the rend points in the consensus to a particular hop2, hop3 for a service? (I think the minimum answer is min(Q) * count(rend), or about 15000-20000 connections.)
I believe this is answered above, you cannot bind all the rend points in the consensus to particular hop 2 and hop 3 for a service, each rend point will have its own hop 2 and hop 3, the ones used in the last circuit before the limit was reached and protection triggered.
Why not just use this defence (slow hop2, hop3 rotation) all the time? If we did, that makes this attack pointless, because you can't keep rotating hop2, hop3 fast until you get the ones you want.
Why not also use this defence (slow hop2, hop3 rotation) for clients? In the last thread, you said that clients can't be forced to make circuits. But with features like refresh and JavaScript, this just isn't true.
Clients are not subject to this attack (HS Guard Discovery attack). This is why they are not addressed. Clients choose the RP and request the HS to connect to it, as much as they want, without any limit. If you mean a malicious honeypot HS trying to de-anonymize clients or mount Guard Discovery attacks on clients, the chances for such an attack to succeed are orders or magnitude lower than vice versa, because the hidden service cannot make the client connect to an evil RP (RP is selected by the client).
In general, how do we know the suspicion thresholds are right?
From my point of view they should be pretty right, based on a simple logic: a relay is selected by a client in a path based on its consensus weight fraction and position probability (guard, middle, exit). So, out of a given number of circuits a relay should appear in a position somewhere close to its position probability (more or less, which is why we use the 2x factor). You can test in practice, create 10000 rend circuits using the last consensus and take the relay that was chosen mostly, you will see that one has the highest middle probability. We consider the probability theory is tested and worthy of taking into consideration of course, we rely on it for this protection to work. I think we can safely do this.
Also, in general, it is harder to test and maintain software that changes its behaviour in rare circumstances. That doesn't mean this is a bad design: just that it costs extra to do right and make sure it's right. How would you test this?
I understand this can be a PITA from engineering point of view, we just have to put in balance and see if it's worth it and if it helps us more than Vanguards do, eliminate the load balancing problems and at the same time gain some other benefits. I don't see it MUCH more complicated than the vanguards proposal to be honest, it's just some more information we need to keep track of and validate a single rule before creating rendezvous circuits from hidden service server side only (not applied to HS client mode).
It is assumed that the protection is not usually triggered, only in exceptional cases (a normal Tor client will just randomly pick rendezvous points based on middle probability, this should not be able to trigger the protection). In the exceptional cases where we reuse hop 2 and hop 3 of the last circuit for a 24 to 72 hours period, the load balancing issues shouldn't be a problem given we talk about isolated cases.
How much would it cost an attacker to *not* make it an isolated case? Could an attacker bring down a relay by making multiple hidden services go through a hop2 or hop3?
No, an attacker cannot do it because he does not get to choose hop 2 and hop 3 as described above. An attacker can mostly make all rend points in the consensus have different static paths (hop 2 and hop 3) for a random short period. This requires some effort, since the attacker needs to take all the rend points one by one and trigger the limit on each. It gets even more complicated when the HS is popular, because more and more circuits are needed to trigger the limit on a particular rendezvous relay. Also, the number of circuits an attacker needs to do to trigger the limit grows exponentially, because as he hits the limit on some rend points the total number of established circuits grow, thus requiring more and more rend circuits to trigger the limit on new RPs. Even if we come to this, having static hop 2 and hop 3 (different ones) for each RP in the consensus for a random period of time the result is exactly as if we were using vangaurds in the first place, except: -> we talk about different hop 2 and hop 3 for each RP, so we have considerably less load balancing problems and we do not need to care about vanguard flag or logic for selecting which relays to use as vanguards. - > the protection is no active all the time for all the hidden services existing in the network, it is only active in some conditions we consider suspect, as described above. It is unclear how different is having the same hop 2 and hop 3 for each rend circuit (with any rend point) for a random period of time as vanguards proposal suggests better than this.
For example: 1. Perform the attack above until the victim relay is in the hop3 position (with a malicious rend point, the client knows hop3). 2. Repeat 1 with a different service and the same malicious rend point.
This method always assumes the rend point is evil, this should be the default thinking anyway since it's selected by the client all the time, and when an attacker wants to de-anonymize a hidden service, he is always obviously a client. In the described attack, say you are the attacker and control rend point X: HS -> Guard -> random_hop2 -> random_hop3 -> RP (X) You know hop 3 of course. Now say you control some hostile consensus weight in the network and try your chances to get be picked as hop3, with the same X rend point so you learn hop 2. So you request more and more rend circuits having the same evil RP. The HS will grant you more circuits: HS -> Guard -> random_hop2 -> random_hop3 -> RP (X) HS -> Guard -> random_hop2 -> random_hop3 -> RP (X) HS -> Guard -> random_hop2 -> random_hop3 -> RP (X) [...] Until the limit is triggered for your RP (X), based on its consensus weight middle probability and total number of rend circuits established by that hidden service from server side. When the limit is triggered, you will have this: HS -> Guard -> static_hop2 -> static_hop3 -> RP (X) Hop 2 and 3 will be static for a random period with that RP(X), and your tries are finished for being chosen in hop 3 position. Now you have to either wait, until the random period for RP (X) runs out, either try a different hostile RP you control. Soon you will hit the limit on the second hostile RP as well. As you can see this clearly makes it harder and requires more time and resources from the attacker, while not affecting the hidden service in any way. Why the load balancing is not a problem here? When a RP is marked as suspicious and 2 relays act as hop 2 and hop 3 only for rend circuits to this particular RP, the only circuits being created here are: -> the circuits requested by the attacker, controlling the suspect RP -> the circuits requested by honest clients, that randomly pick the suspect RP under normal conditions (since this is based on its middle probability, we are not talking about concerning numbers).
Also, Tor2web with Tor2webRendezvousPoints will always trigger this case, as I said in response to the last proposal: (for "break" read "trigger on")
* This will break some Tor2Web installations, which deliberately choose rendezvous points on the same server or network for latency reasons. (Forcing Tor2Web installations to choose multiple RPs may be a worthwhile security tradeoff.)
https://lists.torproject.org/pipermail/tor-dev/2016-January/010293.html
I won't repeat the entire thread here, but if this protection will always be triggered when Tor2webRendezvousPoints is on, please document that in the proposal, and talk about the load balancing implications.
(Tor2webRendezvousPoints allows a Tor2web client to chose set rendezvous points for every connection. Please re-read the thread or the tor man page for details.)
Exactly. Allows a Tor2web _client_ to set rendezvous point for every connection. Nothing will break here. What will happen is if a Tor2Web service is popular and many users browse via that Tor2Web proxy a particular hidden service, that hidden service will at some point trigger the limit and have static hop 2 and hop 3 to the Tor2webRendezvousPoints selected by this particular Tor2Web client. They will be rotated after some time of course. There is absolutely no problem here and the Tor2web clients will not even notice it.
One question: Are we creating an additional risk by keeping this additional information (hop2, hop3 of every rendezvous circuit) on the hidden service server side? How useful can this historic information be for an attacker that comes aware of the location of the hidden service?
It provides the entire path to the rendezvous point. This is useful for an attacker that knows the rendezvous point. It is also useful for an attacker whose priority is to locate clients, rather than locate the service.
We already keep this information regarding the Guard. From my point of view this is irrelevant, given this information only becomes available after the location of the hidden service is already discovered (which is pretty much maximum damage).
... to the hidden service, not necessarily its clients.
Yes, but we only have info, from the hidden service server side for the path to the RP: HS - Guard - hop2 - hop3 - RP On the other hand, there's also: RP <- Hop 2 <- HS client Guard <- HS client So we don't actually know much. The design assumes anyway a HS can be malicious, which is why the client selects the RP and makes a 2 hop circuit to it, while the HS server makes a 3 hop circuit to the RP because it was chosen by someone else. if logging this information (hop2, hop3 and all rend points used) at hidden service server side is risky, this means all clients connecting to honey pot HSes are at risk? I doubt this.
s7r <s7r@sky-ip.org> writes:
George Kadianakis wrote:
Hello,
here is some background information and summarizing of proposal 247 "Defending Against Guard Discovery Attacks using Vanguards" for people who plan to work on this in the short-term future.
Hello,
I have discussed in Amsterdam briefly with David about this and want to further discuss it here where everyone can throw an eye on it. I have an idea to use a different technique that will replace the concept of vanguards and will only activate in case the hidden service might be under attack - I refer here to Hidden Service Guard Discovery Attack, which is currently fast, easy, (relatively, depending on adversary) cheap and effective. It will also address the load balancing questions we have in the context of using vanguards and make it much harder and more expensive for an adversary to mount a HS Guard Discovery attack.
The main idea was discussed last year a little bit: https://lists.torproject.org/pipermail/tor-dev/2016-January/010291.html
but its initial logic (banning a suspicious rendezvous point for a period of time) had some issues as pointed out by arma: https://lists.torproject.org/pipermail/tor-dev/2016-January/010292.html
So, to mitigate those, we could do something different:
Each hidden service server will keep in persistent memory the following information and always validate a rule before selecting the path for any rendezvous circuit: - total number of successfully established rendezvous circuits for the last 24 hours; - middle probability based on consensus weight fraction for each rendezvous relay in the list (if this value is less than 0.3, it defaults to 0.3); - hop 2 and 3 from the last circuit used to each rendezvous relay in the list; - number of successfully established rendezvous circuits per each rendezvous relay fingerprint in the last 24 hours.
A table with the required columns would look like this: Fingerprint | Middle Prob | Last circ hop2,hop3 | num circs last 24 hrs
A rendezvous relay is considered suspicious when the number of successfully established circuits in the last 24 hours per a certain rendezvous relay exceeds with more than x2 factor the number of expected circuits having that relay as rendezvous point.
Hello s7r, and thanks for helping with this and approaching it from a different direction. Personally, I'd be really surprised if any solution that statistically marks relays or paths as "suspicious" will ever work for this particular problem. That's because the adversary does not need that many paths to succeed, and also because the adversary has lots of time to carry out the attack. I also dislike these solutions since the HS operator cannot really distinguish between an actual attack that just happened, or their HS getting slashdotted, or someone trolling them by connecting a thousand times. Furthermore, I don't understand why your proposal marks rendezvous points as suspicious, and not the paths themselves. After all, the attacker can choose a diffferent rendezvous point everytime, as long as the HS makes fresh circuits for each one. Also if you are suggesting the reuse of hops 2 and 3 for multiple circuits, you are basically suggesting a layered guard approach which is what prop247 also tries to do, and FWIW it's not simple at all (especially from an engineering perspective). Cheers!
Hi George, George Kadianakis wrote:
Hello s7r,
and thanks for helping with this and approaching it from a different direction.
Personally, I'd be really surprised if any solution that statistically marks relays or paths as "suspicious" will ever work for this particular problem. That's because the adversary does not need that many paths to succeed, and also because the adversary has lots of time to carry out the attack. I also dislike these solutions since the HS operator cannot really distinguish between an actual attack that just happened, or their HS getting slashdotted, or someone trolling them by connecting a thousand times.
Furthermore, I don't understand why your proposal marks rendezvous points as suspicious, and not the paths themselves. After all, the attacker can choose a diffferent rendezvous point everytime, as long as the HS makes fresh circuits for each one.
Also if you are suggesting the reuse of hops 2 and 3 for multiple circuits, you are basically suggesting a layered guard approach which is what prop247 also tries to do, and FWIW it's not simple at all (especially from an engineering perspective).
This should be invisible for the HS operator. It should not be noticed. Trolling with a HS is something which happens now also, and we cannot stop, if that HS is accessible to the world. If someone will troll, worst case it hits the limit for some (or many) RPs in the consensus, and makes the HS server use static hop 2 and hop 3 for a random period of time, which is exactly what vanguards does except it does it by default under any circumstances and with all the RPs, not just the suspicious ones. There should be no tradeoff here. If the attacker doesn't control the RP, he should not be able to learn hop 3 (unless we are talking about adversaries that are able to watch a huge part of the network at the same time, which is a different attack harder to mitigate) which is why this protection assumes the RP is evil and defends against it by making it hard to learn hop 3 and hop 2, directly leading to making it very hard to learn the HS server Guard. I am not suggesting to reuse hop 2 and hop 3 for multiple circuits, only for rend circuits with a suspicious RP point. If we have more suspicious RP points at the same time, we have different hop 2 and hop 3 for each, for a random period of time (Please see my previous longer email sent in reply to teor for something more clear). I understand this might not be simple at all from engineering perspective. I only wanted to discuss it in depth so that we can decide if it's worth it, if it brings us more benefits than tradeoffs. If we decide it's not worth it, we'll move on with the vanguards proposal and brainstorm for a good selection logic that load balances properly. Either way, there are ways we can do HS guard discovery harder and more expensive for attackers, and we'll surely do it! Thanks for the time! Always a pleasure.
participants (5)
-
George Kadianakis -
Jaskaran Singh -
Roger Dingledine -
s7r -
teor