Re: same first hops
On 10 Oct 2008, at 03:40, Scott Bennett wrote: On Thu, 9 Oct 2008 19:23:48 +0100 Geoff Down <[EMAIL PROTECTED]> wrote: Interestingly, I had about 6 single nodes showing on the Vidalia network map yesterday, whilst my traffic was going via a normal 3-node circuit and another 3-node circuit was in preparation. The single nodes disappeared after 20 minutes or so. Were those nodes your entry guards by any chance? Although tor initially tries to build a few (3?) circuits, once they have expired and no longer have any active streams in them, they get torn down *except* for the links between your client and the entry guard nodes. This not only improves security, but also means that a new circuit already has the first hop connected when tor goes to build that new circuit. Of course, that doesn't explain why those links disappeared after about 20 minutes, and right offhand, no other explanation comes to mind. They weren't my usual entry nodes, no. It's a mystery.
Re: same first hops
On Thu, 9 Oct 2008 19:23:48 +0100 Geoff Down <[EMAIL PROTECTED]> wrote: >On 9 Oct 2008, at 13:33, Scott Bennett wrote: >> While we're on this subject, I'd like to point out a problem with >> tor's >> current data rate capacity testing during server initialization. In >> order >> to get some initial observations of the available data rates over a >> server's >> network connections, tor builds a few (3?) test circuits that make a >> loop >> from itself into the tor network and then back to itself. At present >> it >> uses the normal route length to do this, which can give a drastically >> low >> measurement. A better way would seem to be to use a single hop, i.e., >> a >> circuit that goes to one other relay and the back to its source. That >> may >> still provide a low estimate however, so the value obtained from a >> single >> hop test probably ought to be doubled for use as an estimate of the >> data rate >> capacity of the server that is being initialized. > >Interestingly, I had about 6 single nodes showing on the Vidalia >network map yesterday, whilst my traffic was going via a normal 3-node >circuit and another 3-node circuit was in preparation. >The single nodes disappeared after 20 minutes or so. > Were those nodes your entry guards by any chance? Although tor initially tries to build a few (3?) circuits, once they have expired and no longer have any active streams in them, they get torn down *except* for the links between your client and the entry guard nodes. This not only improves security, but also means that a new circuit already has the first hop connected when tor goes to build that new circuit. Of course, that doesn't explain why those links disappeared after about 20 minutes, and right offhand, no other explanation comes to mind. 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: unsubscribe
On Thu, Oct 09, 2008 at 07:08:35PM +0100, Geoff Down wrote: > On 9 Oct 2008, at 13:24, sigi wrote: >> On Thu, Oct 09, 2008 at 04:15:35AM -0700, John Mosgrove wrote: >>> unsubscribe me. >> >> Please write your Mail to [EMAIL PROTECTED] with mailbody including: >> unsubscribe or-talk >> >> btw: >> When finally will list-subscribers check their mailheaders for this? >> > It would never have occurred to me to check the headers either, so > perhaps you are being too hard on them. Possibly I was too hard on this, but this unsubscribe-question comes so often on all mailinglists, that it bothers a lot nowadays... and it's been answered frequently already - so often... sigi.
Re: same first hops
On Oct 8, 2008, at 11:41 PM, Gregory Maxwell wrote: Consider: Nothing prevents you from running multiple tor nodes. A well funded party might run dozens or hundreds. Maybe one day somebody will actually try to analyze this.
Re: same first hops
On 9 Oct 2008, at 13:33, Scott Bennett wrote: While we're on this subject, I'd like to point out a problem with tor's current data rate capacity testing during server initialization. In order to get some initial observations of the available data rates over a server's network connections, tor builds a few (3?) test circuits that make a loop from itself into the tor network and then back to itself. At present it uses the normal route length to do this, which can give a drastically low measurement. A better way would seem to be to use a single hop, i.e., a circuit that goes to one other relay and the back to its source. That may still provide a low estimate however, so the value obtained from a single hop test probably ought to be doubled for use as an estimate of the data rate capacity of the server that is being initialized. Interestingly, I had about 6 single nodes showing on the Vidalia network map yesterday, whilst my traffic was going via a normal 3-node circuit and another 3-node circuit was in preparation. The single nodes disappeared after 20 minutes or so. GD
Fwd: unsubscribe PS[offtopic}
BTW, Hotmail users with Macs can't reliably access email headers at all, and yes that is stupid of Hotmail but they don't care. Begin forwarded message: From: Geoff Down <[EMAIL PROTECTED]> Date: 9 October 2008 19:08:35 BST To: or-talk@freehaven.net Subject: Re: unsubscribe Reply-To: or-talk@freehaven.net It would never have occurred to me to check the headers either, so perhaps you are being too hard on them. GD On 9 Oct 2008, at 13:24, sigi wrote: Hi John, On Thu, Oct 09, 2008 at 04:15:35AM -0700, John Mosgrove wrote: unsubscribe me. Please write your Mail to [EMAIL PROTECTED] with mailbody including: unsubscribe or-talk btw: When finally will list-subscribers check their mailheaders for this? sigi.
Re: unsubscribe
It would never have occurred to me to check the headers either, so perhaps you are being too hard on them. GD On 9 Oct 2008, at 13:24, sigi wrote: Hi John, On Thu, Oct 09, 2008 at 04:15:35AM -0700, John Mosgrove wrote: unsubscribe me. Please write your Mail to [EMAIL PROTECTED] with mailbody including: unsubscribe or-talk btw: When finally will list-subscribers check their mailheaders for this? sigi.
Re: Abuse complaint
On Tuesday 07 October 2008 14:22:32 Matthew McCabe wrote: > Hey- > > Last night, Time Warner Cable temporarily disabled my account due to an > alleged attack coming from my IP address and targeting a server in > Europe (Denmark I believe). Below is the e-mail I sent them to respond > to the complaint. > > Does anyone have any suggestions on how to respond to these complaints? > Is IP filtering the best (or only) option for addressing TWC's issues? > > Thanks for your help, > Matt Bear in mind that few ISPs care whether a break-in attempt was done at "your" instigation or "someone else's." Think "botnet." If you cause an ISP problems with its peering or transit partners, they disco you once they gather enough evidence that it was sourced from your IP at the time.
Re: Geode: some more headaches for TorButton? :-P
On Thu, 9 Oct 2008 07:51:54 -0400 [EMAIL PROTECTED] wrote: >On Thu, Oct 09, 2008 at 07:52:10AM -0400, [EMAIL PROTECTED] wrote 0.8K bytes >in 18 lines about: >: Rather than adding to the speculation, I thought I'd actually test the >plugin. >: Whenever a site requests your location, your browser asks permission to send >it, >: and also allows you to specify how much granularity to provide. You can also >: tick a box to make your browser remember those settings for a particular >: website. > >This is acceptable so long as your browser can't be tricked into >thinking you clicked yes with full granularity. Or that someone can't >remotely read your per site preferences without your knowledge. > And that none of your other plug-ins undo the setting. Allowing that kind of query to proceed strikes me as exactly the kind of thing that, say, the Google tool bar might do. 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: Geode: some more headaches for TorButton? :-P
On Thu, 9 Oct 2008 04:32:16 -0700 (PDT) J B <[EMAIL PROTECTED]> top-posted: >thanks to you guys who helped me unsubscribe. > >however, note that actually my (yahoo) address has full headers and I dont see >any way to unsubscribe, apart from how you guys said to do it. >I checked the headers and there is nothing about it, even under word search. >I think these headers only arrive to certain people, maybe using mail clients >etc, yahoo doesn't deliver them or they get stripped out some how Well, then send a complaint to yahoo that they have been censoring your email. That header appears on every message sent out on this list, so if the headers are missing, it's because yahoo removed them (a stupid thing for them to do, to be sure). > >Whoever is responsible for this list might wanna add an attachment to all >emails on how to unsubscribe as none of the emails I ever got showed how to do >so in headers or anywhere else. thanks good luck. > How about just getting into the habit of saving the initial responses you get from a mailing list server when you first subscribe? That way you always have the information at hand. Instructions on how to unsubscribe were included in a message sent to you confirming the fact that your email address had been added to the list. 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: same first hops
On Thu, 09 Oct 2008 10:11:26 + Anon Mus <[EMAIL PROTECTED]> wrote: >Scott Bennett wrote: >> Well, technically speaking, I guess that's true. However, unless I'm >> greatly mistaken, the exit end of a circuit will compress any data coming >> into it to be relayed back to the client and will uncompress anything >> arriving from the client to be sent out from the exit. Given that the >> attacker might observe data in the clear going into the exit or coming out >> of it and could perform the same compression in order to know the length of >> the encrypted data, the attacker might be able to pull that off. Another >> complication for the attacker to deal with is the fact that a link between >> the client and an entry node may support multiple circuits, and each >> circuit may support multiple streams, all of which are multiply encrypted >> and whose data cells are commingled with the data cells of the others at the >> client end with no obvious way of distinguishing between the cells of one >> thread and the cells of any other thread traversing that particular link. >> > >Does this already happen? Does what already happen? People attempting this sort of attack? Who knows, except for the putative attackers? But given the illegal behavior of the U.S. government under the current, criminal regime, I'd say it's likely. If you further consider the fact that essentially *all* Internet traffic that originates in, terminates in, or merely passes through any facilities in the U.S. is captured by the U.S. government, this crime syndicate seems most likely to have some success at such attacks if it wants to. China is probably alsoa good bet and for some of the same reasons. Russia? Maybe, but they might not think it was yet worth their trouble. The U.K.? Also, maybe, but keep in mind the requirement of being able to see both ends out of many, many possible ends to circuits in order to have a chance of a successful attack. Another possibility might be Japan, though that one strikes me as a tad unlikely at this point. Or, if you were referring to how tor works, please see http://www.torproject.org/overview.html.en I suppose I should clarify what I wrote above by pointing out that all streams sharing a circuit share that circuit's onion, as opposed to having a different onion for each stream. But their data cells are, of course, intermingled. > >> However, in order to match the length up with whatever is sent/received >> by the suspected client, wouldn't the attacker need to make an assumption or >> two about the circuit length? If so, then introducing randomly varying >> circuit lengths ought to obfuscate things considerably for the attacker. >> > >This has been suggested many times.. but never, to my knowledge, >implemented. > >Its one way to add real entropy to the tor network traffic, circuits >(specified user setting min max hops) could randomly vary between say >3..5 hops. I would rather set 4 hops as the low end of the route length because of certain things that have been posted to this list in the past that suggest that 3 is inadequate. So I guess I'd go for 4 to 6 or 7 as a good range. OTOH, from a randomization point of view, the more the better. The downside there, of course, is that each additional hop introduces one more potential point of circuit failure, lengthens response times, and generally eats up more capacity of the tor network. While we're on this subject, I'd like to point out a problem with tor's current data rate capacity testing during server initialization. In order to get some initial observations of the available data rates over a server's network connections, tor builds a few (3?) test circuits that make a loop from itself into the tor network and then back to itself. At present it uses the normal route length to do this, which can give a drastically low measurement. A better way would seem to be to use a single hop, i.e., a circuit that goes to one other relay and the back to its source. That may still provide a low estimate however, so the value obtained from a single hop test probably ought to be doubled for use as an estimate of the data rate capacity of the server that is being initialized. > >Also 1 and 2 hop circuits would be useful (& add more entropy) for where >a person only wanted a simple exit ip proxy. This is useful nowadays for >2 reasons, > >1. where some forums have "bad","nuisance" ip blocking lists. Some >clever forum admins (contrary to forum rules) will put someones ip on >this list to (illegally) stop them posting a reply, usually if the admin >is abusing their power and losing some argument with someone on the >forum. When challenged this admin will claim they had nothing to do with >it and that it was the "automated protection mechanism". So to be able >to have a large number of simple proxies to hand immediately is very useful. > >2. for anonymously seeding/downloading to
Re: unsubscribe
Hi John, On Thu, Oct 09, 2008 at 04:15:35AM -0700, John Mosgrove wrote: > unsubscribe me. Please write your Mail to [EMAIL PROTECTED] with mailbody including: unsubscribe or-talk btw: When finally will list-subscribers check their mailheaders for this? sigi.
Re: Geode: some more headaches for TorButton? :-P
On Thu, Oct 09, 2008 at 07:52:10AM -0400, [EMAIL PROTECTED] wrote 0.8K bytes in 18 lines about: : Rather than adding to the speculation, I thought I'd actually test the plugin. : Whenever a site requests your location, your browser asks permission to send it, : and also allows you to specify how much granularity to provide. You can also : tick a box to make your browser remember those settings for a particular : website. This is acceptable so long as your browser can't be tricked into thinking you clicked yes with full granularity. Or that someone can't remotely read your per site preferences without your knowledge. -- Andrew
Re: Geode: some more headaches for TorButton? :-P
* on the Thu, Oct 09, 2008 at 01:11:37PM +0200, Tom Hek wrote: > It's really scary when a random website can request your physical > location imo.. I really hope you can disable that shit in the new > version of Firefox when they include it.. Rather than adding to the speculation, I thought I'd actually test the plugin. Whenever a site requests your location, your browser asks permission to send it, and also allows you to specify how much granularity to provide. You can also tick a box to make your browser remember those settings for a particular website. This is no risk whatsoever. They'll almost certainly include an option to turn it off altogether, but even if they don't you have to explicitly state that the website is allowed to see your location. -- Erilenz
Re: Geode: some more headaches for TorButton? :-P
thanks to you guys who helped me unsubscribe. however, note that actually my (yahoo) address has full headers and I dont see any way to unsubscribe, apart from how you guys said to do it. I checked the headers and there is nothing about it, even under word search. I think these headers only arrive to certain people, maybe using mail clients etc, yahoo doesn't deliver them or they get stripped out some how Whoever is responsible for this list might wanna add an attachment to all emails on how to unsubscribe as none of the emails I ever got showed how to do so in headers or anywhere else. thanks good luck. --- On Thu, 10/9/08, Tom Hek <[EMAIL PROTECTED]> wrote: > From: Tom Hek <[EMAIL PROTECTED]> > Subject: Re: Geode: some more headaches for TorButton? :-P > To: or-talk@freehaven.net > Date: Thursday, October 9, 2008, 4:11 AM > It's really scary when a random website can request your > physical > location imo.. I really hope you can disable that shit in > the new > version of Firefox when they include it.. > > Tom > > Marco Bonetti wrote: > > Link bounced from /.: > http://labs.mozilla.com/2008/10/introducing-geode/ > > > > Looks like the upcoming versions of firefox will ship > the support for W3C > > geolocation specification: what's better for a tor > attacker to ask > > directly to the browser where its user lives? ;-) > > I'm quite confident there'll be a way to > (easily?) disable this feature > > but it's scaring stuff nevertheless. > > > > ciao > >
unsubscribe
unsubscribe me.
Re: Geode: some more headaches for TorButton? :-P
It's really scary when a random website can request your physical location imo.. I really hope you can disable that shit in the new version of Firefox when they include it.. Tom Marco Bonetti wrote: Link bounced from /.: http://labs.mozilla.com/2008/10/introducing-geode/ Looks like the upcoming versions of firefox will ship the support for W3C geolocation specification: what's better for a tor attacker to ask directly to the browser where its user lives? ;-) I'm quite confident there'll be a way to (easily?) disable this feature but it's scaring stuff nevertheless. ciao
Re: same first hops
Scott Bennett wrote: Well, technically speaking, I guess that's true. However, unless I'm greatly mistaken, the exit end of a circuit will compress any data coming into it to be relayed back to the client and will uncompress anything arriving from the client to be sent out from the exit. Given that the attacker might observe data in the clear going into the exit or coming out of it and could perform the same compression in order to know the length of the encrypted data, the attacker might be able to pull that off. Another complication for the attacker to deal with is the fact that a link between the client and an entry node may support multiple circuits, and each circuit may support multiple streams, all of which are multiply encrypted and whose data cells are commingled with the data cells of the others at the client end with no obvious way of distinguishing between the cells of one thread and the cells of any other thread traversing that particular link. Does this already happen? However, in order to match the length up with whatever is sent/received by the suspected client, wouldn't the attacker need to make an assumption or two about the circuit length? If so, then introducing randomly varying circuit lengths ought to obfuscate things considerably for the attacker. This has been suggested many times.. but never, to my knowledge, implemented. Its one way to add real entropy to the tor network traffic, circuits (specified user setting min max hops) could randomly vary between say 3..5 hops. Also 1 and 2 hop circuits would be useful (& add more entropy) for where a person only wanted a simple exit ip proxy. This is useful nowadays for 2 reasons, 1. where some forums have "bad","nuisance" ip blocking lists. Some clever forum admins (contrary to forum rules) will put someones ip on this list to (illegally) stop them posting a reply, usually if the admin is abusing their power and losing some argument with someone on the forum. When challenged this admin will claim they had nothing to do with it and that it was the "automated protection mechanism". So to be able to have a large number of simple proxies to hand immediately is very useful. 2. for anonymously seeding/downloading torrents. Now, before you all shout, you must realize its getting more difficult out there. People are getting sent huge fines for just downloading a movie they will junk the next day, based on their IP addy. Potentially, torrent traffic could provide a lot of cover for torland users. 3 or more hops is far too excessive. 1 (or 2) hops would be enough. It not needed for most torrents (eg legal porn) and 1 hop is not going to protect you from law enforcement. Another possible way to complicate things for the attacker would be a variant of something has already been proposed, namely, using multiple data cell sizes within the circuit. As I understand it, the suggestions so far have been directed toward efficiency, e.g., sending long cells when there are enough data to exceed the payload limits of short cells. However, if short cells were randomly used when there are enough data for long cells, then the significance to the attacker of the distinction between long and short cells would be somewhat reduced. Tossing in occasional padding at random to produce a long cell that might have either had only minimally more payload than a short cell or even data for which a short cell would have been adequate ought to augment the attacker's obstacles. If more than two cell lengths were used, then these techniques ought to become even more effective against attackers. Also been suggested before. Perhaps it might be possibly to make very packet exactly the same size. Or at least a range (large medium small) of exact size packets. So they could not be told apart according to their exact data. A third possibility might be to do at the tor level something that is already supported at the data link level in the BSDs and perhaps LINUX, namely, to use multiple physical links (circuits in the case of tor) to split the traffic load of a data link (stream in the case of tor) across multiple physical links. The downside of this method, of course, is that it multiplies the risk of a broken stream due to a tor node failure or lower-level failure. OTOH, it might also frequently and significantly speed up large file transfers through tor. Also been suggested before. If a new feature were added to tor's internal protocol that would allow handing off a thread from one circuit to another, then a further enhancement could be made because it would be handled entirely at the tor level. For example, a thread supported by (i.e., spread across) multiple tor circuits could be shifted across a frequently changing set of circuits between the client and the exit server, all under the control of the tor client. Used in i2p? For a fixed circuit length, such as the cons
Re: same first hops
On Wed, 08 Oct 2008 20:50:28 -0700 "F. Fox" <[EMAIL PROTECTED]> wrote: >M wrote: >> Thanx Gregory and F.Fox...understood the concept. Just one note though: >> >> "Tor (like all current practical low-latency anonymity designs) fails >> when the attacker can see both ends of the communications channel. For >> example, suppose the attacker is watching the Tor relay you choose to >> enter the network, and is also watching the website you visit." >> >> When it says "watching" does it mean? I thought the info was encrypted >> (except the last hop) and the IP invisible? Does it mean timing attacks? >(snip) > >Yes, it's referring to end-to-end attacks - which are usually timing >attacks; however, fingerprinting attacks (based on the total filesizes >of known target downloads, since encryption doesn't change the size of >data) are possible in theory, as well. > Well, technically speaking, I guess that's true. However, unless I'm greatly mistaken, the exit end of a circuit will compress any data coming into it to be relayed back to the client and will uncompress anything arriving from the client to be sent out from the exit. Given that the attacker might observe data in the clear going into the exit or coming out of it and could perform the same compression in order to know the length of the encrypted data, the attacker might be able to pull that off. Another complication for the attacker to deal with is the fact that a link between the client and an entry node may support multiple circuits, and each circuit may support multiple streams, all of which are multiply encrypted and whose data cells are commingled with the data cells of the others at the client end with no obvious way of distinguishing between the cells of one thread and the cells of any other thread traversing that particular link. However, in order to match the length up with whatever is sent/received by the suspected client, wouldn't the attacker need to make an assumption or two about the circuit length? If so, then introducing randomly varying circuit lengths ought to obfuscate things considerably for the attacker. Another possible way to complicate things for the attacker would be a variant of something has already been proposed, namely, using multiple data cell sizes within the circuit. As I understand it, the suggestions so far have been directed toward efficiency, e.g., sending long cells when there are enough data to exceed the payload limits of short cells. However, if short cells were randomly used when there are enough data for long cells, then the significance to the attacker of the distinction between long and short cells would be somewhat reduced. Tossing in occasional padding at random to produce a long cell that might have either had only minimally more payload than a short cell or even data for which a short cell would have been adequate ought to augment the attacker's obstacles. If more than two cell lengths were used, then these techniques ought to become even more effective against attackers. A third possibility might be to do at the tor level something that is already supported at the data link level in the BSDs and perhaps LINUX, namely, to use multiple physical links (circuits in the case of tor) to split the traffic load of a data link (stream in the case of tor) across multiple physical links. The downside of this method, of course, is that it multiplies the risk of a broken stream due to a tor node failure or lower-level failure. OTOH, it might also frequently and significantly speed up large file transfers through tor. If a new feature were added to tor's internal protocol that would allow handing off a thread from one circuit to another, then a further enhancement could be made because it would be handled entirely at the tor level. For example, a thread supported by (i.e., spread across) multiple tor circuits could be shifted across a frequently changing set of circuits between the client and the exit server, all under the control of the tor client. For a fixed circuit length, such as the constant length of 3 that is currently the standard in tor, the entry node and/or the middleman in each circuit could be replaced from time to time. A tor network that used all of these methods (including variable-length circuits) ought to provide a major nightmare (not to mention processing demands) for even a heavily funded and equipped attacker to untangle by the use of timing/sizing measurements. (It might also be overkill, I suppose.:-) 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."
Geode: some more headaches for TorButton? :-P
Link bounced from /.: http://labs.mozilla.com/2008/10/introducing-geode/ Looks like the upcoming versions of firefox will ship the support for W3C geolocation specification: what's better for a tor attacker to ask directly to the browser where its user lives? ;-) I'm quite confident there'll be a way to (easily?) disable this feature but it's scaring stuff nevertheless. ciao -- Marco Bonetti Slackintosh Linux Project Developer: http://workaround.ch/ Linux-live for powerpc: http://workaround.ch/pub/rsync/mb/linux-live/ My webstuff: http://sidbox.homelinux.org/ My GnuPG key id: 0x86A91047
Re: another DirPort DoS attacker
On Wed, 8 Oct 2008 23:34:00 -0400 Roger Dingledine <[EMAIL PROTECTED]> wrote: >On Tue, Sep 02, 2008 at 08:20:47AM -0500, Scott Bennett wrote: >> A short time ago, I found that 212.205.53.212 had several hundred open >> TCP connections to my tor server's DirPort, and very little relay traffic >> seemed to be getting past all of that. I've now taken steps to prevent such >> connections from that IP address. (That IP address has the hame >> sahrsmtp03.cosmote.gr.) Other tor server operators may (or may not) wish to >> follow suit. > >Hi Scott, > >I think I finally tracked down why these are happening. > >They are being generated by obsolete Tors, running 0.2.0.8-alpha or >0.2.0.9-alpha. Those Tor versions are hoping to find v3 identity key >certificates from the old v3 authorities, from back before we changed >their keys due to the Debian RNG bug: >http://archives.seul.org/or/announce/May-2008/msg0.html > >Tor periodically asks itself if it has all the v3 identity certs it >wants, and if it's missing any then it launches requests for them. The >bug introduced in 0.2.0.8-alpha (2007-10-12) >http://archives.seul.org/or/cvs/Oct-2007/msg00117.html >and fixed in 0.2.0.10-alpha (2007-11-10) >http://archives.seul.org/or/cvs/Nov-2007/msg00065.html >was that if there were currently fetches in progress for every cert >that's missing, it would make a request for "/keys/fp" rather than making >no request. > >That bug isn't a big deal when the certs you want are all available. You >get them eventually, and then you don't need them anymore so you stop >the connection flood. But if no caches have the certs either, you just >keep asking for them, and whenever a request is outstanding, you go into >a tight loop of connection flooding while you wait. Well, that's not the most obscure bug I've ever heard of, but also not an obvious one. > >The fix? Well, we can't go make those people upgrade. We don't even know >who they are. The fix I'm working on now is to generate new certs for >the two obsolete keys (only moria1 and tor26 were v3 authorities back in >version 0.2.0.9-alpha), so these old clients will finally get what they >want and shut up. (They still won't work, because the networkstatus >consensus they get won't be signed by any of the keys they demand >signatures from, but at least they'll cry quietly to themselves rather >than harming the rest of the network.) Roger, this is wonderful news. Thank you very much for taking the time to track it down. That's definitely a kind of traffic load that the tor network does *not* need. Because no other systems have harassed mine in that fashion since the date of the message you cite above, I'm guessing that the vast majority of tor users have updated beyond that version, but it's also apparent that some have not. > >I'll let you know how it goes, Okay. Whenever you announce that the faked certs are in place, I'll disable the pf rule and DirPolicy reject statement that are blocking that site at present. Thanks again. 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 * **