Once again: Tor timing attacks and a Tor confession

[grarpamp]

On 2/29/16, Steve Kinney <admin at pilobilus.net> wrote:
> On 02/29/2016 06:38 AM, Georgi Guninski wrote:
>
>> Is it theoretically possible at all to make low latency
>> anonymity of sufficiently decent quality?
>>
>> "sufficiently decent" is not well defined i agree.
>
> Bingo.  How fast do you want web pages to load, vs. how much do
> you want it to cost to de-anonymize your traffic?

In ATM the cost was unfilled buckets... here, filling them
even with junk (if not useful protocol)... is beneficial to you.

Tradeoffs may also have sweet spots and asymmetric scales.

The other meaning of "fast load" vs "$cost" is of bandwidth / bytes
choices of the user to their ISP which is another topic and never "free".

> In the case of TOR, it has long appeared to me that its leading
> design objectives include

Hiding participants to a communication from each other, negotiating
their own encryption over the path, and confounding vanilla hop by hop
backtracing by police level jurisdiction based authorities. That's mostly it.

> competing on the speed front with
> unprotected networking and VPN services.

This is more a function of TCP's natural performance over WAN
than anything else. Also some OS's like FreeBSD now have
quite improved bandwidth x delay product handling in their stacks.

(tor-relays should really evaluate this when considering which
OS's to deploy as relays.)

> The benefits of this
> competition include a larger user base = larger anonymity set.

s/competition/nature/ , which may end up being achievable
with other designs as well.

> The drawbacks include "the government that pays for TOR also has
> the capability to defeat TOR."

Well, then go find funding from an enemy of your enemy who also has
no issue with what you're building. Or just don't accept strange money.
How many of you donated or bought anything? Oh noes!, the influence.
Next!

> Last time I checked, the TOR Browser ships with NoScript turned
> off by default, leaving it unprotected against a large family of
> side channel attacks.  This choice also looks like a convenience
> for technologically naive end users, again degrading the core
> security mission for the sake of a larger user base.

They've said as much. At least users can turn it on.

> In this case
> we do know that hostile State actors have used the deficiency to
> unmask users, via a honey pot attack exploiting javascript to
> phone home and report the users' IP addresses.

"Disclaimers confuse and ward off users, and aren't popular
in marketing departments."

> Leaving fill traffic on the "to do list" forever, pending the
> disappearance of vocal advocates who claim that cover traffic is
> not practicable - either "impossible!" or due to a perceived
> head-to-head performance contest with unprotected networking -

This is a head-in-sand mindset problem. They are useless to you
and will only hold you back. Go find other development partners.

> I personally consider TOR sufficiently decent to positively lock
> out routine commercial surveillance of end users.

Yes. ie: All of the current strong anonymity overlay networks successfully
fend off and are immune to the copyright MAFIAA, and all manner of other
civil, police and non-state adversaries. (Note that's real world in practice
now, vs current academic research attacks that may be deployed in
production by them in the future. And that's at the protocol of the network
level, not the age-old application layer exploit level.)

> Sufficiently
> decent to provide reliable protection against NSA assets when
> combined with physical OpSec, i.e. covertly using open WiFi
> routers and single use disposable computers for brief one-off
> sessions.

Yes. Physical location separation plus non pattern generation.

> Sufficiently valuable as an NSA collection asset to
> discourage routine harassment or prosecution of TOR users for
> petty offenses, which would reveal to more "valuable" targets that
> TOR does not protect them.

Yes. Though it still supplies profiling database and parallel
construction in that mode.

> So far we are only talking about passive attacks by an actor who
> can observe both ends of most TOR network connections.  More
> costly active attacks could defeat /any/ anonymizing network
> protocol based on onion or garlic routing protocols.  So whether
> or not to "fix" TOR at the cost of alienating the bulk of its user
> base due to performance issues might merit some debate.

Tor is fundamentally a tunneled circuit based encrypted network.
It was designed roughly 15 years before Snowden's confirmations
and before 911 in a time when networks were still mostly trusted
and GPA's effectively spying at scale much less attacking were only
in the minds of crackpot cypherpunks.

Tor's circuit design probably doesn't lend itself to fill traffic / management,
and bolting it on the side may be non ideal. (Those are open questions.)
Yet "Tor" without its original design model could hardly longer be called
Tor (or TOR) at that point.

If you want fill traffic, you're probably better off forking and gutting
it, or starting something completely new that incorporates ideas
from knowledge both inclusive and post Tor's design.

Tor is great at what it does well, which is a lot.
You just have to know what that is, and find (or make
in it or elsewhere) what it isn't good at.

> My preferred solution:  Defund the the agencies that can and
> almost certainly do defeat all current network anonymity
> protocols.  My program for accomplishing this objective:  Wait.
> They are hell bend on self destruction and Nature will provide.

You'll be dead by then. It's more fun to risk dying now ;)


Tor is looking at some forms of network fill traffic, which may
or may not be integrated to the entire network wide sense, or
useful in your own designs...

https://gitweb.torproject.org/torspec.git/tree/proposals/251-netflow-padding.txt
https://gitweb.torproject.org/torspec.git/tree/proposals/254-padding-negotiation.txt