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 * **
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: 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 constant
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
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
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: 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.
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: 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
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: 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: 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: 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.
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: 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: 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 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 * **
