It would be nice if hidden-service setup supported proxying to a local unix-socket. nginx, Twisted (and probably others) support this for HTTP for example.
This would reduce the chances of "accidentally" listening on a public TCP port (and eases the task of verifying this) and is somewhat faster.
I'm unsure if it's better to have a new config-item, or overlap with the existing hidden-service listening specification.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
I thought there was already a ticket for this, but I can't find one. Yeah, this is a fine idea.
For an example of how we support AF_UNIX in tor today, see how controller listeners on AF_UNIX work. Adding support for connections to an AF_UNIX address for a hidden service shouldn't be hard.
We have the client side of this implemented in https://trac.torproject.org/projects/tor/ticket/12585 and I strongly support implementing this for the Tor HS side. This will be really nice for Tails, especially but also for applications like OnionShare.
ould someone provide either a sample application or configuration for a server that supports such a socket? I suspect OnionShare would be a good sample application - which can also be heavily sandboxed in a useful manner.
I think in an ideal world, we'd also eventually ship a super minimal server - perhaps a libevent httpd or perhaps an OnionShare like service?
I'm a bit worried by the amount of #ifdef/#endif that this commit introduce in rend_service_set_connection_addr_port(). That makes code review and maintainability quite difficult over time imo.
Can I interest you guys in this kind of fix?: branch bug11485_026_v1, commit 233e8d9, created on top of nickm's branch.