Foundation-Devices / tor

Tor plugin for Flutter
https://pub.dev/packages/tor
MIT License
18 stars 9 forks source link

Onion services #15

Closed sneurlax closed 1 year ago

sneurlax commented 1 year ago

See https://gitlab.torproject.org/tpo/core/arti/-/blob/main/README.md#hidden-service-onion-service-client-support:

Arti has support for connecting to Onion Services aka Tor Hidden Services. However, currently it is disabled by default.

In the meantime, if you would like to try it out, you can enable it on the command line (cargo run -p arti -o address_filter.allow_onion_addrs=true proxy). or edit your config file (set allow_onion_addrs = true in the section [address_filter])

Otherwise, the old MagicalBitcoin/libtor-sys based package did support onion services safely, so either waiting for arti or regressing to libtor-sys could enable onion services

MajesticBank commented 1 year ago

Client onion service support was introduced in https://forum.torproject.org/t/arti-1-1-6-is-released-now-you-can-connect-to-onion-services/8202 (June 30, 2023) and it's considered stable so onion services should be preferred for few reasons.

Their concerns why it's disabled by default (maybe not anymore in the latest version) : This is because Arti currently lacks the "vanguards" feature that Tor uses to prevent guard discovery attacks over time

'Vanguards' is system that protect guard nodes (two nodes, which you use for month and then pick new ones and so on) discovery by network observers over long period of time, which requires extensive resource and this kind of attack are very rare and more likely ( always ) to be directed at onion service itself rather then client since client spend short time in the network.

Tor -> Clearnet is convenient because tor have exit nodes, but privacy speaking is worst way you could utilize tor functionality. Vanguards issue also applies in this scenario.

Spending longer or predictable periods of time connected to clearnet website increase changes of traffic correlation attack several times.

Example: Electrum-like wallet query for address balances:

Tor -> Clearnet: Electrum node can log exit tor ip and list of 20 addresses that sent query at that moment ( one owner probably )

Tor -> Onion: Electrum node can log '127.0.0.1' and list of 20 addresses that sent query at that moment ( could be one owner or more )

Clearnet is dependent on HTPPS security is relaying on CA authority, which technically could issue another certificate for your website while onion services are protected in cryptographic way with public/private key.

Current Arti version is safe to be used as onion service client, from the point of the onion service they couldn't tell difference do client utilize or do not utilize Vanguards.

Current progress on the onion services in arti:

https://gitlab.torproject.org/tpo/core/arti/-/blob/main/CHANGELOG.md#arti-118-5-september-2023

icota commented 1 year ago

Thank you @MajesticBank for the bigger picture. We have debated this internally and since this plugin is meant to be embedded - as long as the app it is embedded in is not attacking the user (or has other vectors not in the app's control, like a browser) we should be good with enabling this.

I vote for allow_onion_addrs for now. We will also monitor the upstream issue and upgrade accordingly.

sneurlax commented 1 year ago

Thanks for the code showing how to enable it! Feel free to merge that and close this issue.

We will probably wait to see if 1.1.9 or another later version enables onion services by default. 1.1.7 nor 1.1.8 brought guard discovery mitigations. While these attacks would be rare, re:

as long as the app it is embedded in is not attacking the user (or has other vectors not in the app's control, like a browser) we should be good with enabling this.

I'm not sure they'd require clientside collusion. But regardless, the decision isn't mine or I'd vote for a regression to MagicalBitcoin/libtor-sys! Better safe than sorry, folks :)

sethforprivacy commented 1 year ago

Thanks for the code showing how to enable it! Feel free to merge that and close this issue.

We will probably wait to see if 1.1.9 or another later version enables onion services by default. 1.1.7 nor 1.1.8 brought guard discovery mitigations. While these attacks would be rare, re:

as long as the app it is embedded in is not attacking the user (or has other vectors not in the app's control, like a browser) we should be good with enabling this.

I'm not sure they'd require clientside collusion. But regardless, the decision isn't mine or I'd vote for a regression to MagicalBitcoin/libtor-sys! Better safe than sorry, folks :)

One note here: from my understanding this attack is only possible if the motivated attacker specifically knows and targets your hidden service, which for personal nodes wouldn't normally even be published, much less well known.

The attack isn't feasible without knowing this Onion address as the attacker has to be able to Sybil and become two malicious nodes in the path. This seems to only be applicable to well-known hidden services that are at risk of targeted attack. If your use-case intends for users to use your own well-known Onion address for Fulcrum etc. then I would consider this more of a risk, but we don't have that specific use-case here at Foundation as this usage would only be for users personal nodes by design.