[tor-dev] RFC: Ephemeral Hidden Services via the Control Port

[Yawning Angel]

On Mon, 16 Feb 2015 10:17:51 -0500
David Goulet <dgoulet at ev0ke.net> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150216/6c6eb6a5/attachment.sig>