"Practical onion hacking: finding the real address of Tor clients"

Fabian Keil freebsd-listen at fabiankeil.de
Mon Oct 23 12:22:36 UTC 2006


George Shaffer <George.Shaffer at comcast.net> wrote:

> On Fri, 2006-10-20 at 09:53, Fabian Keil wrote:
> > George Shaffer <George.Shaffer at comcast.net> wrote:
> > > On Wed, 2006-10-18 at 12:47, Fabian Keil wrote:
> > > > . . . They aren't attacking Tor, but misconfigured applications
> > > > behind the Tor client.
> > > 
> > > Which they said quite clearly in different words: "Clearly Tor's
> > > designers have done a pretty good job: I couldn't find any
> > > weaknesses in Tor itself . . . 
> > > So instead, I attacked the data which Tor carries the most of: web
> > > traffic."
> > 
> > Please don't quote out of context. I wrote:
> > "I also think the title of the paper is intentionally misleading."
> >                   ^^^^^
> 
> In case you did not notice, I used ellipses (". . ."), the standard
> English language notation for omitted content. I considered the part
> that I left out an unfounded personal opinion that needed no comment.

My whole point is that you have to read the paper before it becomes
clear that there was no actual onion hacking involved. I'm aware
that the author knows that he didn't attack Tor, but this
doesn't change the fact that the title mislead me.

> Since you seem to want me to address that, I will. For my first comment
> the actual title does not matter. You use the word "intentionally" as an
> adjective to "misleading." You start with "I also think" so you state
> this is opinion, and not necessarily fact, but basically you are saying
> that you think the authors are liars.

No, I'm saying that the title is misleading and I assume
this is intentional to get more attention.

If the paper was titled "Stating the obvious: as you already
know from reading the documentation, Tor isn't an intercepting
proxy and using a misconfigured browser has consequences", there
would be a lot less readers. 

> The second issue is a matter of fact to be determined. Is the title of
> the paper misleading? For that we do need the title. The subtitle is
> "Finding the real address of Tor clients." Unless the authors are liars,
> and I think they present enough evidence that that is not likely, they
> did find 86 addresses in one day. They did exactly what the subtitle
> said, so I don't see how it could be misleading.

While the author claimed to have found addresses of Tor clients,
he found addresses of the system where the browser is running,
and the addresses of the NAT system the browser is using.

In many (probably most) cases the browser and the Tor client
are running on the same system and share the same IP address,
but that's not guaranteed. 
 
> The main title is "Practical Onion Hacking:" and I expect your point is
> that they did not successful hack, crack, or break the Tor software,
> which everyone who read the article already knows. I think the first
> word "Practical" is important. I have come to expect, that when I see
> practical as part of the title of something in any way related to
> computer security, not to expect something esoteric, theoretical, or
> even necessarily very technical. What I do expect are topics loosely
> comparable to social engineering attacks or dumpster diving. These
> obviously have no relationship at all to the technical merits of any
> software, but they are part of the black hat arsenal.

Lets say I puplish a paper called
"Practical lock picking: opening closed doors",
whose content basically is: "I didn't find any flaws in the locks,
so obviously they are very well designed. I can't be bothered to
tell you which attacks I tried, but just believe me that I know
what I'm doing. So instead, I concentrated my efforts on the fact
that some people hide the key under a stone near to the door.
It's known to be bad practise, but some do it anyway. And oh my
god, my research shows that these keys can be used to actual open
the doors."

Do you still think the title would not be misleading?
After all everyone who reads the paper can tell that
there was no lock picking involved, and the subtitle is
true as some doors could be opened.

> > > In the meantime
> > > though, some users are depending on it for anonymity. You can be sure
> > > that someone in Red China, searching for information his or her
> > > government does not want them to see, is not likely to have mis
> > > configured or misused Tor for want of trying to get it right.
> > 
> > I assume you mean the opposite of the last sentence?
> 
> I've reread it multiple times, and while it may be complex or even
> awkward, I believe I said what I meant and meant what I said. To
> rephrase it, those referred to are highly likely to make every effort
> they can to get it right, and still some are failing.

I don't see the "and still some are failing" part in your first
sentence and read "is not likely to have misconfigured or
misused Tor" as the opposite. But then again, English is
not my native language.
 
> > Anyway, there will always be some people who don't
> > understand the documentation, or don't even bother to
> > read it. That's the case for every product and not a
> > Tor specific problem.
> 
> But products also vary greatly in how easy or hard they are to install
> and or use, as well as the quality of their documentation. The EEF warns
> that Tor is an "advanced" topic, i.e., not one for the technically
> unsophisticated. While Tor is easy to use once set up, it is definitely
> nearer the hard than easy end of installs. After it was installed there
> were at least a couple of places where I said to myself, oh now I see
> what they mean. The documentation, though abundant, leaves much to be
> desired. Unfortunately that is normally true of resource limited, young
> projects. It's also unfortunate that there is not likely any correlation
> between the need for anonymity and computer expertise.

Fortunately you don't need much computer expertise to find
solutions like Anonym.OS, which while not being perfect,
are good enough in many cases.
 
> > The risks of JavaScript, Flash and friends are mentioned
> > several times in the docs.
> 
> Haven't the authors of the report that you seem to object to so much
> made a dramatic demonstration of this. The products you mention are used
> by many content providers, and many web surfers, even knowledgeable
> ones, like the "rich" experience and are willing to sacrifice security
> and privacy for it.

And they constantly get what they deserve.

> As I was completely unaware of any of the work Paul
> Syverson referred to, this report got my attention much more effectively
> than the documentation I had seen. To me there is a big difference
> between simply stating something can be a problem, and a demonstration
> of actual compromises. If any of these older demonstrations are
> available online, then perhaps at least some of the references to
> applications or products that can compromise the use of Tor should link
> to them. If however, this older work remains only in the institutional
> memory of those closely associated with the Onion Routing project(s), or
> in off-line hard copy, for all practical purposes, the FortConsult
> report is new material.

It was already a well known and documented fact that Tor exit
nodes can alter unencrypted traffic. And even if this wasn't documented,
just thinking about it would make it clear. It was also a well known
fact that (with or without Tor) running scripts or binaries in your
browser has it's risks and that Tor itself doesn't intercept traffic.

> > > > It's also a good idea not to trust any exit nodes,
> > > > except the ones you run yourself.
> > > 
> > > If this is true, then the Tor network serves no useful purpose for
> > > the large majority of users who don't run Tor servers, let alone
> > > exit nodes.
> > 
> > Why? Just because you can't trust a exit node, doesn't mean
> > you can't use it. You just have to be aware that unencrypted
> > traffic might have been altered.
> 
> We seem to have different ideas about trust. I generally avoid any
> security or privacy product I don't trust. If you mean we have to assume
> that some (hopefully small) percentage of exit nodes are compromised,
> but that the likely (large) majority of good nodes, outweigh the risks,
> then we may agree.

Even if I'd assume that most of the Tor nodes are compromised (I don't),
I would still use the network because AFAIK it's currently superior
to the other solutions.

I also doubt that those compromised nodes are especially after me,
or that they are all working together. If the whole path
runs through compromised nodes which are run by different attackers
that don't share their data, my anonymity isn't compromised.

> > > Besides technical knowledge and
> > > connection limitations, there is at least one other valid reason for
> > > not running a Tor server. Comcast, the largest ISP in the U.S., has
> > > Terms of Use that very clearly prohibit any and all servers,
> > > including p2p, on any residential connection. I suspect some other
> > > ISPs have similar provisions.
> > 
> > That's a rather lame excuse. Even if your local ISP doesn't allow
> > you to run a Tor server, you can always get your own rootserver
> > and run your exit node from there.
> 
> I found a number of dedicated hosting solutions where you rent a
> dedicated server associated with "root server." These start at $99 per
> month. If I had that kind of money to spare, I think it would be better
> spent in direct contributions to EFF.org. 

In Germany the monthly fees for cheap root servers starts below 30€. 
Of course you don't even need a root server to run a Tor node,
many "virtual servers" work as well.
 
> I'm stunned anyone would make such a suggestion. Only someone already
> highly committed  to Tor would ever consider the time and expense of
> such an approach; there is a world of difference between changing a
> configuration option, if you have the bandwidth and your ISP allows it,
> and what you suggest. Tor needs a mass of users and servers to succeed.
> According to the graphs, servers are doubling annually. Trying to make
> Tor users without a server feel like second class citizens or simply
> unwanted, is a sure route to failure.

I'm not saying that Tor users without servers are second class citizens,
I'm saying that running your own server is the best way to increase
the number of nodes you can trust.

> There is another reason for not running a Tor server even if my ISP
> allowed it. I have a dedicated "stealth" firewall (protecting a personal
> desktop with little of intrinsic value). There is no chance I would poke
> holes in its configuration. That leaves only adding an additional
> machine, outside the firewall in a DMZ. Even if I had sufficient
> hardware, and was willing to deal with the routing issues, I'm not sure
> that I'd want a computer that announces the presence of a live computer
> at my IP address. When I put my security and privacy concerns together,
> I'd rather give up Tor than my current security configuration.

Anyone interested whether or not your IP address is currently in use
only needs to do a port scan. And if you can't trust your firewall
enough to work in cases where someone knows that your IP address is
in use, you should get a firewall that actually works anyway.
 
> There are also the potential legal issues which EFF addresses. In effect
> they say they may try to help you if you run into legal problems running
> a Tor server, but are more likely to help you assess the situation and
> find a lawyer. Engaging quality legal representation to defend against a
> serious legal challenge could easily bankrupt a middle income household.

Your are right, but of course this depends highly on your justice system
and there are countries where running a Tor node involves less risks
than in other countries.

Fabian
-- 
http://www.fabiankeil.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20061023/8b93ea7b/attachment.pgp>


More information about the tor-talk mailing list