Arti integration: onion services #503

New Issue

Closed

opened 2023-02-10 15:33:18 +00:00 by jpds · 5 comments

jpds commented

2023-02-10 15:33:18 +00:00

Contributor

Might be a bit early for this, but filing for future reference:

The Tor project has been porting their C based daemon to Rust, with the goal of making it embeddable:

https://blog.torproject.org/arti_030_released/

They've started landing the onion services API pieces:

It would be epic - if I could do:

garage bucket website --allow --tor www.mydomain.com
garage bucket website --allow --tor myonionsite

...and then garage leverages an embedded arti to:

Generate a new hidden service URL for the bucket
If a bucket is an FQDN, set the https://community.torproject.org/onion-services/advanced/onion-location/ header for users to be redirected
If not an FQDN, display to the admin the relevant URL to share
Announce these URLs through the garage gateways (possibly ones restricted with a tor label or something)

The last step could even deprecate https://gitlab.torproject.org/asn/onionbalance (for at least static sites)

Might be a bit early for this, but filing for future reference: The Tor project has been porting their C based daemon to Rust, with the goal of making it embeddable: - https://blog.torproject.org/arti_030_released/ They've started landing the onion services API pieces: - https://blog.torproject.org/arti_111_released/ - https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/970/ It would be epic - if I could do: ``` garage bucket website --allow --tor www.mydomain.com garage bucket website --allow --tor myonionsite ``` ...and then garage leverages an embedded arti to: 1. Generate a new hidden service URL for the bucket 2. If a bucket is an FQDN, set the https://community.torproject.org/onion-services/advanced/onion-location/ header for users to be redirected 3. If not an FQDN, display to the admin the relevant URL to share 4. Announce these URLs through the garage gateways (possibly ones restricted with a `tor` label or something) The last step could even deprecate https://gitlab.torproject.org/asn/onionbalance (for at least static sites)

👍 1

quentin commented

2023-02-28 17:41:01 +00:00

Owner

cc @trinity-1686a

trinity-1686a commented

2023-02-28 20:13:39 +00:00

Owner

Hi @jpds, Deuxfleurs member and Tor core contributor there 👋

Might be a bit early for this

It's indeed a bit early, Arti just started parsing documents and cells related to onion services, it'll be a few months before we can actually try to do anything. But we can still discuss the idea.

This would be a very nice feature in my opinion, but I'm not sure it should lie in Garage. Deuxfleurs uses its own reverse proxy, and I believe such a feature should be implemented in that class of software, rather than an object-storage+static website backend. The only argument I really see in favour of that feature being in Garage is that Tricot has no users that I know of besides Deuxfleurs, so it wouldn't profit that many people to implement this feature there. I'm very open to being convinced if you have more arguments!

Having some support for an integrated onionbalance would be very nice touch. That thing is very cool in theory, but it feels so much like an afterthough in practice. I can't recall the last time I saw it being used outside of eotk and some experimentations.

Hi @jpds, Deuxfleurs member and Tor core contributor there :wave: >Might be a bit early for this It's indeed a bit early, Arti just started parsing documents and cells related to onion services, it'll be a few months before we can actually try to do anything. But we can still discuss the idea. This would be a very nice feature in my opinion, but I'm not sure it should lie in Garage. Deuxfleurs uses its [own reverse proxy](https://git.deuxfleurs.fr/Deuxfleurs/tricot), and I believe such a feature should be implemented in that class of software, rather than an object-storage+static website backend. The only argument I really see in favour of that feature being in Garage is that Tricot has no users that I know of besides Deuxfleurs, so it wouldn't profit that many people to implement this feature there. I'm very open to being convinced if you have more arguments! Having some support for an integrated onionbalance would be very nice touch. That thing is very cool in theory, but it feels so much like an afterthough in practice. I can't recall the last time I saw it being used outside of [eotk](https://github.com/alecmuffett/eotk) and some experimentations.

👍 2

jpds commented

2023-03-01 11:48:43 +00:00

Author

Contributor

I'm not sure it should lie in Garage. Deuxfleurs uses its own reverse proxy, and I believe such a feature should be implemented in that class of software, rather than an object-storage+static website backend

The difficulty there is that there's no simple way of mapping the random hidden service URLs spawned by arti (in garage) into the multitude of external proxy implementations (in addition to having to run a separate arti instance at that level).

As opposed to Garage which would already know what the hidden URL is and already has a webserver (+ensuring the E2EE for the hidden service to the storage backend).

> I'm not sure it should lie in Garage. Deuxfleurs uses its own reverse proxy, and I believe such a feature should be implemented in that class of software, rather than an object-storage+static website backend The difficulty there is that there's no simple way of mapping the random hidden service URLs spawned by arti (in garage) into the multitude of external proxy implementations (in addition to having to run a separate arti instance at that level). As opposed to Garage which would already know what the hidden URL is and already has a webserver (+ensuring the E2EE for the hidden service to the storage backend).

lx commented

2023-03-01 13:31:35 +00:00

Owner

I think we can safely say that this is outside the scope of Garage. The best way to configure this is probably to add an Nginx reverse proxy somewhere that injects a Host header so that Garage loads the contents from the correct bucket. This also allows to add HTTPS support, which Garage's web endpoint does not (and will not) support. These kinds of configurations can easily be automated with e.g. NixOS.

I think we can safely say that this is outside the scope of Garage. The best way to configure this is probably to add an Nginx reverse proxy somewhere that injects a `Host` header so that Garage loads the contents from the correct bucket. This also allows to add HTTPS support, which Garage's web endpoint does not (and will not) support. These kinds of configurations can easily be automated with e.g. NixOS.