On Mon, 16 Feb 2015 10:17:51 -0500 David Goulet <dgoulet@xxxxxxxxx> wrote: [snip] > A hidden service is created using the key and list of > port/targets, that will persist till configuration reload or the > termination of the tor process. > > Now, an HS bound to a control connection might be a good idea, I'm not > 100% sure but I can see issues with this. Let's say > "ControlListenAddress" is used, this means a TCP socket and it can > timeout if no activity, so if that happens, I loose my HS? That's correct, though unless tor or the controller library has code to stomp on long dormant connections (which a casual look says there isn't), this shouldn't happen, because TCP/IP in itself has no idle timeout (See RFC 1122 4.2.3.6 regarding keep alives, which would also not cause HS loss, since the OS will respond to the probe). There may be certain broken middleboxes (loadbalancers etc) that stomp on long idle TCP connections, but anyone that is running a control port connection through such a thing, and sending RSA keying material in the clear, probably has bigger things to worry about. > This also put quite a requirement on the user side to add an HS on its > tor-ramdisk for instance but has to use a client that keeps the > control connection opens for its lifetime?... How does that work with > stem, it would have to keep the control connection open and the > script using it can't quit else the socket gets closed by the OS? Yup, I don't see "you need to leave stem running" as being all that bad, since this is mostly targeted at managed applications (chat, filesharing, global leaks, etc). If someone has a suggestion for an alternative interface that can handle applications crashing (possibly before they persist the list of HSes they need to clean up), applications that are just poorly written (and not cleaning up all the ephemeral HSes), and (optionally, though lacking this would be a reduction in features) limiting cross application HS enumeration, I'd be more inclined to change things. Regards, -- Yawning Angel
Attachment:
pgpqOws6ITnOf.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev