One missing piece of rend-spec-ng.txt [0] is a section on how HSes should pick their Introduction Points (IPs). There are three main questions here: - How many IPs should an HS have? - Which relays can be IPs? - What's the lifetime of an IP?
==Introduction Points attacks==
Before exploring these questions it's a good idea to state a rough threat model for IPs. First, let's get a visual taste, here is how IPs work in the current HS protocol: https://people.torproject.org/~asn/hs/ip_placement_currently.jpg (number of IPs reduced to 2 to make it more readable)
As you can see, IPs are in a good position to conduct any of the following attacks:
a) IPs can count the number of introductions for a subset of clients (i.e. in the figure above, IP_1 would be able to count introductions from the clients above it). Since clients pick IPs uniformly at random, it's not hard to extrapolate from that to the total number of introductions.
b) IPs have presense information about the HS. That is, they know whether the HS is up or down at a given time since they have a long-term stable circuit to it.
FWIW, regular clients also have this ability by continuously "pinging" the HS and noticing when it's down.
And, of course, an attacker who controls all the IPs of an HS can trivially DoS the HS (till the HS refreshes its IPs).
Furthermore, as part of the Next Generation HSes initiative [0], we are considering enhancing the availability of HSes by allowing multiple nodes per Hidden Service. A plausible idea for achieving that is to allow multiple IP circuits per Introduction Point, as explained in [tor-dev] by Christopher Baines [1]. This means that IPs would work like this: https://people.torproject.org/~asn/hs/ip_placement_scaling.jpg where HS_1, HS_2 and HS_3 are the various nodes of the HS.
This allows the IPs to launch the following attacks:
a) IPs can learn the number of nodes of an HS, by counting the number of IP circuits on them. Also, the IPs can learn the prsense of the nodes of an HS, by looking at the state of their circuit.
b) IPs can choose which HS node will receive traffic.
==How many IPs should an HS have?==
Now let's investigate how many IPs an HS should have.
The current situation is that HSes attempt to estimate their own popularity [2], and then they launch a number of IPs between 3 and 10 depending on how popular they think they are. FWIW, we don't really understand whether the formula works properly [3].
There are a few options for the future here:
a) Fix the formula and keep number of IPs dynamic based on the popularity of the HS.
This is not a bad idea. However, we should make sure that from the number of IPs you can't easily derive the number of clients of the HS. Also we should make sure that the formula works properly.
b) Have a static amount of IPs per HS. For example '5' of them.
I'm not sure what kind of calculations we need to do to find the right constant here (same for the (a) option).
c) Have a static amount of IPs per HS, but also allow this to be configurable by the HS operator.
The idea here is that popular HSes can pump up the number of IPs to make the service more reachable. It's worth noting that HSes who do so will stand out as manually configured; not sure if any other partition attacks can happen here. Also, there is also the danger of all HS operators thinking they are special and pumping the number of IPs to 42.
Generally, we want to have a healthy amount of IPs (so that they don't get DoSed, and that requests get load balanced nicely), but also not too many because every HS having many IP circuits will put a load to the network (especially with services like Torchat where each client is an HS), and also because we want to avoid too many nodes becoming our IPs over time (more on this below).
==Which relays can be IPs?==
This seems to be the easiest question here and Tor is currently handling it well by only restricting IPs to be Stable nodes [4].
This means that with the current network, we have about 4000 possible IPs to choose from [5].
This makes sense since we want to maximize the set of possible IPs, but we also want them to be stable to decrease their natural churn.
==What's the lifetime of an IP?==
Another hard question: How long should we keep IPs for?
Currently, Tor keeps IPs for a random time between 18 to 24 hours [6].
This seems like too short of a period if we actually want to protect against adversarial nodes ever becoming our IPs: Consider an HS with 5 IPs that rotates them every 24 hours, in only two months it will use 300 nodes as IPs plus the natural churn (which is not negligible at all).
With that in mind we need to look at all the possible attacks that IPs could launch and decide whether they should be short-lived or long-lived. For example, waldo in a related thread [7] [8] asks for short-lived IPs, but recent entry guard research has shown that making guards more long-lived is actually beneficial for security [9].
I'm personally leaning towards more long-lived IPs but I still don't know what our constants should be. I could see anything from a week, to a month, to 5 months as reasonable IP lifetimes.
We also need to look at INTRO_POINT_LIFETIME_INTRODUCTIONS, since apparently in the current code, IPs will expire on their own if they perform more than 16384 introductions.
==Conclusion==
I hope that this thread serves as a good start on discussing Introduction Point security. After we take some decisions, we will need to write them down as a proposal and incorporate them in rend-spec-ng.txt.
Also, this thread does not explore other IP matters, like how many HS nodes should correspond to each IP if we go ahead with the scaling ideas [10]. I decided to not include this in the discussion, so that we keep it simple and also so that we don't focus on a particular scaling scheme.
References:
[0]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spec...
[1]: https://lists.torproject.org/pipermail/tor-dev/2014-April/006788.html
[2]: https://gitweb.torproject.org/tor.git/blob/ab3d5c049032651a9c9164262f9a8f81d...
[3]: https://trac.torproject.org/projects/tor/ticket/8950
[4]: https://gitweb.torproject.org/tor.git/blob/bb68c731b897a967a4b7eb138728fa077...
[5]: https://metrics.torproject.org/network.html#relayflags
[6]: https://gitweb.torproject.org/tor.git/blob/bb68c731b897a967a4b7eb138728fa077... https://gitweb.torproject.org/tor.git/blob/bb68c731b897a967a4b7eb138728fa077...
[7]: https://lists.torproject.org/pipermail/tor-dev/2014-May/006815.html
[8]: waldo also mentions an IP guard discovery attack in another reply of his: https://lists.torproject.org/pipermail/tor-dev/2014-May/006843.html
However, I'm not sure if it's actually doable, since I think that HSes will discard an IP that has failed a circuit. We need to look into this more seriously.
[9]: https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-par...
[10]:https://lists.torproject.org/pipermail/tor-dev/2013-October/005615.html https://lists.torproject.org/pipermail/tor-dev/2013-October/005683.html
On 12/08/14 12:05, George Kadianakis wrote:
One missing piece of rend-spec-ng.txt [0] is a section on how HSes should pick their Introduction Points (IPs). There are three main questions here:
- How many IPs should an HS have?
- Which relays can be IPs?
- What's the lifetime of an IP?
There might be one additional question that you might want to consider considering, that of reconnecting to introduction points? [1]
1: https://trac.torproject.org/projects/tor/ticket/8239
This functionality is required for the particular HS scaling architecture discussed below.
Furthermore, as part of the Next Generation HSes initiative [0], we are considering enhancing the availability of HSes by allowing multiple nodes per Hidden Service. A plausible idea for achieving that is to allow multiple IP circuits per Introduction Point, as explained in [tor-dev] by Christopher Baines [1]. This means that IPs would work like this: https://people.torproject.org/~asn/hs/ip_placement_scaling.jpg where HS_1, HS_2 and HS_3 are the various nodes of the HS.
This allows the IPs to launch the following attacks:
a) IPs can learn the number of nodes of an HS, by counting the number of IP circuits on them. Also, the IPs can learn the prsense of the nodes of an HS, by looking at the state of their circuit.
b) IPs can choose which HS node will receive traffic.
On Tue, Aug 12, 2014 at 02:05:49PM +0300, George Kadianakis wrote:
One missing piece of rend-spec-ng.txt [0] is a section on how HSes should pick their Introduction Points (IPs). There are three main questions here:
- How many IPs should an HS have?
- Which relays can be IPs?
- What's the lifetime of an IP?
--Snip--
==How many IPs should an HS have?==
Now let's investigate how many IPs an HS should have.
The current situation is that HSes attempt to estimate their own popularity [2], and then they launch a number of IPs between 3 and 10 depending on how popular they think they are. FWIW, we don't really understand whether the formula works properly [3].
There are a few options for the future here:
a) Fix the formula and keep number of IPs dynamic based on the popularity of the HS.
This is not a bad idea. However, we should make sure that from the number of IPs you can't easily derive the number of clients of the HS. Also we should make sure that the formula works properly.b) Have a static amount of IPs per HS. For example '5' of them.
I'm not sure what kind of calculations we need to do to find the right constant here (same for the (a) option).c) Have a static amount of IPs per HS, but also allow this to be configurable by the HS operator.
The idea here is that popular HSes can pump up the number of IPs to make the service more reachable. It's worth noting that HSes who do so will stand out as manually configured; not sure if any other partition attacks can happen here. Also, there is also the danger of all HS operators thinking they are special and pumping the number of IPs to 42.
There's also the choice "ac) allow the HS operator to set a fixed number or allow them to set an upper limit of IPs and let Tor dynamically allocate them depending on popularity". Many choices :)
Something else we can consider is publishing multiple versions of the HS descriptor, each containing a subset of IPs. An adversary will need to collect them all to see the full picture and know how popular the HS thinks it is. On the other hand, it is likely better for a HS operator to simply add more HS addresses when their popularity increases. This decreases the usability of the HS, though, and relies on users understanding why they should uniformly distribute their connections over the various connections.
Generally, we want to have a healthy amount of IPs (so that they don't get DoSed, and that requests get load balanced nicely), but also not too many because every HS having many IP circuits will put a load to the network (especially with services like Torchat where each client is an HS), and also because we want to avoid too many nodes becoming our IPs over time (more on this below).
We should consider profiling the affect of an IP circuit on the network. Granted, we shouldn't waste any unnecessary bandwidth on useless connections, but I wonder how much load is really added.
==What's the lifetime of an IP?==
Another hard question: How long should we keep IPs for?
Currently, Tor keeps IPs for a random time between 18 to 24 hours [6].
This seems like too short of a period if we actually want to protect against adversarial nodes ever becoming our IPs: Consider an HS with 5 IPs that rotates them every 24 hours, in only two months it will use 300 nodes as IPs plus the natural churn (which is not negligible at all).
With that in mind we need to look at all the possible attacks that IPs could launch and decide whether they should be short-lived or long-lived. For example, waldo in a related thread [7] [8] asks for short-lived IPs, but recent entry guard research has shown that making guards more long-lived is actually beneficial for security [9].
I'm personally leaning towards more long-lived IPs but I still don't know what our constants should be. I could see anything from a week, to a month, to 5 months as reasonable IP lifetimes.
The current period does seem to be too short. It's not as bad as the guard situation, so I don't think we need to keep them for multiple months. Something we could do is if we are still happy with an IP after the specified time period, we can generate a new service key and establish a new circuit with the same IP, and reuse it for one more period. We'd need a sufficiently random gap between destroying the IP circuit and recreating it with the new service key, so that would need some more investigation.
We also need to look at INTRO_POINT_LIFETIME_INTRODUCTIONS, since apparently in the current code, IPs will expire on their own if they perform more than 16384 introductions.
That seems like a magical number, I think we need to decide which attacks we are mitigating by counting this. Plus, as it currently stands, this will expire an IP if a HS receives 16K introductions from an IP within a max of 24 hours. This almost seems like a "Wow, we received a lot of client connections from this IP within a short period of time. We'd probably be stupid not to move to a new IP." Maybe there was other justification though :)
==Conclusion==
I hope that this thread serves as a good start on discussing Introduction Point security. After we take some decisions, we will need to write them down as a proposal and incorporate them in rend-spec-ng.txt.
Thanks for writing this.
References:
https://gitweb.torproject.org/tor.git/blob/bb68c731b897a967a4b7eb138728fa077617646e:/src/or/or.h#l4794[8]: waldo also mentions an IP guard discovery attack in another reply of his: https://lists.torproject.org/pipermail/tor-dev/2014-May/006843.html
However, I'm not sure if it's actually doable, since I think that HSes will discard an IP that has failed a circuit. We need to look into this more seriously.https://lists.torproject.org/pipermail/tor-dev/2013-October/005683.html
Matthew Finkel matthew.finkel@gmail.com writes:
On Tue, Aug 12, 2014 at 02:05:49PM +0300, George Kadianakis wrote:
One missing piece of rend-spec-ng.txt [0] is a section on how HSes should pick their Introduction Points (IPs). There are three main questions here:
- How many IPs should an HS have?
- Which relays can be IPs?
- What's the lifetime of an IP?
--Snip--
==How many IPs should an HS have?==
Now let's investigate how many IPs an HS should have.
The current situation is that HSes attempt to estimate their own popularity [2], and then they launch a number of IPs between 3 and 10 depending on how popular they think they are. FWIW, we don't really understand whether the formula works properly [3].
There are a few options for the future here:
a) Fix the formula and keep number of IPs dynamic based on the popularity of the HS.
This is not a bad idea. However, we should make sure that from the number of IPs you can't easily derive the number of clients of the HS. Also we should make sure that the formula works properly.b) Have a static amount of IPs per HS. For example '5' of them.
I'm not sure what kind of calculations we need to do to find the right constant here (same for the (a) option).c) Have a static amount of IPs per HS, but also allow this to be configurable by the HS operator.
The idea here is that popular HSes can pump up the number of IPs to make the service more reachable. It's worth noting that HSes who do so will stand out as manually configured; not sure if any other partition attacks can happen here. Also, there is also the danger of all HS operators thinking they are special and pumping the number of IPs to 42.There's also the choice "ac) allow the HS operator to set a fixed number or allow them to set an upper limit of IPs and let Tor dynamically allocate them depending on popularity". Many choices :)
Something else we can consider is publishing multiple versions of the HS descriptor, each containing a subset of IPs. An adversary will need to collect them all to see the full picture and know how popular the HS thinks it is. On the other hand, it is likely better for a HS operator to simply add more HS addresses when their popularity increases. This decreases the usability of the HS, though, and relies on users understanding why they should uniformly distribute their connections over the various connections.
Generally, we want to have a healthy amount of IPs (so that they don't get DoSed, and that requests get load balanced nicely), but also not too many because every HS having many IP circuits will put a load to the network (especially with services like Torchat where each client is an HS), and also because we want to avoid too many nodes becoming our IPs over time (more on this below).
We should consider profiling the affect of an IP circuit on the network. Granted, we shouldn't waste any unnecessary bandwidth on useless connections, but I wonder how much load is really added.
Right.
FWIW, the only rationale for `#define NUM_INTRO_POINTS_MAX 10` that I know about, is Robert's post: https://trac.torproject.org/projects/tor/ticket/4862#comment:13 .
Maybe we need to estimate the number of HSes we want the Tor network to be able to support, and then calculate how many circuits the Tor network can handle, and then...
-
Christopher Baines -
George Kadianakis -
Matthew Finkel