[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Making TBB undetectable!

> but if attacker detect that someone is trying to hide
> it's identity when entering a powerful vile's email account or when
> trying to contact a high risk journalist, that might cost lives.

But if you're doing something (in the adversary's eyes) that serious, it
probably doesn't matter whether they can tell you're using TBB or not.
Either way, they're going to look at ways to identify you. Being one of a
crowd of Tor users likely offers more protection against that than trying
to make it difficult to identify that you're using Tor.

> undetectablizer Add-on is useful for private exit nodes.

The issue I have with the idea of private exits, is that not everyone can
use them. In other words, if you're using one, then you can be (however
loosely) associated with other users of that node. You all got
access/permission somehow, so you are now incredibly reliant on other users
not slipping up, and on the owner/operator not being traced.

If you've simply paid BTC for access, you then have to be very sure you've
not slipped up (simple examples: re-used a wallet, or funded one from fiat

Personally, I'd prefer a public exit, it's harder to associate users and
there's less room for making costly mistakes.

> There are limited numbers of data requests possible (check out
> browserleaks.com or browserspy.dk). We need list all of them and
> compare with other browsers to spoof what is different.

Those are a list of the requests we know are differentiators, it doesn't
mean that others won't be discovered, you'd need to gamble that anything
found is publicly disclosed when it's found, rather than kept quiet by an
adversary. What you're essentially asking for is a browser that behaves
like TBB (i.e. the various privacy protections) whilst pretending it
behaves like a Google Nexus (for example). It's not that it'd be impossible
to do, but one tiny mistake or oversight takes you straight back to being
finger-printable, and almost uniquely so if very few are using
Unidentifiable Mode.

> As far as I know you can't fetch installed Add-ons by javascript, it
> only works for plugins so it is not detectable either. Detecting
> Add-ons is done by side channel attacks, for instance Adblock prevent
> certain scripts or Noscript prevent certain objects, attacker can
> simply call such elements and find out those Add-ons are already
> installed or not.

Yes and no. You can't just run a list of add-ons off using Javascript,
however a fairly simple side-channel attack is to try and load images from
add-ons you care about detecting. If the add-on is installed and has
contentaccessible set (and your path is valid) then it'll load, if not,
it'll fail.

So, you can fairly easily poll for various add-ons. Not sure it'd affect
your add-on, but seemed worth mentioning.

> We just change details a browser return to calls in a way that caller
> can't recognize it is telling the truth or not.

How do you do this without breaking certain sites? For example, if my JS
configures absolute positioning based on screen-size (yes, it's a bad way
of doing things, and yes I've seen sites do it) then you reporting back a
600px screen is going to look terrible on a 1280.

> In a public wifi hotspot there is only one IP address and several
> clients simultaneously visit different websites. It would be very
> difficult for an attacker to find out a private Tor exit node is
> actually a Tor exit node

You'd need to be very careful about where your private exit is located. If
it's in a datacentre, then no-one's going to mistake it for a cafe (for
example). An adversary with sufficient resources would also soon be able to
look at data-rates to and from your box, as well as sources - shouldn't
take them long to realise it's communicating with Tor relays.

> Don't forget that it is not
> impossible to locate a user if a global adversary observe a big
> portion of globe and deanonymize Tor itself but we still trust Tor for
> anonymity thus we can trust undetectablizer Add-on in most of cases to
> remain unidentifiable either.

True, the difference here being that you're talking about something that
would be happening on a much smaller scale, and attempting to closely
replicate 'normal' fingerprints. A tiny mistake would be enough to
differentiate you from the 'normal' traffic, as well as from the 'standard'
TBB profile.

>> As others have said though, the aim isn't to hide that you're using Tor
>> from your destination, and successfully doing so would (IMO) be a pretty
>> non-trivial task
> What? Undetectabilizer Add-on's aim is exactly hiding that we're using
> Tor from the destination site.

To be clear - I meant it wasn't Tor's aim.

> Pluggable Transports aim to hide that
> we're using Tor from network observers located between user and
> entry-guards.

But not to hide that we're using Tor from the destination.

> Making undetectablizer Add-on is a trivial task.

Making it correctly is not trivial, you have no room for mistakes,
otherwise you risk becoming more fingerprintable than vanilla TBB

> If you give us only one practical example that let destination sites
> automatically separate TBB from vanilla Firefox or safari

Assuming we're talking about an unmodified TBB? I'd start by trying to
ascertain whether no-script is enabled. Working out whether HTTPS
Everywhere is enabled should be fairly trivial too. There are, of course,
plenty of people who run those in combination outside of TBB, but it's a
reasonable starting point for narrowing things down.

Someone who's suitably motivated will spend far more time and resources
looking at the minute differences in order to build a fingerprint.

Ben Tasker
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to