re: "tcp_tracing_internet.pdf"
This appears to describe an active network modulation attack (node DoS). Either hammer tree on nodes of the expected path and trace the modulation, or on all but the expected path to find unmodulated. It generally requires GPA, deploying nodes, or being one end of the path... in order to observe the results. And it's old news. As noted before, since Tor (and all other current anonymous overlays) nodes do not perform their own independant buffering, reclocking and contracting for expected hop parameters... this vulnerability will remain.
Anyone wanting to research, code, deploy, and present on such countermeasures would certainly be welcomed.
hella old news. oh look here's POC for end to end correlation https://var.thejh.net/git/?p=detour.git;a=blob;f=README
but why bother chatting about this since it's explicitly not in Tor's threat model to protect against a global passive adversary? if you want to protect against that then look into the vast mixnet literature.
anyway for breaking tor you can read lots of good papers such as (note that none of these papers present their definition of "hacking" or define well known terms like TCP and UDP ;-) :
The Sniper Attack: Anonymously Deanonymizing and Disabling the Tor Network https://www.freehaven.net/anonbib/cache/sniper14.pdf
Spying in the Dark: TCP and Tor Traffic Analysis http://freehaven.net/anonbib/papers/pets2012/paper_57.pdf
A Practical Congestion Attack on Tor Using Long Paths http://freehaven.net/anonbib/papers/congestion-longpaths.pdf
Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization https://www.freehaven.net/anonbib/cache/oakland2013-trawling.pdf
On Mon, Apr 10, 2017 at 01:21:05PM -0400, grarpamp wrote:
re: "tcp_tracing_internet.pdf"
This appears to describe an active network modulation attack (node DoS). Either hammer tree on nodes of the expected path and trace the modulation, or on all but the expected path to find unmodulated. It generally requires GPA, deploying nodes, or being one end of the path... in order to observe the results. And it's old news. As noted before, since Tor (and all other current anonymous overlays) nodes do not perform their own independant buffering, reclocking and contracting for expected hop parameters... this vulnerability will remain.
Anyone wanting to research, code, deploy, and present on such countermeasures would certainly be welcomed. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
dawuud -
grarpamp