New low cost traffic analysis attacks and mitigations

Development
1

Interesting blogpost that provides some technical meat.

It has some client side suggestions for thwarting website fingerprinting. I will quote here and if anything useful is covered we can spin them off into their separate phabricator tickets.

Users: Do multiple things at once with your Tor client

Thankfully we get this for free with Whonix’s design and thanks to stream isolation, safely at that.

We can do better by allowing users to run their client as a bridge we protect client traffic even more.

  • What bridge type is ideal for Whonix GW? The easiest and quickest to implement? (Snowflake?)
  • The GUI side option would be implemented as part of the anon-connection wizard.
  • Does running your client as a bridge allow you to you yourself connect to a bridge before Tor? Does this provide double benefits? Needs research probably.

Mozilla/EFF/AdBlocker makers: Investigate Real Time Bidding ad networks

Blocking ads in Tor Browser turns out to be an anonymity benefit and not just to get rid of an annoyance. The Tor Project is taking a soft stance on this for pragmatic political reasons. If they block ads outright they risk Tor being blacklisted even more as retaliation.

Investigating ad networks for transparency is impossible unless you have an inside view of how they run their systems. Not gonna happen.

Tails hasn’t given a fuck about ads or how blocking them makes their TBB differ from plain bundles since forever. We should seriously find the best solution for blocking ads today if we agree to do it and convince Tails to switch to it if they have a different solution so we can blend into a slightly larger group.

We already chose to implement more secure options for our distro even if the cost is an identifiable network fingerprint.

Website Operators: Use v3 Onion Services

Yet one more reason to deprecate v2 and advise against them in documentation

The rest of the advice in the article doesn’t apply to us.

2 Likes
2

Couldn’t we also create a script that creates normal-looking network traffic regularly to further protect users?

e.g. the script opens a connection to a few random websites for a random amount of time.

There’s a big difference between maybe being identified as a Whonix user via some advanced attack and definitely being identified by a Whonix user via any random website. It’s really easy to detect if ads are being blocked.

I’m against making any big changes like that to the browser. Best to wait for the Tor Project to do it.

1 Like
3

What are the costs of running a bridge? I’ve read the TorServers.net will set one up. I wonder if they have ever given an idea of bandwidth costs and up-keep. Or is a “Whonix Bridge” more of a negative than a positive?

1 Like
4

Not in scope. The idea here is to mix traffic from more people into the same node to provide cover for a user’s activities. What you’re suggesting is something similar to ad nauseaum which would load the Tor network without any real benefit since spoofed activity is easily filtered for especially for someone who does website fingerprinting.

Default ad blocking will never happen for the reasons mentioned. Tails has been doing it for years and it is worth considering now that ads sabotage anonymity.

Something like snowflake is trivial to run. Just keep your browser open for the addon to work. The other transports require NAT holepunching and just a bunch more steps that won’t be feasible on some networks or for all users’ skill levels.

2 Likes
5

https://lists.torproject.org/pipermail/tor-dev/2020-January/014114.html

1 Like
6

Agreed. Anything that requires to open a port in any users local physical modem/router is going to fail. Most won’t be able to do that. At best for advanced users.

Which options are left?

Snowflake? Is that a “real bridge” for the purpose of this issue that helps defeating this attack?

Does that contradict Tor Entry Guards - Whonix ?

The Design and Implementation of the Tor Browser [DRAFT] contradicts this.

Add uBlock Origin to the Tor Browser:

Network fingerprint from internet service provide (ISP) perspective. Not web fingerprint from website perspective.

Users would probably love ad blocking by default. So would I. We can consider ad blocking for usability too.

Ad blocking would worsen the fingerprint, so goes the argument. Is that really so? I speculate this argument might be mostly based authority and unrealistic expectations for future TBB improvements. But is it backed by actual knowledge, testing, data? Measurable worse?

See tbb-linkability [archive] and tbb-fingerprinting [archive]. I speculate these bugs might not br fixed soon, other similar issues are identified meanwhile. The worse fingerprint might not matter as TBB might never be good enough for ad blocking to matter?

Problem is that it is an “inside” Tor Browser issue. Once Tor Browser was inside modified, all Tor Browser issues would be blamed on Whonix. Similar to add Tor Browser first startup popup to ask whether security slider should be set to safest

“Inside” Tor Browser modifications are fragile as add Tor Browser first startup popup to ask whether security slider should be set to safest has shown. Tails cannot be compared much? Whonix / Tor Browser can be upgraded anytime. Tails not so much since its mostly release based updated?

quote Tips on Remaining Anonymous

1 Like
7

The only options deployed ATM are obfs4, meek and snowflake. The only configureless client side one is snowflake:

Currently there are three pluggable transports available, but more are being developed.

Of course. It routes other users’ traffic through your client.

It does. I think they don’t/can’t take usage models like the 1G/App into consideration since a very small number of users will run Tor that way. So the next best thing is to try to confuse the malicious guard by pumping in different types of traffic. So if we had to rate the from more to less effectiveness, then:

1 G/App > Multiple Traffic thru 1 G > One type of traffic thru 1 G

I see so they agree about the principle, but not the implementation. (upstream curation vs addon). Not a fan of security theater and this seems to be the case.

Although in the ticket about uBlockOrigin , arthuredelstein discusses they were working on shipping an adblocker that’s turned off by default and need to work a few things out for performance. The quote in the manual above may be outdated and was never changed to reflect reality. It was written before uBlock existed which is superior to all these options.

The 0.1% of ad networks that slip thru is not a strong argument against the benefits of blocking all the rest. We can think of the whole approach as on a spectrum vs being absolute. fpcentral - a site designed specifically for TBB fingerprint testing should answer these questions.

Depends on how easy these things are for a third party to uncover. First party isolation problems would be easy to fingerprint I imagine.

Fragility is a big enough argument against this alone. A great addition that always breaks and works half the time is not a good idea. As for the Tails vs Whonix fingerprint - we have to know if things like addon version are easily enumerated by sites.

With all due respect, pseudonymity becomes a liability over time and any mistake would uncover all a user’s past activities while anonymity provides forward secrecy of sorts. Anonymity is the ideal while pseudonymity is not fatal, but it can be if identities are not recycled after a short period of time.

Website fingerprinting (in this threat model) is about a malicious guard correctly identifying what the contents of an encrypted stream a user is requesting.

8

We certainly shouldn’t make everyone use a snowflake bridge by default without asking upstream, The Tor Project.

I faintly remember we asking The Tor Project if we could make everyone use the meek pluggable transport by default (or as an automatic fallback in case of connectivity issues)? The answer was “no, please don’t, as domain fronting produces actual costs”.

Also meek is probably slower? And less reliable connection stability? Switching a whole distribution to be using it by default is quite a change.

Quote Configure (Private) (Obfuscated) Tor Bridges

Always remember that bridges are not bullet-proof. The following is a reminder about bridge versus non-bridge anonymity:

Quote [archive] Roger Dingledine, cofounder of Tor:

[…] Bridges are less reliable and tend to have lower performance than other entry points. If you live in a uncensored area, they are not necessarily more secure than entry guards. […]

Quote question:

If that is true, that also means, that bridge users are sufficiently more vulnerable to attacks, which are circumvented by entry guards?

Quote [archive] Roger Dingledine, cofounder of Tor:

[…] They’re probably more vulnerable, but I don’t know if I’d say “sufficiently”. […]

Therefore, if I understood your suggestion right…

  • Could you please suggest to Tor Project to make everyone provide a snowflake bridge server by default in light of this? If they do that, this change would trickle down to Whonix too. If they refuse this, doesn’t this mean that this change may be unappropriated for Whonix too?
  • Could you please ask Tor Project if it would be a good idea if if Tails and/or Whonix would make everyone a snowflake bridge server by default? (Mention being a developer - we actually considering this. Isn’t a user contemplating this for theoretic purposes.)
9

It would never be done by default, nor is it appropriate for everyone. That was a concern already mentioned by upstream in past discussions. I suggested making it an option in the whonix connection wizard.

meek could never work for this as it needs a CDN Serverside. For traffic mixing to work you need a bridge transport that makes you the server.

We asked TPO about making everybody run a snowflake (not meek) bridge and we concluded it was a bad idea.

Offtopic: The fact that meek uses PRISM partner companies probably makes traffic analysis worse, but it’s a trade-off for better circumvention.

This time around, I never suggested everyone be doing it. I meant assessing doing the plumbing/installing the plugins/packages that would enable that and making a GUI option for it, if you think it is a good idea.

What I asked about was the consequences of both acting as and using a bridge at the same time for the different protection properties the provide. Something to document only:

https://lists.torproject.org/pipermail/tor-dev/2020-January/014114.html

1 Like
10

Who’s the intended beneficiary user type for this feature? Why would it be good if some people opt in to be a snowflake bridge? While at the same time being inappropriate if activated by default for all Whonix users?

1 Like
11

People using Tor/Whonix as a regular client or HS and need cover traffic to confuse webpage classifiers run by malicious nodes especially a bad guard.

People in censored areas benefit by getting more bridges “for free” while helping us stay safer.

Some of our users might be in censored areas themselves so them being a bridge makes little sense. It’s also unclear how both being and using a bridge affects anonymity. Others might not want to dedicate resources for whatever reason (quota/lack of interest) or don’t want random computers connecting to them under any circumstance - might grab attention on corporate and monitored networks with stringent traffic rules.

There are benefits, but it depends on each user’s situation. Opt-in is then the most sensible approach.

1 Like
12

Thanks for explaining. We have a good rationale now.

Yes, making bridge users host a bridge too make not be wise without consulting Tor Project first. Therefore this would not be a good default for all users (including bridge users).

This might have been a good default for public Tor network (non-bridge) users but you listed good points why this is not a good default for these users either.

How to run a snowflake bridge on Debian? We probably need to run snowflake standalone. Not using a browser extension / graphical user interface as this is harder to automate / control on Whonix-Gateway through the package manager apt. By using standalone, cli tools things get much easier. As snowflake standalone option:

Home · Wiki · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab

There are no premade, signed packages / binaries yet for snowflake server?

Are you sure snowflake servers (bridges) would receive a continuous amount of traffic? Because, if nobody is using the bridge, it wouldn’t provide any benefit for the purpose of the issue of this forum thread, I suppose?

Quote Better gamify the UX for snowflake extension (#31109) · Issues · Legacy / Trac · GitLab

Sometimes usage is low due to bugs but other times it could be due to very few clients using the system. Is there a way to reassure people that the extension is still working or will be useful in the future?

13

AFAIK the Snowflake WebExtension addon implements both client and server functionality and has already been rolled out.[1] In theory one should be able to interact with the addon using the same technique mentioned in the documentation you linked - may have to ask.

It is available in alpha TBB releases.[2]

Once we resolve the secure way to obtain the code it will be a matter of figuring out how to implement TBB as Tor safely on the GW.

[1] Creating a Snowflake WebExtension addon (#23888) · Issues · Legacy / Trac · GitLab

[2]

Integration with Tor Browser

2018-11-30: Snowflake is included in ​alpha releases of Tor Browser for GNU/Linux and macOS. Not Windows yet.

Further integration of Snowflake into Tor Browser is being tracked at ticket #19001.

It’s a Catch-22. Little usage because of bugs and bugs because not widely used/tested. Either way one has to break the cycle at some point by just deploying it out there and exposing it to more users. That way there will be more people connecting to users running the server, providing them with cover traffic.

Snowflake is the decentralized meek of the future. The sheer number of bridges and their dynamic nature makes it much harder to discover and block. It’s only a matter of time before it is endorsed as the top circumvention transport.

1 Like
14

While Tor Browser alpha might be able to use snowflake brides as a client, I don’t think it can be used to host snowflake bridges (server)?

Screenshots in Creating a Snowflake WebExtension addon (#23888) · Issues · Legacy / Trac · GitLab which discuss hosting a bridge do not show Tor Browser.

Snowflake WebExtension addon (any graphical user interface [GUI]) is unsuitable for Whonix-Gateway / as a choice in anon-connection wizard (ACW). This is because, well, I can’t “click” on the users computer for all users personally. I cannot set it up for everyone manually. And the final user experience isn’t supposed to the user to click anything either after choosing that option in ACW. All I can do is ship configuration files and/or run command line commands. Interacting with with a GUI from command line tools is hard.

Using a browser based solution has several technical challenges:

  • install a browser (very doable)
  • remove start menu entry (very doable)
  • start the browser (here it starts getting complicated [1])
  • install snowflake addon [2]
  • start snowflake addon [3]
  • stop the browser
  • update snowflake addon [4]

[1] Start the browser for real? So the user can really see it? Usability issue. Users would probably use the browser for other things too. Launching the browser for real requires X to be fully ready. Or maybe start the browser hidden using a simulated X environment using xpra or something.

[2] How does one install a browser addon from the command line?

[3] How does one enable snowflake from the command line?

[4] How does one update snowflake from command line?

If it’s not possible to do from command line, I don’t see how it can be automated with ACW.

It might be possible to solve all of this but that solution would be more complex and more fragile than not needing to interact with any GUI to start with.

This is similar to make TBB usable as “system Tor”, so latest pluggable transports and the tor-launcher graphical user interface can be used in Whonix

Therefore, any solution that does not involve using an GUI (except for an option for users to enable hosting a bridge in ACW) is best avoided. Therefore:

1 Like
15

Website fingerprinting meaning that an Internet Service Provider (ISP) that can observe an encrypted connection between a user and proxy (SSH, VPN or Tor) can still deduce what website is being used due to amount of traffic, timings, and whatnot.

In current configuration:

Alice → ISP → Tor Relay A

Tor Relay A being the entry guard of Alice.

How would hosting a snowflake or any bridge help?

Bob → Alice → ISP → Tor Relay B

Bob is a bridge user. Alice is a bridge host.
Tor Relay B being a relay which the Tor client of Bob has chosen.

How likely is it that Bob will also sent traffic to Tor Relay A? Because that would be required to obfuscate website fingerprinting. Am I right? How could it help that Alice isn’t only talking to Tor Relay A but also to Tor relay B? The traffic to Tor Relay A does not change. Website fingerprinting should still be possible in the same way.

Unless it is assumed that the whole internet uplink of Alice gets so busy that its connection to Tor Relay A suffers? That would mean that this works best of users with slower rather than faster uplinks?

Or is assumed that so many users use snowflake bridges that some snowflake bridge user would connect to Tor Relay A too?

Quote New low cost traffic analysis attacks and mitigations | The Tor Project

A similar argument can be made for mixing your client traffic with your own Tor Relay or Tor Bridge that you run, but that is very tricky to do correctly for it to actually help.

It links to vanguards/README_SECURITY.md at master · mikeperry-tor/vanguards · GitHub which seems to try to help onion services. Seems rather hard to grasp indeed. Doesn’t sound like “just run a snowflake bridge, done”.

Run the snowflake bridge under the same Tor process? Or a separate Tor process?

I would understand vanguards/README_SECURITY.md at master · mikeperry-tor/vanguards · GitHub as: run a (snowflake) bridge as a separate Tor process and then configure the system Tor process to use your own snowflake bridge? But wouldn’t that also reduce the number of Tor relays being used from 3 to 2?

16

+1 Needs research/asking upstream (I’ll do it soon) - One should be able to theoretically set the same options directly via addon prefs with a script.

xpra or passing a headless option with cli is the way to go.

We’d include the browser version alpha that has it or defer this entire project until it hits stable. It should have it out of the box

Via addon prefs theoretically or using the go commands in the docs above. Open question.

You don’t. TBB autoupdate handles this.

Absolutely.

17

Even add Tor Browser first startup popup to ask whether security slider should be set to safest failed.

Problem is “change by pref” / use with CLI is not a use case tested / considered by upstream. Therefore can easily break.

It’s really difficult to automate these things.

[1] I don’t think it’s included in Tor Browser. Even not in Alpha. As per:

I guess it’s either Firefox or Chromium. Tor Browser has WebRTC disabled - which would break snowflake?

It’s probably not a TBB thing. [1]

TBB autoupdate prompts for update. It does not automatically do it and restart the browser automatically? Requires clicks?

Standalone (non-browser) binary Home · Wiki · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab seems much easier to implement. Supposing compilation is easy and doesn’t require networking for other packages unavailable from packages.debian.org.

1 Like
18

Just to be clear about the web fingerprinting threat model for those following at home:

Website traffic fingerprinting is an attack where the adversary attempts to recognize the encrypted traffic patterns of specific web pages without using any other information. In the case of Tor, this attack would take place between the user and the Guard node, or at the Guard node itself.

Great question and one I didn’t know much about until you mentioned it.

Bridge, is designed to act as entry node (guard). There is no difference as far as number of hops with or without bridges when you connect to a given server. If there were three hops required to connect to given server without a bridge, there are three hops required to connect to a given server with a bridge.

Given this info it means both node and user traffic is mixed and sent along to 2 remaining hops and malicious nodes would be none the wiser whose machine it came from. Bridge mode turns you into a participant in the Tor network and so regular connections from your node to other relays shouldn’t be discernible from your own. I need to confirm if a user’s individual connections are still using a guard of their own or not vs being a guard proper .

Padding. Padding makes it confusing for ISPs to know if there is anything in the pipes. The newly implemented padding should make this confusing for other Tor nodes as well.

I Must ask. You’re coming up with good questions, keep them coming.

1 Like
19

https://lists.torproject.org/pipermail/tor-dev/2020-January/014115.html

1 Like
20

Documenting the current status:

1 Like