New low cost traffic analysis attacks and mitigations

Development
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
21

I think 1:1 App/Guard > multipl traffic types in one client. I want to edit the page to reflect that unless you are still unsure.

1 Like
22

You mean A) Increase Protection from Malicious Entry Guards: One Guard per Application is more important than B) New low cost traffic analysis attacks and mitigations? I guess that could be true.

  • Attack A) means zero connection privacy maybe for everything all the time.
  • Attack B) means the ISP can see which websites are visited all the time.

Yes, please edit.

A): What about users who only use 1 app, the Tor Browser and nothing else?

23

Yep. I even asked an expert to confirm.

They would be screwed, but only for browsing traffic at that point. Other stuff would be “safe”. Combining traffic may or may not provide a marginal protection, but if it doesn’t then all of your activities’ privacy is blown.

1 Like
24

I don’t know at all but I speculate it could be ~50-80% of Whonix users who only use the Tor Browser.

Also I don’t understand the distinction between application and activity here.

Common ground: Tor Browser is an application, OK. HexChat is another application OK. So far we agree. Now Increase Protection from Malicious Entry Guards: One Guard per Application claims “Tor Browser and HexChat” should use different Tor circuits. Alright.

But why does it matter? From perspective of Tor, it’s all just TCP traffic. Tor doesn’t look if it is coming from Tor Browser or HexChat. That difference doesn’t exist anymore at that level. (Except these applications are configured to use different Tor SocksPorts.

Now reductio ad absurdum.

  • User A): uses Tor Browser. HexChat, Thunderbird, OnionShare, Electrum, Monero → 6 applications → “you should use 6 different Tor entry guards”.
  • User B): uses Tor Browser for browsing, uses Tor Browser IRC Chat add-on or IRC webchat, uses cloud file send services, uses web wallet → 1 application → “you should use only 1 Tor entry guard”.

As more and more functionality moves from previously standalone applications (HexChat, Thunderbird, …) into the browser the less the distinction between applications makes sense to me.

It would sound a lot more convincing to me to tell user B “use a different Tor entry guard per activity”. Why should users not use a different Tor entry guard by activity?

  • [1] Considered true (?): use a different Tor entry guard per application
  • [2] Considered true (?): do not use a different Tor entry guard per activity

How can [1] and [2] be considered true at the same time?

25

1App:1G just assumes the worst and doesn’t attempt to create cover traffic, but argues for putting your apps/eggs in different guard baskets.

He never argues against segregating website visits to different guards so we can assume this is just as valid. Worth asking once a dialog starts, but logically this advice is equivalent. The idea is to fragment a user’s anonymous traffic so no guard can construct a full picture if it decides to be evil.

1 Like
26

Turns out everything I thought I knew about snowflake and bridges was wrong:

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

The stuff running in the browser is proxy for the actual bridge that someone hosts. All bridge types need port forwarding.

You need custom code to mix client traffic and bridge traffic. The benefits are only for Onion services not clients.

In short we can safely scratch that off.

1 Like