Add an .onion mirror to https://accrescent.app and allow use from the client

[xtaltal]

Mirroring accrescent.app with an .onion site allows Tor users to access accrescent's website without anyone knowing that it is being accessed, besides the server hosting the .onion address. The same applies to usage from the application store client.

[lberrymage]

Creating a .onion site for https://accrescent.app seems relatively easy to do, and I'm open to doing that. Serving onions for all client services, however, is a comparatively daunting task and one I think deserving of a separate issue.

The reason serving onions for client services is so much more difficult is mostly because there is currently no Tor library for Android which meets our security requirements, including tor-android by the Guardian Project. Arti looks promising for the future, but it's not ready for production usage on Android with onion services yet. Additionally, Accrescent uses very large amounts of bandwidth by nature of it primarily serving large binary files. This could potentially place significant strain on the Tor network if we were to serve those files over an onion service. The latter may not be a significant issue if Tor connectivity were an opt-in toggle (which it almost certainly would be) and thus used by few users, but it's worth considering nonetheless.

[xtaltal]

Creating a .onion site for https://accrescent.app seems relatively easy to do, and I'm open to doing that.

At its baseline, this is true - it is relatively easy to do so and should require little additional maintanence. However, I actually considered that this would be more of a future thing to do when I wrote this issue, because ideally you are a point where you can have an HTTPS certificate for the .onion site that meaningfully asserts some form of ownership to your project.

HTTPS for the .onion is desirable, as it allows you to freely include it alongside "https://accrescent.app" here on GitHub and elsewhere. Without an HTTPS certificate, there is not chain of trust. You can go ahead and create the .onion site, but you must maintain a policy of not posting it anywhere outside of the website, or a policy of suggesting that users check it from multiple pages (as is done with a SHA256 hash on the readme file), otherwise we run the risk that GitHub's platform acts maliciously by replacing the .onion URL with a rouge URL.

So yes, this is fine, just be careful about usage.

Serving onions for all client services, however, is a comparatively daunting task and one I think deserving of a separate issue.

I understand your following concerns, and I have arranged your next message out of order to reply to them.

Accrescent uses very large amounts of bandwidth by nature of it primarily serving large binary files. This could potentially place significant strain on the Tor network if we were to serve those files over an onion service.

This is true. It would use twice as much bandwidth at once. I cannot explain it well, but the Tor Project organization might not like this use of the Tor network because it's not low bandwidth usage. The Tor network does allot appropriate resources to high bandwidth users vs. low bandwidth users as appropriate though, so it should be fine.

Another important concern is that since this is over the Tor network, it will be slow for your users. I would personally consider client use to at least be blocked on https://github.com/accrescent/meta/issues/10.

The reason serving onions for client services is so much more difficult is mostly because there is currently no Tor library for Android which meets our security requirements, including tor-android by the Guardian Project. Arti looks promising for the future, but it's not ready for production usage on Android with onion services yet.

First, these libraries are not ready to host onion services from the Android device. This is a different use from the idea here: connecting to an onion service. Connecting to an onion service is okay as far as I am aware.

Maybe I did not think this through very well, because I did not think your application would need to include a library to connect to Tor. If you did connect to Tor from the application itself, it would prevent the user from using a Tor VPN application. Tor over Tor is not easily possible because the Tor clients will block attempts at connecting to known Tor relays, and the Tor Project discourages Tor over Tor. We certainly would want the user to use a Tor VPN application instead of trusting individual applications to be connecting to Tor because of the trust model with Android networking.

I was thinking that you would simply replace the URL with the .onion URL and inform that user that their Tor VPN must be active. Is this too simple? You don't increase application attack surface with unknown libraries into the application.

Or maybe we can wait until Tor Project's Tor VPN application is more mature later. I wouldn't trust Guardian Project's work in this area either.

[xtaltal]

I really think that the bandwidth concerns somewhat fall out of scope and are not an issue. The concerns around security, the selection of library or code to use for connection to the Tor network, and usability issues would need to be resolved first and foremost.

[lberrymage]

First, these libraries are not ready to host onion services from the Android device. This is a different use from the idea here: connecting to an onion service. Connecting to an onion service is okay as far as I am aware.

It's possible I misunderstood their language on onion service support. Last I heard, the Tor project claimed that the Arti client support for connecting to onion services shouldn't yet be considered as secure as the C client implementation, but that was some time ago. However, to my knowledge they still don't have an official Android library, as this is planned for around 2.0.0.

Maybe I did not think this through very well, because I did not think your application would need to include a library to connect to Tor. If you did connect to Tor from the application itself, it would prevent the user from using a Tor VPN application. Tor over Tor is not easily possible because the Tor clients will block attempts at connecting to known Tor relays, and the Tor Project discourages Tor over Tor. We certainly would want the user to use a Tor VPN application instead of trusting individual applications to be connecting to Tor because of the trust model with Android networking.

I was thinking that you would simply replace the URL with the .onion URL and inform that user that their Tor VPN must be active. Is this too simple? You don't increase application attack surface with unknown libraries into the application.

That's a fair point. I didn't consider a user using a Tor VPN application in part because I don't know of any mature Tor VPN app I would feel comfortable having Accrescent recommend. But now that you mention it, that would probably be the ideal solution once a mature one exists.

[xtaltal]

That's a fair point. I didn't consider a user using a Tor VPN application in part because I don't know of any mature Tor VPN app I would feel comfortable having Accrescent recommend. But now that you mention it, that would probably be the ideal solution once a mature one exists

If we went with this option, then users can still choose to use any Tor VPN application, like Orbot, so I don't see why it would be better to wait. Ideally you have a way to tell which VPN application is running, but this just forces the user's decisions. is Accrescent's application-level security enough to keep Asscresent secure? If so, maybe the user's decision and anonymity/privacy should be in their own hands. They'd be using Orbot for the other apps anyways, so it necessarily can't be worse as far as I can tell?

As for Arti's security when connecting to Onion services, I think your reading was correct. I saw that Arti lacked support for Vanguards, and I thought it was only for hosting onion services as a server, but lack of Vanguards support was why Arti disabled connection to Onions services by default. Vanguards protects clients for hosting onion services and connecting to onion services.

https://gitlab.torproject.org/tpo/core/arti/-/issues/1402 This Tor Project issue should resolve your concerns about Arti security when connecting to onion services, but even so, Arti will still somewhat be in development for a long time and may not be mature enough. I may contact the Tor Project for the developer's comments on the security of Arti sometime later.

I would like your thoughts on the user's decision to use any Tor VPN application. I think Accrescent should not recommend any particular application though until a mature one exists, but rather to just say you need such an app in place.