[tor-talk] on the topic of tor's weaknesses

[grarpamp]

>>> It may take a while for a clientA to use said entry but when
>>> they do it seems it would be quite easy to time/count correlate
>>> or munge the HS traffic of clientA. And only require two nodes
>>> (hs, entry) and no GPA taps to do so.

>> That's why guards were introduced: They will not completely
>> eliminate the above class of attacks, but at least make it
>> statistically much less likely; since you will only use 3 out
>> of 800 or so guard nodes per month.

Though I did not explicitly say so, I implied the current state
with phrase 'take a while'... that today's client picks an 'entry'
node and makes it one of its 'guards'.


> OK, so taking that all into account, is it more likely that you
> will be de-anonymized using public services through tor (ie
> browsing the web) or using hidden services through tor?

I'm guessing equivalent. Unless using encrypted clearnet services.
For which (and under the above two node example) Sting can no longer
prove user was involved with certain content on the far side without
legal process to the host. Due to cost, time and log sync issues,
Sting would obviously prefer to run their own service, were it legal
to do so.

Though HS is more hops away, I doubt it would affect timing or byte
counting all that much.


>> Can such an entry know when it's being used as an entry by
>> whatever appears to its left? I think that is what I describe
>> relies on.

I was just unsure as to whether the entry (guard) could be instrumented
to, in fact, tell when it is being used as an entry by a client to
its left. That's the dead giveaway in this two node case afaik.

> The short but incomplete answer is yes.

And Msr. Syverson seems to indicate that it can be.


> See "Locating Hidden Servers"

My example is not about 'locating HS', only to locating users
(clients) with [an entry (guard) and an end node (clearnet exit or
HS)].


If it was the example, by similar construction...
Unless the last relay before an HS (indeed the HS's EG) could know
that an HS is the next jump to its right for some subset of the
traffic to said EG's right, Bust (as opposed to Sting) could not
pair its deployment of said HS_EG with its own client data pump to
find the HS.

Again a general picture:
client <> clientEG <> relayN <> HS_EG/relay <> HS/exit


>> Doesn't this mean bad news for users of hidden services,

> The important thing is to understand what security is provided
> http://freehaven.net/anonbib/

> Entry guards ...
> If one of them is evil, it will see the entry side of (a large
> fraction of) your circuits and will be able to associate you with
> your destination whenever you go to a hostile destination or use
> a hostile exit. What Lasse and I showed was that you weren't
> really much worse off from this than when choosing circuits with
> random entry relays.

Yes, the weakness seems clearer now. Unless there's a way to modify
the system so that the EG does not know it's an EG for a given
client stream to its left, it would just be a foregone fact of life
as part of the unsolved timing/etc attack class.


How much of a risk is it? Perhaps only canaries, or a realworld
test undertaken on this list, will tell.