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
Re: another seeming attack on my server's DirPort
Kyle Williams wrote: This is just a theory, no hard facts to back it up. When I'm messing around with Tor's ControlPort, I've noticed that my Tor traffic just hangs until whatever I'm doing on the ControlPort stops. There have been a couple of times where I do something very wrong on the controlport and Tor just freezes (does not route any traffic) until I close my connection with the ControlPort. I'm wondering if the same is true for when someone is fetching descriptors from the DirPort? Does Tor traffic freeze (not route traffic) until the Dirport completes its task? Next guess... If someone where to be attacking, oh say, a hidden service, and your node was the Introduction Point for that hidden service, then perhaps someone is trying to force the owner of the hidden service to choose a new introduction point. What is the uptime of your node? Have you typically been running it for a long time? If someone is DoSing your Dirport, why not just turn it off? Alternatively, if you've got an Apache reverse proxy in front of your DirPort as described in the manual, you could perhaps implement per IP, connection and bandwidth rate limiting with mod_cband. Just a thought. Mike
Re: Provider 1blu closed exit node torpaulianer
Here's an answer from 1blu why they are closing the tor-servers: Gern nutzen wir die Gelegenheit zur Stellungnahme. Als Dienstanbieter haftet die 1blu AG spätestens ab Kenntnis auch für fremde Inhalte. Damit ist sie schon zur Vermeidung einer eigenen Haftung berechtigt und verpflichtet, Kundenserver zu sperren, wenn Beschwerden über davon ausgehenden Missbrauch vorliegen. Wenn durch die 1blu AG Unterlassungserklärungen von Kunden gefordert werden, liegen grundsätzlich Beschwerden vor, die die 1blu AG zum Eingreifen zwingen. Da die 1blu AG keinen Zugriff auf Kundensysteme hat, sind konkrete Serveranwendungen nicht unmittelbar bekannt. Die 1blu AG hat zu keinem Zeitpunkt Kunden wegen des Betriebs einer bestimmten Anwendung kontaktiert oder Verhandlungen darüber angeboten. Mit freundlichen Grüßen aus Berlin, Ihr 1blu Support-Team Short in english: 1blu are saying, that if they are not closing the servers after a third-party contacted them about an abuse from this server, they would make themselves liable. So they take the servers offline and are forcing the owners to sign a forbearance-declaration. greets -- kazaam [EMAIL PROTECTED] pgplqnOql6efB.pgp Description: PGP signature
Re: Provider 1blu closed exit node torpaulianer
Am Donnerstag, 20. Dezember 2007 15:08 schrieb kazaam: Here's an answer from 1blu why they are closing the tor-servers: Gern nutzen wir die Gelegenheit zur Stellungnahme. Als Dienstanbieter haftet die 1blu AG spätestens ab Kenntnis auch für fremde Inhalte. Isnt this is a bullshit? They say: ..we are liable for customers CONTENTS. Tor doesnt provide any content at all. A tor server is something like a telecommunication device. Damit ist sie schon zur Vermeidung einer eigenen Haftung berechtigt und verpflichtet, Kundenserver zu sperren, wenn Beschwerden über davon ausgehenden Missbrauch vorliegen. Next bullshit: according german laws (I am not a lawyer) telecommunication providers are not responsible for customers content. So noone can punish a telecommunication provider for the fact that any illegal content passed his systems. Wenn durch die 1blu AG Unterlassungserklärungen von Kunden gefordert werden, liegen grundsätzlich Beschwerden vor, die die 1blu AG zum Eingreifen zwingen. It seems to me it is what I wrote these days in the german GTP mailing list: those server providers go the way of least resistance. If they would have a minimum of courage they would protect their customers. Da die 1blu AG keinen Zugriff auf Kundensysteme hat, sind konkrete Serveranwendungen nicht unmittelbar bekannt. Die 1blu AG hat zu keinem Zeitpunkt Kunden wegen des Betriebs einer bestimmten Anwendung kontaktiert oder Verhandlungen darüber angeboten. Mit freundlichen Grüßen aus Berlin, Ihr 1blu Support-Team Short in english: 1blu are saying, that if they are not closing the servers after a third-party contacted them about an abuse from this server, they would make themselves liable. So they take the servers offline and are forcing the owners to sign a forbearance-declaration. greets pgpkRdgsKsC2K.pgp Description: PGP signature
Re: another seeming attack on my server's DirPort
Hello, On 19.12.2007, at 09:46, Scott Bennett wrote: Is anyone else having this kind of trouble, regardless of the apparent origin(s) of the attack(s)? This night I some TCP attacks (?) reported by syslog. About one half on TOR's Dir Port, the rest on port , approximately also opened by TOR. All coming from these two IP addresses: Dec 20 05:45:23 sokrates kernel: TCP: Treason uncloaked! Peer 74.130.148.96:25919/33467 shrinks window 2322119975:2322119976. Repaired. [...] Dec 20 06:04:39 sokrates kernel: TCP: Treason uncloaked! Peer 140.129.39.93:1031/9030 shrinks window 1242426870:1242428371. Repaired. A few minutes later, the server's network connection went down: Dec 20 06:41:12 sokrates kernel: NETDEV WATCHDOG: eth0: transmit timed out Dec 20 06:41:15 sokrates kernel: eth0: Transmit timeout, status 0d c07f media 10. Dec 20 06:41:15 sokrates kernel: eth0: Tx queue start entry 282389391 dirty entry 282389387. Dec 20 06:41:15 sokrates kernel: eth0: Tx descriptor 0 is 0008a28c. Dec 20 06:41:15 sokrates kernel: eth0: Tx descriptor 1 is 000805ea. Dec 20 06:41:15 sokrates kernel: eth0: Tx descriptor 2 is 000805ea. Dec 20 06:41:15 sokrates kernel: eth0: Tx descriptor 3 is 000845ea. (queue head) Dec 20 06:41:15 sokrates kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 [Repeated about every second until the server was rebooted] I assume a correlation between these two events, although I wonder how (blocked) window shrinks could lead to this. My idea was to automatically search in syslog for window shrink events and then block the guilty IPs for 24 hours with iptables. But I hope that anybody understands what was there exactly going on... Jan-Kaspar
Re: another seeming attack on my server's DirPort
On Wed, 19 Dec 2007 10:46:56 -0500 Roger Dingledine [EMAIL PROTECTED] wrote: On Wed, Dec 19, 2007 at 02:46:04AM -0600, Scott Bennett wrote: A little while ago, I added another filter rule to the router here to stop an apparently endless, rapid-fire series of directory requests hitting my tor server's DirPort from 125.35.9.66, which appears to be in China. The last time I reported this type of thing, you may recall, it came from a site in Italy. The symptom, like the last time, was that output rate on my machine's main Ethernet interface was running steadily around the transmit rate limit imposed by my ADSL line. dig(1) shows: Hi Scott, Can you check what's being repeatedly fetched? One way to do this is to run at loglevel debug briefly, and look for log_debug(LD_DIRSERV,rewritten url as '%s'., url); My first guess is that it's a runaway Tor client, or a runaway cache between the Tor client and you, rather than any intentionally abusive behavior. (It's amazing what can go wrong on the Internet when you have enough participants.) Sure. I'll do that the next time I see it happening. Meanwhile, though, I'm leaving the blocking rules in effect for the two offenders I've already encountered. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Re: another seeming attack on my server's DirPort
On Wed, 19 Dec 2007 13:44:09 -0800 Kyle Williams [EMAIL PROTECTED] wrote: On Dec 19, 2007 12:46 AM, Scott Bennett [EMAIL PROTECTED] wrote: A little while ago, I added another filter rule to the router here to stop an apparently endless, rapid-fire series of directory requests hitting my tor server's DirPort from 125.35.9.66, which appears to be in China. The last time I reported this type of thing, you may recall, it came from a site in Italy. The symptom, like the last time, was that output rate on my machine's main Ethernet interface was running steadily around the transmit rate limit imposed by my ADSL line. dig(1) shows: ; DiG 9.3.4-P1 -x 125.35.9.66 any ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 63929 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;66.9.35.125.in-addr.arpa. IN ANY ;; AUTHORITY SECTION: 9.35.125.in-addr.arpa. 10800 IN SOA ns.bta.net.cn. root.ns.bta.net.cn. 2006020501 28899 7200 604800 86400 ;; Query time: 351 msec ;; SERVER: 66.225.32.4#53(66.225.32.4) ;; WHEN: Wed Dec 19 02:40:29 2007 ;; MSG SIZE rcvd: 96 Is anyone else having this kind of trouble, regardless of the apparent origin(s) of the attack(s)? I don't mind legitimate requests for directory service tying up all or nearly all of my available output bandwidth, but I do object to morons conducting a DoS attack to keep others from getting directory service from my tor servers directory mirror. If others are also finding their tor servers being hit like this, then perhaps we need to think up an automated way to deny directory service to abusers in order to put a stop to such activity. This is just a theory, no hard facts to back it up. When I'm messing around with Tor's ControlPort, I've noticed that my Tor traffic just hangs until whatever I'm doing on the ControlPort stops. There have been a couple of times where I do something very wrong on the controlport and Tor just freezes (does not route any traffic) until I close my connection with the ControlPort. I'm wondering if the same is true for when someone is fetching descriptors from the DirPort? Does Tor traffic freeze (not route traffic) until the Dirport completes its task? No, but throughput surely slows down because it has to compete with the directory mirror outflow. Next guess... If someone where to be attacking, oh say, a hidden service, and your node was the Introduction Point for that hidden service, then perhaps someone is trying to force the owner of the hidden service to choose a new introduction point. I have no idea. What is the uptime of your node? Have you typically been running it for a long time? It is usually less than one day, thanks to the crappy ISP I signed up with. If someone is DoSing your Dirport, why not just turn it off? If we all did that, then where would we get directory service? BTW, the SOA for your DIG request, ns.bta.net.cn (202.96.0.133), had a direct match on http://cryptome.org/nsa-ip-update13.htm Just thought you should know... I still don't understand the thinking of those people. I have no reason to believe that the Chinese government is allowing the NSA to control IP addresses allocated to, and served inside, China. It makes no sense at all, and leads me to conclude that the whole list is worthless. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Re: Snail Mail Onion Routing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Speaking of the devil, I've actually thought about this an came up with an entire system about a year or so ago, but I couldn't find anyone who seemed to find interest in it, so it's been in hibernation since then. Send me an e-mail and I'll dig it up my whitepaper for you (right now I'm in the middle of something else and I'll be traveling tomorrow). ~Andrew - -- People just like you lose untold millions in personal wealth due to frivolous lawsuits and unfair government seizures. Are you protected? Read the Asset Protection Crash Course at http://www.keepyourassets.net?andrew to find out how to protect your hard-earned assets. coderman wrote: On Dec 19, 2007 2:53 PM, Martin Fick [EMAIL PROTECTED] wrote: Anyone interested in designing a Snail Mail Onion Routing protocol to be used to build a strong real world (non-computer) anonymous package receiving network? :) what you want is a zero knowledge mix, not a snail mail onion routing protocol. :) see http://www.freehaven.net/anonbib/ for lots of zero knowledge mixing (mix) info... this is off topic for Tor, as such mixes are not low latency. however, they are the appropriate for the design you seek and most of the open questions you pose are answered in various papers on the subject. best regards, -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHa0JQgwZR2XMkZmQRAlHLAKCQhFE76o438PXDLKFwtHwe2b9WWgCgqo8B D2FdHx+IbW4NRZVrg5QxS1g= =UdNJ -END PGP SIGNATURE-
Re: Snail Mail Onion Routing
I'd be interested in participating. Comrade Ringo Kamens On Dec 20, 2007 11:34 PM, Andrew Del Vecchio [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Speaking of the devil, I've actually thought about this an came up with an entire system about a year or so ago, but I couldn't find anyone who seemed to find interest in it, so it's been in hibernation since then. Send me an e-mail and I'll dig it up my whitepaper for you (right now I'm in the middle of something else and I'll be traveling tomorrow). ~Andrew - -- People just like you lose untold millions in personal wealth due to frivolous lawsuits and unfair government seizures. Are you protected? Read the Asset Protection Crash Course at http://www.keepyourassets.net?andrew to find out how to protect your hard-earned assets. coderman wrote: On Dec 19, 2007 2:53 PM, Martin Fick [EMAIL PROTECTED] wrote: Anyone interested in designing a Snail Mail Onion Routing protocol to be used to build a strong real world (non-computer) anonymous package receiving network? :) what you want is a zero knowledge mix, not a snail mail onion routing protocol. :) see http://www.freehaven.net/anonbib/ for lots of zero knowledge mixing (mix) info... this is off topic for Tor, as such mixes are not low latency. however, they are the appropriate for the design you seek and most of the open questions you pose are answered in various papers on the subject. best regards, -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHa0JQgwZR2XMkZmQRAlHLAKCQhFE76o438PXDLKFwtHwe2b9WWgCgqo8B D2FdHx+IbW4NRZVrg5QxS1g= =UdNJ -END PGP SIGNATURE-
Re: another seeming attack on my server's DirPort
On Thu, 20 Dec 2007 13:11:15 + Mike Cardwell [EMAIL PROTECTED] wrote: Kyle Williams wrote: This is just a theory, no hard facts to back it up. When I'm messing around with Tor's ControlPort, I've noticed that my Tor traffic just hangs until whatever I'm doing on the ControlPort stops. There have been a couple of times where I do something very wrong on the controlport and Tor just freezes (does not route any traffic) until I close my connection with the ControlPort. I'm wondering if the same is true for when someone is fetching descriptors from the DirPort? Does Tor traffic freeze (not route traffic) until the Dirport completes its task? Next guess... If someone where to be attacking, oh say, a hidden service, and your node was the Introduction Point for that hidden service, then perhaps someone is trying to force the owner of the hidden service to choose a new introduction point. What is the uptime of your node? Have you typically been running it for a long time? If someone is DoSing your Dirport, why not just turn it off? Alternatively, if you've got an Apache reverse proxy in front of your DirPort as described in the manual, you could perhaps implement per IP, connection and bandwidth rate limiting with mod_cband. Just a thought. Nope. No web servers at all. In fact, tor is the only service I've made available to the outside world. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Re: another seeming attack on my server's DirPort
Scott Bennett wrote: I still don't understand the thinking of those people. I have no reason to believe that the Chinese government is allowing the NSA to control IP addresses allocated to, and served inside, China. It makes no sense at all, and leads me to conclude that the whole list is worthless. I do agree. The same here. I don't believe all German major Telcos are NSA affiliated. Olaf
