Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes
> HS -> Guard_1 -> Guard_2 -> Guard_3 -> RP. > > The idea is that Guard_1 is a single node that you choose and keep for > O(6 months, or as long as possible), but Guard_2 actually comes from a > set of 3-6 or so nodes that you keep for O(weeks), and Guard_3 you > rotate something like O(hours). ... > The hope behind my reasoning is that if it is incredibly likely for you > to rotate your guard(s) before they are discovered, guard discovery > attacks lose their value. This doesn’t make sense - do you mean "if it is likely for you to rotate your guards *after” they are discovered"? > OTOH, perhaps I am reasoning about this wrong, and it is operationally > better to stick with a guard node in the second position for as long as > you stick with your first guard. In my mind, having identical rotation > periods is only better if you subscribe to the theory that compromising > a node is a noisy process, and unlikely to succeed in repeated > succession. In which case, you probably just want a static route of > exactly three (and only three) guard nodes, fixed for the lifetime of > your HS. At least, if you want the most security in this threat model. > > Does this make sense? I don’t follow your reasoning. Even if compromising is a completely deterministic process, it would be better to have one quickly rotating node at the end of the HS-side circuit because if each hop rotated slowly the adversary would have enough time upon discovery of each hop to set up surveillance of the next (where the last hop is always immediately discovered by the adversarially-chosen RP). Having a quickly-rotating final hop from the HS means the adversary has to wait until the HS rotates to an adversarially-controlled relay. > Do you subscribe to the "it's cumbersome and noisy to compromise a node > (and therefore you should sit on your routes as long as possible until > they break)" threat model, or the "it's likely quiet and/or quick (and > therefore all we can do is try to improve the statistics to reduce the > likelihood of compromise early in the rotation period)" threat model? Or > is there an additional threat model/goal we should be aiming to satisfy > here? I do actually suspect that it's cumbersome and noisy, but the solution I have argued for doesn’t depend on that (indeed, it is based on a deterministic compromise model). > It sounds like you subscribe to the first "it's cumbersome to compromise > a node, so keep a fixed route" threat model and goal, right? Would it > make you more nervous if the exit was also fixed? If so, why? If not, > why not? As I was saying above, a fixed exit would allow compromise in the time it takes to begin surveillance (times three). We can likely do better than that. Aaron ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes
A. Johnson: > >> The idea would be that Guard_3 would rotate on the order of hours, > >> Guard_2 would come from a set that is rotated on the order of days > >> (based on the expected duration for the adversary to become > >> Guard_3), and Guard_1 would rotate on the order of months (based on > >> the expected duration for the adversary to become Guard_2). > > > > Why set guard 2 to expire in days? If that is less than surveillance > > speed, then once the adversary had guard 3, it’s game over. > > Sorry, I should have stated this more clearly as "If that is greater > than the time needed for surveillance”. And I can imagine rotating > guard 2 faster than guard 1 for performance reasons (faster rotation > more quickly takes advantage of new capacity in the network). But the > only reason that I can see treating guard 2 differently than guard 1 > is that you judge the “cost" of the attack starting from guard 2 to be > higher, thus compensating for the increase in attack speed. That is, > if guard 2 rotates to a malicious relay, the adversary still has to > identify and then do a targeted compromised of guard 1, while if a > malicious relay is selected as guard 1, then the target HS can be > relatively easily observed directly. Such an argument is hard to > evaluate carefully, because the costs in terms of added technical and > legal complexity are hard to estimate. For example, at what point is > it “cheaper" to run more malicious nodes and/or wait longer in hopes > of obtaining guard 1 than to try and identify guard 2 but then have to > perform surveillance on an identified guard 1? Well, based on your analysis, I was actually proposing a hybrid scheme somewhere between "virtual circuits" (which win out for load balancing) and "two layers of single guards" (which may win out for security, but only if you make certain assumptions about how the adversary can compromise nodes). Going back to my diagram: HS -> Guard_1 -> Guard_2 -> Guard_3 -> RP. The idea is that Guard_1 is a single node that you choose and keep for O(6 months, or as long as possible), but Guard_2 actually comes from a set of 3-6 or so nodes that you keep for O(weeks), and Guard_3 you rotate something like O(hours). The reason they then are "treated differently" in terms of rotation lifespan is that this hybrid scheme naturally exposes you to more of the network in a given time period in the Guard_2 position, and even more in the Guard_3 position. So these two positions would have shorter durations for a given probability of compromise (by selecting a malicious node), simply because they rotate faster. In other words, these timespans are based entirely on compromise probabilities over many rotation periods, and have less to do with how long it takes to compromise a node once you discover it. The hope behind my reasoning is that if it is incredibly likely for you to rotate your guard(s) before they are discovered, guard discovery attacks lose their value. OTOH, perhaps I am reasoning about this wrong, and it is operationally better to stick with a guard node in the second position for as long as you stick with your first guard. In my mind, having identical rotation periods is only better if you subscribe to the theory that compromising a node is a noisy process, and unlikely to succeed in repeated succession. In which case, you probably just want a static route of exactly three (and only three) guard nodes, fixed for the lifetime of your HS. At least, if you want the most security in this threat model. Does this make sense? > So I would argue to protect guard 2 as much as guard 1, and then look > for other, better understood, methods to improve performance. Some fun > methods that come to mind are (i) carefully choosing number of primary > and secondary guards and (ii) trying to reduce the HS path length, and > (iii) allowing HSes to pay for improved performance (yes, I haven’t > given up on this idea, haha). Exposing to the HS operator the options > controlling the security/performance tradeoff may also be a good > option. Do you subscribe to the "it's cumbersome and noisy to compromise a node (and therefore you should sit on your routes as long as possible until they break)" threat model, or the "it's likely quiet and/or quick (and therefore all we can do is try to improve the statistics to reduce the likelihood of compromise early in the rotation period)" threat model? Or is there an additional threat model/goal we should be aiming to satisfy here? It sounds like you subscribe to the first "it's cumbersome to compromise a node, so keep a fixed route" threat model and goal, right? Would it make you more nervous if the exit was also fixed? If so, why? If not, why not? If we agree that is the best threat model (and I'm not fully convinced yet, but I could be), then it does sound like we're arriving at three or four different path selection algorithms that are successively worse for security under this threat model, but better for
Re: [tor-dev] Hidden Service authorization UI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/11/14 12:50, George Kadianakis wrote: > I suspect that HS authorization is very rare in the current > network, and if we believe it's a useful tool, it might be > worthwhile to make it more useable by people. For what it's worth, the reason I haven't (so far) implemented HS authorization for Briar is that it's inconvenient to manage the list of auth cookies (effectively a second copy of the controlling app's contact list) via the control port. It would be really nice if the controlling app could store the auth cookies itself and supply the relevant cookie when making a SOCKS connection. The SOCKS password field seems like a natural fit, but I think perhaps Tor's already using the username and password for some other purpose? Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUYjENAAoJEBEET9GfxSfMJz4H/iAHIn02IbkyjFEPYko2IIg/ ms6uTABTHm1VkF+UgrKejlNwYO/aVpPmeWGjohCrbqDbxw1PQdYVBncOyL1pLWa3 KkKYsyfoREGkp0/PR/jsRic3dopzp5wVKC2jT9ujVVrH1+Al1iG6f4feI6kmv4R+ jaXrjd4g57NnLpYlFwB8DMeLm/+Q5tWWp42pjNyy6edL+H06TDOe85ivcYsfzrbb BmMJexNvspKsmN5lDaG402TVnrmHaxJCj/ZaPBvQdEXDjOMQQD4MLM8eZYMY3nYA 23SW3QiXERqdg7jf8l2cLZNZyeTyYhZTRjbkySbsCwRWLN/UgE/s8WYkdbDRo0I= =i490 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Defending against guard discovery attacks by pinning middle nodes
>> The idea would be that Guard_3 would rotate on the order of hours, >> Guard_2 would come from a set that is rotated on the order of days >> (based on the expected duration for the adversary to become Guard_3), and >> Guard_1 would rotate on the order of months (based on the expected >> duration for the adversary to become Guard_2). > > Why set guard 2 to expire in days? If that is less than surveillance speed, > then once the adversary had guard 3, it’s game over. Sorry, I should have stated this more clearly as "If that is greater than the time needed for surveillance”. And I can imagine rotating guard 2 faster than guard 1 for performance reasons (faster rotation more quickly takes advantage of new capacity in the network). But the only reason that I can see treating guard 2 differently than guard 1 is that you judge the “cost" of the attack starting from guard 2 to be higher, thus compensating for the increase in attack speed. That is, if guard 2 rotates to a malicious relay, the adversary still has to identify and then do a targeted compromised of guard 1, while if a malicious relay is selected as guard 1, then the target HS can be relatively easily observed directly. Such an argument is hard to evaluate carefully, because the costs in terms of added technical and legal complexity are hard to estimate. For example, at what point is it “cheaper" to run more malicious nodes and/or wait longer in hopes of obtaining guard 1 than to try and identify guard 2 but then have to perform surveillance on an identified guard 1? So I would argue to protect guard 2 as much as guard 1, and then look for other, better understood, methods to improve performance. Some fun methods that come to mind are (i) carefully choosing number of primary and secondary guards and (ii) trying to reduce the HS path length, and (iii) allowing HSes to pay for improved performance (yes, I haven’t given up on this idea, haha). Exposing to the HS operator the options controlling the security/performance tradeoff may also be a good option. Cheers, Aaron ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] tor packet handling
Hi, I want to develop extension(intrusion detection) for tor. for that i have to extract TCP and IP header from packet. I need to know where and how tor handle packet(TCP/IP). is it in buffer.c / connection.c ? Regards Kawsar ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
