[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Suspicious Circuits



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> A) This explains why it is trying the old introduction points, and it
> explains why it's building a long circuit trying each one in turn. But
> why is it trying the same introduction point more than once?

Uhhhm, right. The problem is that introduction points are not removed on
failure, which they should be. It's quite unusual that introduction
points fail (and most people won't notice that), but okay, we should
better fix it. My first guess is that this problem was introduced in
0.2.0.7-alpha (ChangeLog entry: "- Hidden services were choosing
introduction points uniquely by hexdigest, but when constructing the
hidden service descriptor they merely wrote the (potentially ambiguous)
nickname.") and that hex-encoded identities are compared with nicknames
when removing introduction points. But it's quite hard to tell without
running it. On the other hand, this change was also backported to
0.1.2.18 which did not have this problem. Hmm.

Let's find it out. :) As discussed on #tor yesterday, I attached a patch
to this message containing some more logging statements. Could you,
Kyle, apply it and run the same configuration as you did last time? You
should also enforce the same timing problem, because without it's
unlikely that intro points fail and respond with a NAK message.

Thanks for that! :)

> B) Do you think it's possible to reduce the "30 second delay" to make
> this sort of behavior happen less often? It would be nice to have hidden
> services launch more 'immediately'. But on more thought, I think 30
> seconds may already be a bare minimum, if we consider users on crappy
> connections setting up hidden services. Hm.

Good question. 30 seconds are not really much compared to the overall
performance of hidden services. How important is it that hidden services
are more immediately available after setting them up? This is only done
once in a while. Does this affect user experience so much? I think that
the behavior in Kyle's case is a really rare event, compared to the
normal use cases for hidden services. So, I would not change it in favor
of fewer and more accurate descriptor publications.

- --Karsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHak1D0M+WPffBEmURAhe+AJwMWLUlZCiroiU7BBxIwL5vkd813ACfc4Q8
AKAxnBr9Apq13uhz5gubZIM=
=jY7A
-----END PGP SIGNATURE-----
Index: /home/karsten/diss/tor/tor-0_2_0_12_alpha/src/or/rendclient.c
===================================================================
--- /home/karsten/diss/tor/tor-0_2_0_12_alpha/src/or/rendclient.c	(revision 12873)
+++ /home/karsten/diss/tor/tor-0_2_0_12_alpha/src/or/rendclient.c	(working copy)
@@ -337,11 +337,21 @@
     return 0;
   }
 
+  log_info(LD_REND, "Removing failed intro point for service %s. "
+                    "We still have a valid descriptor with %d intro points.",
+                    escaped_safe_str(query), ent->parsed->n_intro_points);
   if (ent->parsed->intro_point_extend_info) {
+    log_info(LD_REND, "The descriptor has its intro points stored as extend "
+                      "infos rather than nicknames. Failed intro point is %s",
+                      hex_str(failed_intro->identity_digest, DIGEST_LEN));
     for (i=0; i < ent->parsed->n_intro_points; ++i) {
+      log_info(LD_REND, "Comparing with intro point %s...",
+              hex_str(ent->parsed->intro_point_extend_info[i]->identity_digest,
+                       DIGEST_LEN));
       if (!memcmp(failed_intro->identity_digest,
                   ent->parsed->intro_point_extend_info[i]->identity_digest,
                   DIGEST_LEN)) {
+        log_info(LD_REND, "Found a match! Removing intro point.");
         tor_assert(!strcmp(ent->parsed->intro_points[i],
                            ent->parsed->intro_point_extend_info[i]->nickname));
         tor_free(ent->parsed->intro_points[i]);
@@ -352,11 +362,19 @@
         ent->parsed->intro_point_extend_info[i] =
           ent->parsed->intro_point_extend_info[ent->parsed->n_intro_points];
         break;
+      } else {
+        log_info(LD_REND, "No match.");
       }
     }
   } else {
+    log_info(LD_REND, "The descriptor has its intro points stored as "
+                      "nicknames rather than extend infos. Failed intro "
+                      "point is %s", failed_intro->nickname);
     for (i=0; i < ent->parsed->n_intro_points; ++i) {
+    log_info(LD_REND, "Comparing with intro point %s...",
+             ent->parsed->intro_points[i]);
       if (!strcasecmp(ent->parsed->intro_points[i], failed_intro->nickname)) {
+        log_info(LD_REND, "Found a match! Removing intro point.");
         tor_free(ent->parsed->intro_points[i]);
         ent->parsed->intro_points[i] =
           ent->parsed->intro_points[--ent->parsed->n_intro_points];
@@ -361,9 +379,13 @@
         ent->parsed->intro_points[i] =
           ent->parsed->intro_points[--ent->parsed->n_intro_points];
         break;
+      } else {
+        log_info(LD_REND, "No match.");
       }
     }
   }
+  log_info(LD_REND, "Our descriptor now has %d intro points.",
+           ent->parsed->n_intro_points);
 
   if (!ent->parsed->n_intro_points) {
     log_info(LD_REND,

Attachment: patch-goldy.sig
Description: Binary data