New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add Tor support: onion listeners #8
Comments
Incidentally, this might require changing the CLI scripts from blocking-style calls to Twisted-style calls, because it sounds like getting Requests to use SOCKS is not a solved problem. See https://github.com/kennethreitz/requests/pull/478 for background. At this point we have decent unit tests, so I don't think this would hurt the stability of the blocking API. |
I've landed preliminary support for this in e04e840. Use |
I was going to recommend this, would take out the necessary rendezvous. |
BTW, with the recent (large) implementation/protocol changes I landed for 0.8.0, I might have broken our existing preliminary Tor support (I haven't had time to test it, and the unit tests don't cover it). If so, I'm sorry, and rest assured it it will return soon. |
I have tested it, and Tor support works. |
awesome, thanks! |
So the next step would be creating the hidden services in a manner similar to onionshare or is that out of scope for this project? |
Yup, creating hidden services is the next step. Just before the big 0.8.0 release, I added several messages with which the two sides can advertise their connectivity options to each other. There's an The second half is for the other side to notice both 1: "oh, hey, they can connect to Tor" and 2: "Oh, hey, I can start an onion-service", and then actually start the onion service. Once the service is running and we know the One trick with onion services is that they take a fairly long time to spin up, so you don't want to bother doing if the other side won't be able to use it, or if there's a better pathway to use (e.g. if the sender is behind Tor, but the receiver has a public IP address, then the sender should just use Tor and an exit node to reach the receiver). Also, there's no point in having both sender and receiver spin up a hidden service: one is sufficient. In most cases the sender is started before the receiver (the only exception being where you and I meet offline, agree on a code, then both go home and type it in). So there's a big chunk of idle time (after the sender starts, before the receiver finishes typing in the code) during which we could spin up the hidden service and not increase our overall latency. But we don't know if the receiver will be able to connect to it until after they startup and we get their first few messages. So I'm thinking that maybe we should have a (OTOH, I'm assuming that starting an HS imposes some load on the tor network, so it's polite to avoid doing it unless necessary.. maybe it's not that big of a deal, and we can just start one up every time we use |
reminder to myself: meejah says the best API in txtorcon-0.15.0 for this is probably:
Also, assuming that a side which doesn't use
If the non-
If we decided to aggressively spin up the hidden service any time we can, even if we have no idea if the other side can use it, we could flip that middle private+private case to |
My plan here is to add a
--tor
flag, which will:txtorcon
will be asked to create a new Tor instance)txtorcon
to create an ephemeral Hidden Service, and usetor:XYZ.onion:PORT
as the "direct hint", instead of scanning and revealing local IP addressesIf both sides are using
--tor
, they should be able to connect with the HS "direct hints". But if only one side is using Tor, the other won't be able to use the HS, so they must fall back to the relay.The text was updated successfully, but these errors were encountered: