search

JesusMcCloud / netlayer

Tor Bindings for Kotlin/Java
European Union Public License 1.1
27 stars 24 forks source link

Allow netlayer to work with an existing tor #7

Closed mrosseel closed 6 years ago

mrosseel commented 6 years ago

Quite regularly, people with an existing tor installation are asking if Bisq (and with extension netlayer) could run using their own tor installation, and not by starting a new tor instance.

PS: some of those requests come from people running tails, but that's not the main focus of this ticket

JesusMcCloud commented 6 years ago

I fully understand the reason why people are asking for this and it is perfectly possible to provide this feature (after some work). I will put it on my todo list. Keep in mind, though, that using an existing tor installation will probably not result in a pleasant user experience, so don't expect too much…

i7qj2dlve2ehpapm commented 6 years ago

Referred here from Bisq forum. Sorry I can't make patch; I am developer, but I don't know Java. I ask support for this feature, for these reasons:

In case of Tor security vulnerability, power user with system Tor can update much quicker than Bisq and its dependencies can release new package. This is not hypothetical concern. Yesterday was released fixes for TROVE-2017-009/CVE-2017-8819 and TROVE-2017-013/CVE-2017-8823. Both affect v2 onion service, used by Bisq. TROVE-2017-013 is severity "High", use-after-free. Reporter of that bug crashed Tor while running Ricochet, another Tor bundler (obviously not through netlayer). All onion service tors should be updated immediately. Is netlayer's tor-binary updated yet, so Bisq can release update?

Well, to me that is the important but infrequent reason. Usual reason is this:

I can't use Bisq, because for years I have strict policy to prohibit direct access by applications to clearnet. All applications are network-isolated behind Tor gateway. I think I am not alone; it is policy of many power users, privacy activists, and also of out-of-the-box systems such as Qubes/Whonix (very user-friendly). Of course Tails also does much isolation.

Isolation is critical to security; and security is critical to privacy. I never worried about "leaks" of any kind; and even if application is totally compromised, my privacy is safe this way. For this principle, even official Sandboxed Tor Browser isolates the application much as it can from userland, and even filters SOCKS/control port for its own bundled Tor.

Of course whatever I say about "Bisq", applies also to any other application using netlayer.

Keep in mind, though, that using an existing tor installation will probably not result in a pleasant user experience, so don't expect too much…

Why not pleasant experience? With right setup, there is no significant performance difference. It is a little inconvenient to configure a control port filter (important: only whitelisted is login commands, ADD_ONION, and QUIT; applications are not allowed GETINFO, GETCONF, SETCONF, or any others). In some packaged systems, everything comes preconfigured for user. I don't see any downside.

Tor Browser works just fine with external Tor. It needs some environment variables set; power user can do this, or system packagers. Ordinary user will not shoot self in foot. The only downside (really an upside) is if you put a good control port filter, Torbutton can't display network path because, duh, it should never be able to find your "real" IP address or circuit path. It is obviously the number-one Tor application, by usage. If Tor Browser can make pleasant experience with external Tor, anything can!

For all this reasons - thank you for your attention to this feature.

(This message is posted using Tor Browser, through network isolating Tor gateway.)

JesusMcCloud commented 6 years ago

I fully understand your concern and I do agree that once everything is running, things should run smooth. Configuring the netlayer to work with an existing configuration will be tricky part. Your restrictive setup wrt. control commands could also prove problematic…

i7qj2dlve2ehpapm commented 6 years ago

Thanks for your working on this! When netlayer support Tor gateway, I am excited to maybe trade on Bisq in near future... hope so.

Just to answer one issue:

Your restrictive setup wrt. control commands could also prove problematic…

I am not alone there. Far from it. All most popular realworld use cases of external Tor is filtering the control port, including Tails:

If a compromised software had access to the Tor control port, an attacker who controls it could simply ask Tor the public IP through the GETINFO address command. To prevent this, access to the Tor control port is only granted to the root user, as well as to the members of the debian-tor group (via the control socket). A filtering proxy to the control port runs on port 9051 (i.e. the default Tor ControlPort), so for instance Torbutton still can perform safe commands like SIGNAL NEWNYM. It allows defining fine-grained access whitelists of commands (and their argunents) and events on a per-application basis, which can enforce rules like "this $user (e.g. amnesia) when running this $application (e.g. /usr/bin/onionshare) can only run these commands (ADD_ONION etc.) and listen to these events (e.g. HS_DESC, which is expected after a successfull use of ADD_ONION)".

Also Whonix filters the control port. Whonix (by @adrelanos) is out of the box included with Qubes OS, a userfriendly point/click platform with VM isolation. Tor runs in a dedicated VM, with filtered control port.

Tails and Whonix/Qubes are now the most popular userfriendly security/privacy/Tor platforms. Both got used by Edward Snowden; maybe he wants to trade on Bisq.

Obviously, to add new application in their filters require either advanced configuration, or distro packager work. They come preconfigured for various applications. Check their bug trackers for requests of new application support. If application can't be configured securely, maintainers need to say "sorry no", which make users sad and increases pointless support requests.

That is about "prepackaged".

I think most popular standalone control port filter is ROFLCopTor by @subgraph OS, derived in part from or-ctl-filter by @Yawning (the dev of Sandboxed Tor Browser). I know this is popular with Ricochet users, and elsewhere. Ricochet is basically same use case as Bisq, pure P2P with .onion address for user identity. So control port access needs of Bisq should be similar.

It's not some weird thing I do, filtering the control port. Nobody in right mind will give unrestricted control port access to application on isolated Tor. It's called "control port" for a reason, it can be used to get real IP address, spy on other application's circuits, and totally reconfigure Tor. Compromise all anonymity! There has been some controversy about this in the Tor bug tracker (example and other bugs), but we're stuck with it now - and people adapt by use these filtering control port proxies.

JesusMcCloud commented 6 years ago

No need to get touchy :) This will be an incremental process and I will need testers. First step will be to to get it working as is. It only makes sense to look into filtering after some basic support is there. Going for the full monty right from the start is not how successful development cycles usually work…

JesusMcCloud commented 6 years ago

Initial, very basic support is now implemented in v0.4 (in the tor.external module) It does not interface with tor wrt. configuration, but assumes a preconfigured hidden service

package org.berndpruenster.netlayer.tor.demo

import org.berndpruenster.netlayer.tor.ExternalHiddenServiceSocket
import org.berndpruenster.netlayer.tor.ExternalTorSocket
import java.io.BufferedReader
import java.io.InputStreamReader

fun main(args:Array<String>){

    val sock = ExternalTorSocket(34465,"google.com",443)
    val hsName = "x4hqvjg6pogtujst.onion"
    val server = ExternalHiddenServiceSocket(10024)
    Thread({
        BufferedReader(InputStreamReader(
        server.accept().getInputStream())).use { println(it.readLine()) }}).start()
    ExternalTorSocket(34465,hsName,10024).outputStream.write("Hello Tor\n".toByteArray())

}

Please let me know if this is a satisfactory mid-term solution

adrelanos commented 6 years ago

Do you know add_onion / Tor ephemeral onion services? In other words, Tor onion services can be created through Tor ControlPort. Then no pre-configured Tor onion service is required.

ephemeral: Means the onion service will be gone after the Tor control connection is closed. It's however possible and usual to retrieve onion service private key and to restore it at next run.

For example https://github.com/ricochet-im/ricochet by @special is doing that.

Tor ephemeral onion services would work a lot a lot better for Whonix than preconfigued Tor hidden services.

https://github.com/micahflee/onionshare by @micahflee has superb Tails and Whonix support.

    # In Whonix, listen on 0.0.0.0 instead of 127.0.0.1 (#220)
    if os.path.exists('/usr/share/anon-ws-base-files/workstation'):
        host = '0.0.0.0'
    else:
        host = '127.0.0.1'

Related: https://github.com/Whonix/proposals/blob/master/635-listen-port-convention.txt

In Whonix:

TOR_CONTROL_IPC_PATH=/var/run/anon-ws-disable-stacked-tor/127.0.0.1_9151.sock
TOR_SOCKS_IPC_PATH=/var/run/anon-ws-disable-stacked-tor/127.0.0.1_9150.sock

These are unix domain socket files.

Ports would also work but nowadays unix domain socket files are much more advisable since these are less likely to leak.

adrelanos commented 6 years ago
freimair commented 6 years ago

feature is available with version 0.6