Slo-Tech - Raziskovalci Sambuddho Chakravarty in Angelos D. Keromytis iz Columbia University ter Angelos Stavrou iz George Mason University so 30. maja letos na konferenci Security and Privacy Day @ Stony Brook predstavili prispevek z naslovom Approximating a Global Passive Adversary against Tor.
V prispevku so predstavili izviren način razkritja identitete oz. identifikacije uporabnikov Tor omrežja ter razkritje lokacije skritih strežnikov (tim. hidden services).
Raziskovalci so pri tem uporabili metodo merjenja pasovne širine, ki je na voljo, LinkWidth. Metoda pri merjenju pasovne širine uporablja TCP RST pakete stisnjene med TPC SYN pakete, pasovno širino, ki je trenutno na voljo, pa nato oceni na podlagi razpršitve TCP RST/ACK paketov. S pomočjo te metode je mogoče oddaljeno izmeriti dopustno pasovno širino katerekoli internetne povezave in sicer brez posredovanja uporabnika te povezave ali njegovega ponudnika dostopa do interneta.
Raziskovalci so s pomočjo spreminjanja pasovne širine anonimne povezave ter metode LinkWidth lahko spremljali spremembe v pasovnih širinah v Tor omrežju. Na ta način so lahko identificirali IP naslov uporabnika Tor omrežja (identifikacija sicer ni mogoče v vseh primerih). Z ustrezno koordiniranim napadom je mogoče uporabnika anonimizacijskega omrežja Tor identificirati v manj kot 20 minutah.
Poleg anominizacije Tor omrežje ponuja tudi postavitev skritega internetnega strežnika v Tor omrežju. Tak strežnik je dostopen le znotraj Tor omrežja, anonimizacijski sistem pa skrbi za to, da njegova prava lokacija ostane skrita. A raziskovalci so v svoji predstavitvi predstavili tudi način identifikacije pravega IP naslova lokacije skritega strežnika (hidden service) v približno 120 minutah.
Novice » Varnost » Predstavljen nov način napada na anonimizacijsko omrežje Tor
Pyr0Beast ::
Jeba ...
Torej bo moralo omrežje pošiljati podvojene ali pa fakane podatke da zafrkne proggy ?
Torej bo moralo omrežje pošiljati podvojene ali pa fakane podatke da zafrkne proggy ?
Some nanoparticles are more equal than others
Good work: Any notion of sanity and critical thought is off-topic in this place
Good work: Any notion of sanity and critical thought is off-topic in this place
Pyr0Beast ::
Mislil sem, da ga potem naslednji tor strežnik sfiltrira ali redirecta, .. ja no. Slepi promet to odlično opiše [:D]
Some nanoparticles are more equal than others
Good work: Any notion of sanity and critical thought is off-topic in this place
Good work: Any notion of sanity and critical thought is off-topic in this place
infiniteLoop ::
Upam, da ns ne bojo prisilili v to. Slepi promet namrec nikomur ne koristi in obremenjuje omrezje. Hja kaj cmo ce ne gre zlepa...
None of us is as dumb as all of us.
Azrael ::
Khmm, ni bilo ob prvih predstavitvah Tor govora o slepem prometu in podobnem smetenju in naj bi bilo to kar po default? A sedaj pa šele bo?
Aha, tipično za [saj vemo koga], veliko obljub in skoraj nič narejenega, kot je treba.
In še dokler stvar stoji na TCP/IP protokolu, lahko kvečjemu samo podaljša čas do razkrija, anonimnosti na dlogi rok (je to sedaj 20 min) ali v primeru striktne hrambe prometnih podatkov ne zagotavlja.
p.s. ShieldsUp na grc.com še vedno pogrunta pravi IP, če se tja narišeš preko Tor ali so vsaj to malenkost že zgruntali kako zaobiti?
Aha, tipično za [saj vemo koga], veliko obljub in skoraj nič narejenega, kot je treba.
In še dokler stvar stoji na TCP/IP protokolu, lahko kvečjemu samo podaljša čas do razkrija, anonimnosti na dlogi rok (je to sedaj 20 min) ali v primeru striktne hrambe prometnih podatkov ne zagotavlja.
p.s. ShieldsUp na grc.com še vedno pogrunta pravi IP, če se tja narišeš preko Tor ali so vsaj to malenkost že zgruntali kako zaobiti?
Nekoč je bil Slo-tech.
jype ::
Azrael> Aha, tipično za [saj vemo koga], veliko obljub in skoraj nič narejenega, kot je treba.
Saj Tora ne programira Microsoft, da bi bilo to tipično.
Saj Tora ne programira Microsoft, da bi bilo to tipično.
Azrael ::
Seveda ne, tam stvar v drugi ali tretji verziji bolj ali manj dela to kar so obljubili za prvo verzijo. Tukaj gre pa po temle principu.
Sedaj pa nazaj na topic.
Sedaj pa nazaj na topic.
Nekoč je bil Slo-tech.
talmai ::
Joj, Azrael, ubožček. Če nisi kompetenten, se raje ne smeši z uporabo zahtevnih inovativnih orodij v razvoju. Izpadeš kot fotografski amater, ki od profi fotoaparata pričakuje autofocus in potem vse pošlje v tri pirovske, češ kakšen beden objektiv.
PaX_MaN ::
Če piše v fičrs "uber autofocus, better than any!!!!!111" bi nekako pričakoval da to ima, kne?
Azrael ::
Točno tako.
SW v razvoju se označuje nekako tako:
Ena takih tehnik je recimo da je promet v Tor omrežju vedno 100%. Kadar se ne prenaša nič pametnega, se prenaša dummy promet. Ker je kriptiran in ker so vse povezave ves čas na 100% bandwitha pa od zunaj ne moreš ugotoviti kako poteka routing.>zahtevnih inovativnih orodij v razvoju
SW v razvoju se označuje nekako tako:
Please bear in mind that SW is still in alpha stage, meaning it is not feature complete and is not recommended for everyday use.Ta hype in paranoja, ki se zganja ob Tor, je IMHO zelo nemoralen način iskanja beta testerjev, ki ne testirajo v sandboxu, ampak kar v RL. Mogoče OK za razvoj SW, za beta testerje, ki večina sploh ne ve tega, pa sploh ne nujno, daleč od tega.
Nekoč je bil Slo-tech.
poweroff ::
Azrael - vseeno boljše nekaj, kot nič. Sicer sem bral tudi mnenja, da tale napad ni res kritičen, ampak tega nisem vključil v novico.
Se mi pa zdi, da se vam bo kmalu kolcalo po anonimizaciji. Če prej ne, ko vas bodo zaradi P2P pričeli izklapljati...
Zato potrebujemo razvoj. In zato je javni pregled in odkrivanje napak nekaj najboljšega, kar se nam lahko zgodi.
Se mi pa zdi, da se vam bo kmalu kolcalo po anonimizaciji. Če prej ne, ko vas bodo zaradi P2P pričeli izklapljati...
Zato potrebujemo razvoj. In zato je javni pregled in odkrivanje napak nekaj najboljšega, kar se nam lahko zgodi.
sudo poweroff
KoKi ::
p.s. ShieldsUp na grc.com še vedno pogrunta pravi IP, če se tja narišeš preko Tor ali so vsaj to malenkost že zgruntali kako zaobiti?
Ne pa ne.
# hackable
poweroff ::
Azrael - razvoj tora poteka precej hitro. GRC pa je izvedel trik z JavaScriptom, ta problem pa rešuje TorButton (jup, so že vgradili ustrezne blokade, nekatere pa še bodo).
Glede tega napada pa komentar Mikea Perrya:
A handful of comments about the paper (many of these they themselves
brought up, but some they did not):
0. They are really an active adversary here. They need to be
controlling a website in order to unmask users, or have control of
some exit nodes or their upstream routers, and must modulate the
bandwidth of TCP connections considerably (+/- 30-40KB/sec or more,
for a period of 10 minutes).
1. Their results for path recognition (25% false negatives, 10% false
positives) are based on their limited sample set of only 13 trial
circuits via a small set of nodes that must be geographically close to
and well-peered with their pinging 'vantage point(s)'. I suspect
reality is a lot less forgiving than this limited sample size
indicates when more nodes and trials are involved using the real Tor
path selection algorithm.
2. The bandwidth estimation technique they utilized (based on TCP
Westwood/CapProbe/PacketPair) is very sensitive to any queuing and
congestion that occurs between the target and the 'vantage point(s)'.
As soon as congestion happens along the path, these types of estimates
report a large amount of excess capacity (rather than no capacity) due
to the acks/responses getting compressed together in queues. The way
this has been 'fixed' in TCP Westwood+ is to filter out the high
estimates and perform weighted averaging to smooth fluctuations
(precisely what they are trying to measure). It would have been nice
if they provided some more realistic testing of their bandwidth
estimation consistency using real world nodes as opposed to the lab
results on half-duplex ethernet.
3. Based on my measurements last year, only the top ~5-10% nodes are
capable of transmitting this much data in an individual stream, and
only if all of the nodes in your path are from this set. Furthermore,
as load balancing improves (and we still have more work to do here
beyond my initial improvements last year), these averages should in
theory come down for these nodes (but increase for slower nodes). So
how they will fair once we figure out the bottlenecks of the network
is unknown. They could do better in this case, but it is probably more
likely the average stream capacity for most nodes will drop below
their detection threshold.
4. Right now these few fast nodes carry about 60% of the network
traffic. A rough back of the envelope calculation based on our
selection algorithm means that only ~22% (.6*.6*.6) of the paths of
the network have this property for normal traffic, and only ~4.5% of
hidden service paths (which are 6 hops).
5. Their error rates do get pretty high once they've begun
trying to trace the stream back to its ISP (on top of the rates for
just path recognition). Any other fluctuations in traffic are going to
add error to this ability, and I imagine traffic fluctuates like crazy
along these paths. They also assume full a-priori knowledge of these
routes which in practice means a full map of all of the peering
agreements of the Internet, and 'vantage point(s)' that have no
queuing delay to all of them..
A couple countermeasures that are possible:
1. Nodes that block ICMP and filter closed TCP ports are less
susceptible to this attack, since they would force the adversary to
measure the capacity changes at upstream routers instead (which will
have other noise introduced due to peers utilizing the link as well). I
am wondering if this means we should scan the network to see how many of
these top nodes allow ICMP and send TCP resets, and if it is feasible to
notify their operators that they may want to consider improving their
firewalls, since we're only talking about 100-150 IPs here. There are a
lot more critical things to scan for though, so this is probably lower
priority.
2. Roger pointed out that clients can potentially protect themselves
by setting 'BandwidthRate 25KB' and setting 'BandwidthBurst' to some
high value, so that short lived streams will still get high capacity
if it is available, but once streams approach the 10-20minute lifetime
needed for this attack to work, they should be below the detectable
threshold. I think this is a somewhat ugly hack, and should probably
be governed by a "High Security Mode" setting that would be
specifically tuned to this purpose (and be a catching point for other
hacks that protect against various attacks but at the expense of
performance/usability).
All this aside, this is a very clever attack, and further evidence
that we should more closely study capacity properties, reliability
properties, queuing properties, and general balancing properties of
the network.
Glede tega napada pa komentar Mikea Perrya:
A handful of comments about the paper (many of these they themselves
brought up, but some they did not):
0. They are really an active adversary here. They need to be
controlling a website in order to unmask users, or have control of
some exit nodes or their upstream routers, and must modulate the
bandwidth of TCP connections considerably (+/- 30-40KB/sec or more,
for a period of 10 minutes).
1. Their results for path recognition (25% false negatives, 10% false
positives) are based on their limited sample set of only 13 trial
circuits via a small set of nodes that must be geographically close to
and well-peered with their pinging 'vantage point(s)'. I suspect
reality is a lot less forgiving than this limited sample size
indicates when more nodes and trials are involved using the real Tor
path selection algorithm.
2. The bandwidth estimation technique they utilized (based on TCP
Westwood/CapProbe/PacketPair) is very sensitive to any queuing and
congestion that occurs between the target and the 'vantage point(s)'.
As soon as congestion happens along the path, these types of estimates
report a large amount of excess capacity (rather than no capacity) due
to the acks/responses getting compressed together in queues. The way
this has been 'fixed' in TCP Westwood+ is to filter out the high
estimates and perform weighted averaging to smooth fluctuations
(precisely what they are trying to measure). It would have been nice
if they provided some more realistic testing of their bandwidth
estimation consistency using real world nodes as opposed to the lab
results on half-duplex ethernet.
3. Based on my measurements last year, only the top ~5-10% nodes are
capable of transmitting this much data in an individual stream, and
only if all of the nodes in your path are from this set. Furthermore,
as load balancing improves (and we still have more work to do here
beyond my initial improvements last year), these averages should in
theory come down for these nodes (but increase for slower nodes). So
how they will fair once we figure out the bottlenecks of the network
is unknown. They could do better in this case, but it is probably more
likely the average stream capacity for most nodes will drop below
their detection threshold.
4. Right now these few fast nodes carry about 60% of the network
traffic. A rough back of the envelope calculation based on our
selection algorithm means that only ~22% (.6*.6*.6) of the paths of
the network have this property for normal traffic, and only ~4.5% of
hidden service paths (which are 6 hops).
5. Their error rates do get pretty high once they've begun
trying to trace the stream back to its ISP (on top of the rates for
just path recognition). Any other fluctuations in traffic are going to
add error to this ability, and I imagine traffic fluctuates like crazy
along these paths. They also assume full a-priori knowledge of these
routes which in practice means a full map of all of the peering
agreements of the Internet, and 'vantage point(s)' that have no
queuing delay to all of them..
A couple countermeasures that are possible:
1. Nodes that block ICMP and filter closed TCP ports are less
susceptible to this attack, since they would force the adversary to
measure the capacity changes at upstream routers instead (which will
have other noise introduced due to peers utilizing the link as well). I
am wondering if this means we should scan the network to see how many of
these top nodes allow ICMP and send TCP resets, and if it is feasible to
notify their operators that they may want to consider improving their
firewalls, since we're only talking about 100-150 IPs here. There are a
lot more critical things to scan for though, so this is probably lower
priority.
2. Roger pointed out that clients can potentially protect themselves
by setting 'BandwidthRate 25KB' and setting 'BandwidthBurst' to some
high value, so that short lived streams will still get high capacity
if it is available, but once streams approach the 10-20minute lifetime
needed for this attack to work, they should be below the detectable
threshold. I think this is a somewhat ugly hack, and should probably
be governed by a "High Security Mode" setting that would be
specifically tuned to this purpose (and be a catching point for other
hacks that protect against various attacks but at the expense of
performance/usability).
All this aside, this is a very clever attack, and further evidence
that we should more closely study capacity properties, reliability
properties, queuing properties, and general balancing properties of
the network.
sudo poweroff
poweroff ::
Če še koga zanima, še eden od razvijalcev, Roger, se je oglasil v zvezi s tem. Toliko, da vidite, da se problema lotevajo resno in da v praksi ta napad ne pomeni konca projekta.
Right. We've gotten a copy of the paper from the authors, and we're
evaluating it. My current thoughts are that this is a brilliant new
theoretical attack, but how effective it can be on the current Tor
network is still an open question.
In other words, the next steps are to a) try to make the attack more
practical and see how flexible it can become, and/or b) learn from the
authors whether they know more than they wrote in their very brief and
unfortunately kind of vague analysis section. Alas, I'm busy the next
few days with our upcoming Tor releases, and will get back to talking
to them after that.
Interestingly, it appears that folks who transfer huge amounts of data
over Tor may be more vulnerable than the folks who have more moderate
loads -- maybe we've just found another argument against putting
file-sharing traffic over Tor. ;)
Since a lot of the countermeasures we're pondering are just a matter
of degree ("well, if the attack doesn't work when the foo level is
over .8, then try to make the foo level always .81"), we need a better
understanding of the limits of the attack before we can go about trying
to counter it.
My intuition is that it will turn out to be a fine attack, and we will
need to do something smart about it.
Speaking of which, there is another attack that's currently in this same
situation -- a brilliant theoretical attack, probably can be made to work
in practice, more work is required before we understand how effective
it can be:
http://freehaven.net/anonbib/#ccs07-lat...
One of the interesting features of these new network-property-based
anonymity attacks is that it appears they work even better against
single-hop proxy systems than against Tor. These attacks so far are of
the form "first do an attack to identify the Tor relays in the circuit,
and then hope you have enough time left to trace all the way to the
client location before the client moves". If the first half is trivial,
you have a lot more time for the second half.
So when you read our warning at startup:
"This is experimental software. Do not rely on it for strong anonymity."
be sure not to interpret it as a suggestion that there are any other
low-latency anonymity approaches that are considered better. As far
as I can tell, it's either use Tor or do nothing; and each user has a
different level of risk they can handle, so part of our ongoing work is
to figure out how much risk there really is.
Right. We've gotten a copy of the paper from the authors, and we're
evaluating it. My current thoughts are that this is a brilliant new
theoretical attack, but how effective it can be on the current Tor
network is still an open question.
In other words, the next steps are to a) try to make the attack more
practical and see how flexible it can become, and/or b) learn from the
authors whether they know more than they wrote in their very brief and
unfortunately kind of vague analysis section. Alas, I'm busy the next
few days with our upcoming Tor releases, and will get back to talking
to them after that.
Interestingly, it appears that folks who transfer huge amounts of data
over Tor may be more vulnerable than the folks who have more moderate
loads -- maybe we've just found another argument against putting
file-sharing traffic over Tor. ;)
Since a lot of the countermeasures we're pondering are just a matter
of degree ("well, if the attack doesn't work when the foo level is
over .8, then try to make the foo level always .81"), we need a better
understanding of the limits of the attack before we can go about trying
to counter it.
My intuition is that it will turn out to be a fine attack, and we will
need to do something smart about it.
Speaking of which, there is another attack that's currently in this same
situation -- a brilliant theoretical attack, probably can be made to work
in practice, more work is required before we understand how effective
it can be:
http://freehaven.net/anonbib/#ccs07-lat...
One of the interesting features of these new network-property-based
anonymity attacks is that it appears they work even better against
single-hop proxy systems than against Tor. These attacks so far are of
the form "first do an attack to identify the Tor relays in the circuit,
and then hope you have enough time left to trace all the way to the
client location before the client moves". If the first half is trivial,
you have a lot more time for the second half.
So when you read our warning at startup:
"This is experimental software. Do not rely on it for strong anonymity."
be sure not to interpret it as a suggestion that there are any other
low-latency anonymity approaches that are considered better. As far
as I can tell, it's either use Tor or do nothing; and each user has a
different level of risk they can handle, so part of our ongoing work is
to figure out how much risk there really is.
sudo poweroff
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Ali si z vpn pro res anonimen na netu (strani: 1 2 3 )Oddelek: Pomoč in nasveti | 26666 (24359) | poweroff |
| » | Plačljivi anonimizacijski VPN tuneliOddelek: Omrežja in internet | 6366 (5851) | enadvatri |
| » | Iran blokiral TOR, popravek na voljo še isti danOddelek: Novice / Varnost | 5186 (3590) | poweroff |
| » | Načrti za razvoj anonimizacijskega omrežja Tor v prihodnjih treh letihOddelek: Novice / Zasebnost | 5819 (4055) | Jst |
| » | problem downloadanja (prepovedano)Oddelek: Omrežja in internet | 2531 (1866) | ABX |