tor-commits April 2014

tor-commits@lists.torproject.org

22 participants
2020 discussions

[torspec/master] Add xxx-single-guard-node as proposal 236.
by nickm＠torproject.org 23 Apr '14

23 Apr '14

commit 97062e055d0992356ba61dfe605d40b10b90ccff Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Apr 23 14:20:01 2014 -0400 Add xxx-single-guard-node as proposal 236. --- proposals/000-index.txt | 2 + proposals/236-single-guard-node.txt | 286 +++++++++++++++++++++++++++++++++++ proposals/xxx-single-guard-node.txt | 286 ----------------------------------- 3 files changed, 288 insertions(+), 286 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index f32d9bd..4674c3f 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -156,6 +156,7 @@ Proposals by number: 233 Making Tor2Web mode faster [OPEN] 234 Adding remittance field to directory specification [OPEN] 235 Stop assigning (and eventually supporting) the Named flag [DRAFT] +236 The move to a single guard node [OPEN] Proposals by status: @@ -214,6 +215,7 @@ Proposals by status: 232 Pluggable Transport through SOCKS proxy [for 0.2.6.x] 233 Making Tor2Web mode faster 234 Adding remittance field to directory specification + 236 The move to a single guard node ACCEPTED: 140 Provide diffs between consensuses 172 GETINFO controller option for circuit information diff --git a/proposals/236-single-guard-node.txt b/proposals/236-single-guard-node.txt new file mode 100644 index 0000000..d7c03d3 --- /dev/null +++ b/proposals/236-single-guard-node.txt @@ -0,0 +1,286 @@ +Filename: 236-single-guard-node.txt +Title: The move to a single guard node +Author: George Kadianakis, Nicholas Hopper +Created: 2014-03-22 +Status: Open + +0. Introduction + + It has been suggested that reducing the number of guard nodes of + each user and increasing the guard node rotation period will make + Tor more resistant against certain attacks [0]. + + For example, an attacker who sets up guard nodes and hopes for a + client to eventually choose them as their guard will have much less + probability of succeeding in the long term. + + Currently, every client picks 3 guard nodes and keeps them for 2 to + 3 months (since 0.2.4.12-alpha) before rotating them. In this + document, we propose the move to a single guard per client and an + increase of the rotation period to 9 to 10 months. + +1. Proposed changes + +1.1. Switch to one guard per client + + When this proposal becomes effective, clients will switch to using + a single guard node. + + That is, in its first startup, Tor picks one guard and stores its + identity persistently to disk. Tor uses that guard node as the + first hop of its circuits from thereafter. + + If that Guard node ever becomes unusable, rather than replacing it, + Tor picks a new guard and adds it to the end of the list. When + choosing the first hop of a circuit, Tor tries all guard nodes from + the top of the list sequentially till it finds a usable guard node. + + A Guard node is considered unusable according to section "5. Guard + nodes" in path-spec.txt. The rest of the rules from that section + apply here too. XXX which rules specifically? -asn + XXX Probably the rules about how to add a new guard (only after + contact), when to re-try a guard for reachability, and when to + discard a guard? -nickhopper + + XXX Do we need to specify how already existing clients migrate? + +1.1.1. Alternative behavior to section 1.1 + + Here is an alternative behavior than the one specified in the + previous section. It's unclear which one is better. + + Instead of picking a new guard when the old guard becomes unusable, + we pick a number of guards in the beginning but only use the top + usable guard each time. When our guard becomes unusable, we move to + the guard below it in the list. + + This behavior _might_ make some attacks harder; for example, an + attacker who shoots down your guard in the hope that you will pick + his guard next, is now forced to have evil guards in the network at + the time you first picked your guards. + + However, this behavior might also influence performance, since a + guard that was fast enough 7 months ago, might not be this fast + today. Should we reevaluate our opinion based on the last + consensus, when we have to pick a new guard? Also, a guard that was + up 7 months ago might be down today, so we might end up sampling + from the current network anyway. + +1.2. Increase guard rotation period + + When this proposal becomes effective, Tor clients will set the + lifetime of each guard to a random time between 9 to 10 months. + + If Tor tries to use a guard whose age is over its lifetime value, + the guard gets discarded (also from persistent storage) and a new + one is picked in its place. + + XXX We didn't do any analysis on extending the rotation period. + For example, we don't even know the average age of guards, and + whether all guards stay around for less than 9 months anyway. + Maybe we should do some analysis before proceeding? + + XXX The guard lifetime should be controlled using the + (undocumented?) GuardLifetime consensus option, right? + +1.2.1. Alternative behavior to section 1.2 + + Here is an alternative behavior than the one specified in the + previous section. It's unclear which one is better. + + Similar to section 1.2, but instead of rotating to completely new + guard nodes after 9 months, we pick a few extra guard nodes in the + beginning, and after 9 months we delete the already used guard + nodes and use the one after them. + + This has approximately the same tradeoffs as section 1.1.1. + + Also, should we check the age of all of our guards periodically, or + only check them when we try to use them? + +1.3. Age of guard as a factor on guard probabilities + + By increasing the guard rotation period we also increase the lack + of utilization for young guards since clients will rotate guards even + more infrequently now (see 'Phase three' of [1]). + + We can mitigate this phenomenon by treating these recent guards as + "fractional" guards: + + To do so, everytime an authority needs to vote for a guard, it + reads a set of consensus documents spanning the past NNN months, + where NNN is the number of months in the guard rotation period (10 + months if this proposal is adopted in full) and calculates the + visibility of the guard; that is, in how many consensuses it has + had the guard flag. + + The authorities include the age of each guard by appending + '[SP "GV=" INT]' in the guard's "w" line. + + A guard N that has been visible for V out of NNN*30*24 consensuses + has had the opportunity to be chosen as a guard by approximately + F = V/NNN*30*24 of the clients in the network, and the remaining + 1-F fraction of the clients have not noticed this change. So when + being chosen for middle or exit positions on a circuit, clients + should treat N as if F fraction of its bandwidth is a guard + (respectively, dual) node and (1-F) is a middle (resp, exit) node. + Let Wpf denote the weight from the 'bandwidth-weights' line a + client would apply to N for position p if it had the guard + flag, Wpn the weight if it did not have the guard flag, and B the + measured bandwidth of N in the consensus. Then instead of choosing + N for position p proportionally to Wpf*B or Wpn*B, clients should + choose N proportionally to F*Wpf*B + (1-F)*Wpn*B. + + Similarly, when calculating the bandwidth-weights line as in + section 3.8.3 of dir-spec.txt, directory authorities should treat N + as if fraction F of its bandwidth has the guard flag and (1-F) does + not. So when computing the totals G,M,E,D, each relay N with guard + visibility fraction F and bandwidth B should be added as follows: + + G' = G + F*B, if N does not have the exit flag + M' = M + (1-F)*B, if N does not have the exit flag + D' = D + F*B, if N has the exit flag + E' = E + (1-F)*B, if N has the exit flag + +1.4. Raise the bandwidth threshold for being a guard + + From dir-spec.txt: + "Guard" -- A router is a possible 'Guard' if its Weighted Fractional + Uptime is at least the median for "familiar" active routers, and if + its bandwidth is at least median or at least 250KB/s. + + When this proposal becomes effective, authorities should change the + bandwidth threshold for being a guard node to 2000KB/s instead of + 250KB/s. + + Implications of raising the bandwidth threshold are discussed in + section 2.3. + + XXX Is this insane? It's an 8-fold increase. + +2. Discussion + +2.1. Guard node set fingerprinting + + With the old behavior of three guard nodes per user, it was + extremely unlikely for two users to have the same guard node + set. Hence the set of guard nodes acted as a fingerprint to each + user. + + When this proposal becomes effective, each user will have one guard + node. We believe that this slightly reduces the effectiveness of + this fingerprint since users who pick a popular guard node will now + blend in with thousands of other users. However, clients who pick a + slow guard will still have a small anonymity set [2]. + + All in all, this proposal slightly improves the situation of guard + node fingerprinting, but does not solve it. See the next section + for a suggested scheme that would further fix the guard node set + fingerprinting problem + +2.1.1. Potential fingerprinting solution: Guard buckets + + One of the suggested alternatives that moves us closer to solving + the guard node fingerprinting problem, would be to split the list + of N guard nodes into buckets of K guards, and have each client + pick a bucket [3]. + + This reduces the fingerprint from N-choose-k to N/k guard set + choices; it also allows users to have multiple guard nodes which + provides reliability and performance. + + Unfortunately, the implementation of this idea is not as easy and + its anonymity effects are not well understood so we had to reject + this alternative for now. + +2.2. What about 'multipath' schemes like Conflux? + + By switching to one guard, we rule out the deployment of + 'multipath' systems like Conflux [4] which build multiple circuits + through the Tor network and attempt to detect and use the most + efficient circuits. + + On the other hand, the 'Guard buckets' idea outlined in section + 2.1.1 works well with Conflux-type schemes so it's still worth + considering. + +2.3. Implications of raising the bandwidth threshold for guards + + By raising the bandwidth threshold for being a guard we directly + affect the performance and anonymity of Tor clients. We performed a + brief analysis of the implications of switching to one guard and + the results imply that the changes are not tragic [2]. + + Specifically, it seems that the performance of about half of the + clients will degrade slightly, but the performance of the other + half will remain the same or even improve. + + Also, it seems that the powerful guard nodes of the Tor network + have enough total bandwidth capacity to handle client traffic even + if some slow guard nodes get discarded. + + On the anonymity side, by increasing the bandwidth threshold to + 2MB/s we half our guard nodes; we discard 1000 out of 2000 + guards. Even if this seems like a substantial diversity loss, it + seems that the 1000 discarded guard nodes had a very small chance + of being selected in the first place (7% chance of any of the being + selected). + + However, it's worth noting that the performed analysis was quite + brief and the implications of this proposal are complex, so we + should be prepared for surprises. + +2.4. Should we stop building circuits after a number of guard failures? + + Inspired by academic papers like the Sniper attack [5], a powerful + attacker can choose to shut down guard nodes till a client is + forced to pick an attacker controlled guard node. Similarly, a + local network attacker can kill all connections towards all guards + except the ones she controls. + + This is a very powerful attack that is hard to defend against. A + naive way of defending against it would be for Tor to refuse to + build any more circuits after a number of guard node failures have + been experienced. + + Unfortunately, we believe that this is not a sufficiently strong + countermeasure since puzzled users will not comprehend the + confusing warning message about guard node failures and they will + instead just uninstall and reinstall TBB to fix the issue. + +2.5. What this proposal does not propose + + Finally, this proposal does not aim to solve all the problems with + guard nodes. This proposal only tries to solve some of the problems + whose solution is analyzed sufficiently and seems harmless enough + to us. + + For example, this proposal does not try to solve: + - Guard enumeration attacks. We need guard layers or virtual + circuits for this [6]. + - The guard node set fingerprinting problem [7] + - The fact that each isolation profile or virtual identity should + have its own guards. + +XXX It would also be nice to have some way to easily revert back to 3 + guards if we later decide that a single guard was a very stupid + idea. + +References: + +[0]: https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-pa… + http://freehaven.net/anonbib/#wpes12-cogs + +[1]: https://blog.torproject.org/blog/lifecycle-of-a-new-relay + +[2]: https://lists.torproject.org/pipermail/tor-dev/2014-March/006458.html + +[3]: https://trac.torproject.org/projects/tor/ticket/9273#comment:4 + +[4]: http://freehaven.net/anonbib/#pets13-splitting + +[5]: https://blog.torproject.org/blog/new-tor-denial-service-attacks-and-defenses + +[6]: https://trac.torproject.org/projects/tor/ticket/9001 + +[7]: https://trac.torproject.org/projects/tor/ticket/10969 diff --git a/proposals/xxx-single-guard-node.txt b/proposals/xxx-single-guard-node.txt deleted file mode 100644 index 451b483..0000000 --- a/proposals/xxx-single-guard-node.txt +++ /dev/null @@ -1,286 +0,0 @@ -Filename: xxx-single-guard-node.txt -Title: The move to a single guard node -Author: George Kadianakis, Nicholas Hopper -Created: 2014-03-22 -Status: Draft - -0. Introduction - - It has been suggested that reducing the number of guard nodes of - each user and increasing the guard node rotation period will make - Tor more resistant against certain attacks [0]. - - For example, an attacker who sets up guard nodes and hopes for a - client to eventually choose them as their guard will have much less - probability of succeeding in the long term. - - Currently, every client picks 3 guard nodes and keeps them for 2 to - 3 months (since 0.2.4.12-alpha) before rotating them. In this - document, we propose the move to a single guard per client and an - increase of the rotation period to 9 to 10 months. - -1. Proposed changes - -1.1. Switch to one guard per client - - When this proposal becomes effective, clients will switch to using - a single guard node. - - That is, in its first startup, Tor picks one guard and stores its - identity persistently to disk. Tor uses that guard node as the - first hop of its circuits from thereafter. - - If that Guard node ever becomes unusable, rather than replacing it, - Tor picks a new guard and adds it to the end of the list. When - choosing the first hop of a circuit, Tor tries all guard nodes from - the top of the list sequentially till it finds a usable guard node. - - A Guard node is considered unusable according to section "5. Guard - nodes" in path-spec.txt. The rest of the rules from that section - apply here too. XXX which rules specifically? -asn - XXX Probably the rules about how to add a new guard (only after - contact), when to re-try a guard for reachability, and when to - discard a guard? -nickhopper - - XXX Do we need to specify how already existing clients migrate? - -1.1.1. Alternative behavior to section 1.1 - - Here is an alternative behavior than the one specified in the - previous section. It's unclear which one is better. - - Instead of picking a new guard when the old guard becomes unusable, - we pick a number of guards in the beginning but only use the top - usable guard each time. When our guard becomes unusable, we move to - the guard below it in the list. - - This behavior _might_ make some attacks harder; for example, an - attacker who shoots down your guard in the hope that you will pick - his guard next, is now forced to have evil guards in the network at - the time you first picked your guards. - - However, this behavior might also influence performance, since a - guard that was fast enough 7 months ago, might not be this fast - today. Should we reevaluate our opinion based on the last - consensus, when we have to pick a new guard? Also, a guard that was - up 7 months ago might be down today, so we might end up sampling - from the current network anyway. - -1.2. Increase guard rotation period - - When this proposal becomes effective, Tor clients will set the - lifetime of each guard to a random time between 9 to 10 months. - - If Tor tries to use a guard whose age is over its lifetime value, - the guard gets discarded (also from persistent storage) and a new - one is picked in its place. - - XXX We didn't do any analysis on extending the rotation period. - For example, we don't even know the average age of guards, and - whether all guards stay around for less than 9 months anyway. - Maybe we should do some analysis before proceeding? - - XXX The guard lifetime should be controlled using the - (undocumented?) GuardLifetime consensus option, right? - -1.2.1. Alternative behavior to section 1.2 - - Here is an alternative behavior than the one specified in the - previous section. It's unclear which one is better. - - Similar to section 1.2, but instead of rotating to completely new - guard nodes after 9 months, we pick a few extra guard nodes in the - beginning, and after 9 months we delete the already used guard - nodes and use the one after them. - - This has approximately the same tradeoffs as section 1.1.1. - - Also, should we check the age of all of our guards periodically, or - only check them when we try to use them? - -1.3. Age of guard as a factor on guard probabilities - - By increasing the guard rotation period we also increase the lack - of utilization for young guards since clients will rotate guards even - more infrequently now (see 'Phase three' of [1]). - - We can mitigate this phenomenon by treating these recent guards as - "fractional" guards: - - To do so, everytime an authority needs to vote for a guard, it - reads a set of consensus documents spanning the past NNN months, - where NNN is the number of months in the guard rotation period (10 - months if this proposal is adopted in full) and calculates the - visibility of the guard; that is, in how many consensuses it has - had the guard flag. - - The authorities include the age of each guard by appending - '[SP "GV=" INT]' in the guard's "w" line. - - A guard N that has been visible for V out of NNN*30*24 consensuses - has had the opportunity to be chosen as a guard by approximately - F = V/NNN*30*24 of the clients in the network, and the remaining - 1-F fraction of the clients have not noticed this change. So when - being chosen for middle or exit positions on a circuit, clients - should treat N as if F fraction of its bandwidth is a guard - (respectively, dual) node and (1-F) is a middle (resp, exit) node. - Let Wpf denote the weight from the 'bandwidth-weights' line a - client would apply to N for position p if it had the guard - flag, Wpn the weight if it did not have the guard flag, and B the - measured bandwidth of N in the consensus. Then instead of choosing - N for position p proportionally to Wpf*B or Wpn*B, clients should - choose N proportionally to F*Wpf*B + (1-F)*Wpn*B. - - Similarly, when calculating the bandwidth-weights line as in - section 3.8.3 of dir-spec.txt, directory authorities should treat N - as if fraction F of its bandwidth has the guard flag and (1-F) does - not. So when computing the totals G,M,E,D, each relay N with guard - visibility fraction F and bandwidth B should be added as follows: - - G' = G + F*B, if N does not have the exit flag - M' = M + (1-F)*B, if N does not have the exit flag - D' = D + F*B, if N has the exit flag - E' = E + (1-F)*B, if N has the exit flag - -1.4. Raise the bandwidth threshold for being a guard - - From dir-spec.txt: - "Guard" -- A router is a possible 'Guard' if its Weighted Fractional - Uptime is at least the median for "familiar" active routers, and if - its bandwidth is at least median or at least 250KB/s. - - When this proposal becomes effective, authorities should change the - bandwidth threshold for being a guard node to 2000KB/s instead of - 250KB/s. - - Implications of raising the bandwidth threshold are discussed in - section 2.3. - - XXX Is this insane? It's an 8-fold increase. - -2. Discussion - -2.1. Guard node set fingerprinting - - With the old behavior of three guard nodes per user, it was - extremely unlikely for two users to have the same guard node - set. Hence the set of guard nodes acted as a fingerprint to each - user. - - When this proposal becomes effective, each user will have one guard - node. We believe that this slightly reduces the effectiveness of - this fingerprint since users who pick a popular guard node will now - blend in with thousands of other users. However, clients who pick a - slow guard will still have a small anonymity set [2]. - - All in all, this proposal slightly improves the situation of guard - node fingerprinting, but does not solve it. See the next section - for a suggested scheme that would further fix the guard node set - fingerprinting problem - -2.1.1. Potential fingerprinting solution: Guard buckets - - One of the suggested alternatives that moves us closer to solving - the guard node fingerprinting problem, would be to split the list - of N guard nodes into buckets of K guards, and have each client - pick a bucket [3]. - - This reduces the fingerprint from N-choose-k to N/k guard set - choices; it also allows users to have multiple guard nodes which - provides reliability and performance. - - Unfortunately, the implementation of this idea is not as easy and - its anonymity effects are not well understood so we had to reject - this alternative for now. - -2.2. What about 'multipath' schemes like Conflux? - - By switching to one guard, we rule out the deployment of - 'multipath' systems like Conflux [4] which build multiple circuits - through the Tor network and attempt to detect and use the most - efficient circuits. - - On the other hand, the 'Guard buckets' idea outlined in section - 2.1.1 works well with Conflux-type schemes so it's still worth - considering. - -2.3. Implications of raising the bandwidth threshold for guards - - By raising the bandwidth threshold for being a guard we directly - affect the performance and anonymity of Tor clients. We performed a - brief analysis of the implications of switching to one guard and - the results imply that the changes are not tragic [2]. - - Specifically, it seems that the performance of about half of the - clients will degrade slightly, but the performance of the other - half will remain the same or even improve. - - Also, it seems that the powerful guard nodes of the Tor network - have enough total bandwidth capacity to handle client traffic even - if some slow guard nodes get discarded. - - On the anonymity side, by increasing the bandwidth threshold to - 2MB/s we half our guard nodes; we discard 1000 out of 2000 - guards. Even if this seems like a substantial diversity loss, it - seems that the 1000 discarded guard nodes had a very small chance - of being selected in the first place (7% chance of any of the being - selected). - - However, it's worth noting that the performed analysis was quite - brief and the implications of this proposal are complex, so we - should be prepared for surprises. - -2.4. Should we stop building circuits after a number of guard failures? - - Inspired by academic papers like the Sniper attack [5], a powerful - attacker can choose to shut down guard nodes till a client is - forced to pick an attacker controlled guard node. Similarly, a - local network attacker can kill all connections towards all guards - except the ones she controls. - - This is a very powerful attack that is hard to defend against. A - naive way of defending against it would be for Tor to refuse to - build any more circuits after a number of guard node failures have - been experienced. - - Unfortunately, we believe that this is not a sufficiently strong - countermeasure since puzzled users will not comprehend the - confusing warning message about guard node failures and they will - instead just uninstall and reinstall TBB to fix the issue. - -2.5. What this proposal does not propose - - Finally, this proposal does not aim to solve all the problems with - guard nodes. This proposal only tries to solve some of the problems - whose solution is analyzed sufficiently and seems harmless enough - to us. - - For example, this proposal does not try to solve: - - Guard enumeration attacks. We need guard layers or virtual - circuits for this [6]. - - The guard node set fingerprinting problem [7] - - The fact that each isolation profile or virtual identity should - have its own guards. - -XXX It would also be nice to have some way to easily revert back to 3 - guards if we later decide that a single guard was a very stupid - idea. - -References: - -[0]: https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-pa… - http://freehaven.net/anonbib/#wpes12-cogs - -[1]: https://blog.torproject.org/blog/lifecycle-of-a-new-relay - -[2]: https://lists.torproject.org/pipermail/tor-dev/2014-March/006458.html - -[3]: https://trac.torproject.org/projects/tor/ticket/9273#comment:4 - -[4]: http://freehaven.net/anonbib/#pets13-splitting - -[5]: https://blog.torproject.org/blog/new-tor-denial-service-attacks-and-defenses - -[6]: https://trac.torproject.org/projects/tor/ticket/9001 - -[7]: https://trac.torproject.org/projects/tor/ticket/10969

1 0

[tor/release-0.2.4] Remove the unused router_hex_digest_matches
by arma＠torproject.org 23 Apr '14

23 Apr '14

commit 9077118ee27e275d495b89a810ee28882c74cf62 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Mar 11 11:17:46 2014 -0400 Remove the unused router_hex_digest_matches When I removed some unused functions in 5bfa373eeeb, this became unused as well. --- src/or/routerlist.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/src/or/routerlist.c b/src/or/routerlist.c index c28de24..cb39729 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -2591,19 +2591,6 @@ router_is_named(const routerinfo_t *router) tor_memeq(digest, router->cache_info.identity_digest, DIGEST_LEN)); } -/** Return true iff the digest of router's identity key, - * encoded in hexadecimal, matches hexdigest (which is - * optionally prefixed with a single dollar sign). Return false if - * hexdigest is malformed, or it doesn't match. */ -static INLINE int -router_hex_digest_matches(const routerinfo_t *router, const char *hexdigest) -{ - return hex_digest_nickname_matches(hexdigest, - router->cache_info.identity_digest, - router->nickname, - router_is_named(router)); -} - /** Return true iff digest is the digest of the identity key of a * trusted directory matching at least one bit of type. If type * is zero, any authority is okay. */

1 0

[tor/release-0.2.4] Update ns downloads when we receive a bridge descriptor
by arma＠torproject.org 23 Apr '14

23 Apr '14

commit db72479eea4b5bbd73d1fa33f4c9e4e4e2b99b04 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Mar 10 15:01:27 2014 -0400 Update ns downloads when we receive a bridge descriptor This prevents long stalls when we're starting with a state file but with no bridge descriptors. Fixes bug 9229. I believe this bug has been present since 0.2.0.3-alpha. --- changes/bug9229 | 5 +++++ src/or/entrynodes.c | 6 +++++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/changes/bug9229 b/changes/bug9229 new file mode 100644 index 0000000..ad7fd22 --- /dev/null +++ b/changes/bug9229 @@ -0,0 +1,5 @@ + o Minor bugfixes: + - Avoid 60-second delays in the bootstrapping process when Tor + is launching for a second time while using bridges. Fixes bug 9229; + bugfix on 0.2.0.3-alpha. + diff --git a/src/or/entrynodes.c b/src/or/entrynodes.c index 2aa063c..59770fa 100644 --- a/src/or/entrynodes.c +++ b/src/or/entrynodes.c @@ -2115,8 +2115,12 @@ learned_bridge_descriptor(routerinfo_t *ri, int from_cache) * our entry node list */ entry_guard_register_connect_status(ri->cache_info.identity_digest, 1, 0, now); - if (first) + if (first) { + /* XXXX apparently, this is never called. See bug #9229. */ routerlist_retry_directory_downloads(now); + } + + update_networkstatus_downloads(now); } } }

1 0

[tor/release-0.2.4] Correct the URL in the "a relay on win95???" message
by arma＠torproject.org 23 Apr '14

23 Apr '14

commit cbf9e742368158b927249913b395b3796d847a92 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Mar 6 09:57:42 2014 -0500 Correct the URL in the "a relay on win95???" message This is a fix for 9393; it's not a bugfix on any Tor version per se, but rather on whatever Tor version was current when we reorganized the wiki. --- changes/bug9393 | 4 ++++ src/or/config.c | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/changes/bug9393 b/changes/bug9393 new file mode 100644 index 0000000..9aedd12 --- /dev/null +++ b/changes/bug9393 @@ -0,0 +1,4 @@ + o Minor bugfixes: + - Give the correct URL in the warning message that we present + when the user is trying to run a Tor relay on an ancient version + of Windows. Fixes bug 9393. diff --git a/src/or/config.c b/src/or/config.c index 3984755..ef02946 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -2319,7 +2319,7 @@ options_validate(or_options_t *old_options, or_options_t *options, !strcmpstart(uname, "Windows Me"))) { log_warn(LD_CONFIG, "Tor is running as a server, but you are " "running %s; this probably won't work. See " - "https://wiki.torproject.org/TheOnionRouter/TorFAQ#ServerOS " + "https://www.torproject.org/docs/faq.html#BestOSForRelay " "for details.", uname); }

1 0

[tor/release-0.2.4] whitespace fix
by arma＠torproject.org 23 Apr '14

23 Apr '14

commit 24e0b1088acd94ceae3109107fa354b89309e2b7 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Mar 27 15:34:57 2014 -0400 whitespace fix --- src/or/connection_edge.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index 3a72110..895c0f7 100644 --- a/src/or/connection_edge.c +++ b/src/or/connection_edge.c @@ -2088,7 +2088,6 @@ connection_ap_handshake_socks_resolved_addr(entry_connection_t *conn, } } - /** Send an answer to an AP connection that has requested a DNS lookup via * SOCKS. The type should be one of RESOLVED_TYPE_(IPV4|IPV6|HOSTNAME) or -1 * for unreachable; the answer should be in the format specified in the socks

1 0

[tor/release-0.2.4] Fix unittest compilation with --disable-curve25519
by arma＠torproject.org 23 Apr '14

23 Apr '14

commit a83abcf5ee5cb8fe245bc97e089e082f62921194 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Mar 20 13:52:50 2014 -0400 Fix unittest compilation with --disable-curve25519 This is a fix for 9700, which we already fixed in 0.2.5.x, but which got left in 0.2.4.x. This is a partial backport of a0a855d586d99540277014ccd3 --- changes/bug9700 | 3 +++ src/test/test.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/changes/bug9700 b/changes/bug9700 new file mode 100644 index 0000000..f59f54c --- /dev/null +++ b/changes/bug9700 @@ -0,0 +1,3 @@ + o Minor bugfixes (compilation): + - Fix a compilation error when compiling with --disable-cuve25519. + Fixes bug 9700; bugfix on 0.2.4.17-rc. diff --git a/src/test/test.c b/src/test/test.c index 4ec8792..c2911d8 100644 --- a/src/test/test.c +++ b/src/test/test.c @@ -56,12 +56,12 @@ double fabs(double x); #include "memarea.h" #include "onion.h" #include "onion_tap.h" +#include "onion_ntor.h" #include "policies.h" #include "rephist.h" #include "routerparse.h" #ifdef CURVE25519_ENABLED #include "crypto_curve25519.h" -#include "onion_ntor.h" #endif #ifdef USE_DMALLOC

1 0

[tor/release-0.2.4] Fix documentation of torrc search order
by arma＠torproject.org 23 Apr '14

23 Apr '14

commit a68e6ea9c0288d82ea10076c551f48d63b3813fc Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Mar 27 14:58:46 2014 -0400 Fix documentation of torrc search order We are searching @CONFDIR@ before $HOME, but the documentation implied otherwise. I screwed this up in f5e86bcd6c06d43ff3af5acd8135bd8b577bc3, when I first documented the $HOME/.torrc possibility. Fix for bug 9213; bugfix on 0.2.3.18-rc. --- changes/bug9213_doc | 5 +++++ doc/tor.1.txt | 5 ++++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/changes/bug9213_doc b/changes/bug9213_doc new file mode 100644 index 0000000..2f959dd --- /dev/null +++ b/changes/bug9213_doc @@ -0,0 +1,5 @@ + o Documentation: + - Correctly document that we search for a system torrc file before + looking in ~/.torrc. Fixes documentation side of 9213; bugfix + on 0.2.3.18-rc. + diff --git a/doc/tor.1.txt b/doc/tor.1.txt index 3f8f6da..eb9ad67 100644 --- a/doc/tor.1.txt +++ b/doc/tor.1.txt @@ -37,7 +37,7 @@ COMMAND-LINE OPTIONS [[opt-f]] **-f** __FILE__:: Specify a new configuration file to contain further Tor configuration - options. (Default: $HOME/.torrc, or @CONFDIR@/torrc if that file is not + options. (Default: @CONFDIR@/torrc, or $HOME/.torrc if that file is not found) [[opt-defaults-torrc]] **--defaults-torrc** __FILE__:: @@ -2103,6 +2103,9 @@ FILES **@CONFDIR@/torrc**:: The configuration file, which contains "option value" pairs. +**$HOME/.torrc**:: + Fallback location for torrc, if @CONFDIR@/torrc is not found. + **@LOCALSTATEDIR@/lib/tor/**:: The tor process stores keys and other data here.

1 0

[tor/release-0.2.4] Tweak changes file and comment dates.
by arma＠torproject.org 23 Apr '14

23 Apr '14

commit 09ed8a5dbb5216caae0055c1608abbc8c76412c9 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 14 17:58:49 2014 -0400 Tweak changes file and comment dates. --- changes/bug11464_023 | 2 +- src/or/routerlist.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/changes/bug11464_023 b/changes/bug11464_023 index a9cd658..80c04b2 100644 --- a/changes/bug11464_023 +++ b/changes/bug11464_023 @@ -1,5 +1,5 @@ o Major features (security): - - Block every authority signing key that was used on an authority + - Block authority signing keys that were used on an authorities vulnerable to the "heartbleed" bug in openssl (CVE-2014-0160). (We don't have any evidence that these keys _were_ compromised; we're doing this to be prudent.) Resolves ticket 11464. diff --git a/src/or/routerlist.c b/src/or/routerlist.c index 7cbf6ef..a7968be 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -460,9 +460,9 @@ authority_cert_dl_failed(const char *id_digest, int status) static const char *BAD_SIGNING_KEYS[] = { "09CD84F751FD6E955E0F8ADB497D5401470D697E", // Expires 2015-01-11 16:26:31 -// dizum still needs to rotate as of 2014-04-04 +// dizum still needs to rotate as of 2014-04-14 //"0E7E9C07F0969D0468AD741E172A6109DC289F3C", // Expires 2014-08-12 10:18:26 -// dannenberg still needs to rotate as of 2014-04-04 +// dannenberg still needs to rotate as of 2014-04-14 //"57B85409891D3FB32137F642FDEDF8B7F8CDFDCD", // Expires 2015-02-11 17:19:09 "87326329007AF781F587AF5B594E540B2B6C7630", // Expires 2014-07-17 11:10:09 "98CC82342DE8D298CF99D3F1A396475901E0D38E", // Expires 2014-11-10 13:18:56

1 0

[tor/release-0.2.4] Fill in the list of blacklisted signing keys.
by arma＠torproject.org 23 Apr '14

23 Apr '14

commit 46cf63bb42f2818201bc0c39036f2c17e210fcdb Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 14 16:03:53 2014 -0400 Fill in the list of blacklisted signing keys. I used a list of certificate files from arma, and a little script, both at 11464. --- src/or/routerlist.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/src/or/routerlist.c b/src/or/routerlist.c index e993e13..7cbf6ef 100644 --- a/src/or/routerlist.c +++ b/src/or/routerlist.c @@ -459,7 +459,18 @@ authority_cert_dl_failed(const char *id_digest, int status) } static const char *BAD_SIGNING_KEYS[] = { - "----------------------------------------", + "09CD84F751FD6E955E0F8ADB497D5401470D697E", // Expires 2015-01-11 16:26:31 +// dizum still needs to rotate as of 2014-04-04 +//"0E7E9C07F0969D0468AD741E172A6109DC289F3C", // Expires 2014-08-12 10:18:26 +// dannenberg still needs to rotate as of 2014-04-04 +//"57B85409891D3FB32137F642FDEDF8B7F8CDFDCD", // Expires 2015-02-11 17:19:09 + "87326329007AF781F587AF5B594E540B2B6C7630", // Expires 2014-07-17 11:10:09 + "98CC82342DE8D298CF99D3F1A396475901E0D38E", // Expires 2014-11-10 13:18:56 + "9904B52336713A5ADCB13E4FB14DC919E0D45571", // Expires 2014-04-20 20:01:01 + "9DCD8E3F1DD1597E2AD476BBA28A1A89F3095227", // Expires 2015-01-16 03:52:30 + "A61682F34B9BB9694AC98491FE1ABBFE61923941", // Expires 2014-06-11 09:25:09 + "B59F6E99C575113650C99F1C425BA7B20A8C071D", // Expires 2014-07-31 13:22:10 + "D27178388FA75B96D37FA36E0B015227DDDBDA51", // Expires 2014-08-04 04:01:57 NULL, };

1 0

[tor/release-0.2.4] Merge branch 'bug9213_doc_024' into maint-0.2.4
by arma＠torproject.org 23 Apr '14

23 Apr '14

commit 48578e1512f2d5fa95e4fdde0564d2db8ee7f995 Merge: 24e0b10 a68e6ea Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 1 20:59:13 2014 -0400 Merge branch 'bug9213_doc_024' into maint-0.2.4 changes/bug9213_doc | 5 +++++ doc/tor.1.txt | 5 ++++- 2 files changed, 9 insertions(+), 1 deletion(-)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits April 2014