lelutin
commented
6 years ago Hi there!
thanks for submitting this. I also feel that it would be a great feature to have users empowered to setup a .onion for their website. alternc's web interface should show some information to users about what to do for configuring a website (especially for things like wordpress that forces a redirection to its base url, taking over the role of the http daemon) just to make sure that it's always visible that it could not work and explain why and how to work around this.
I wonder how the tor daemon fares with scaling up the number of onion services that are run though. Our main alternc setup manages multiple hundreds of site.. so if we make this available and publicize it, I think we could easily reach 100 onion services on the same running daemon.
One idea to make this simpler would be setup only one onion service, and then have different subdomains of this. so it could be something like <domainname>.<bighashforonionservice>.onion
.. also I'm not super keen on giving control of the torrc to alternc, since we already have a puppet module that does a good job of managing this : https://gitlab.com/shared-puppet-modules-group/tor -- but integration in the web interface, and to make it configure apache to respond to the onion's subdomain would be necessary.
paulcmal
Adding support for Tor onion services would be great.
Config
When the service doesn't care what hostname is used to reach it, configuration is as simple as adding a few lines to
/etc/tor/torrc. One line to indicate a directory where Tor will generate & store private key and hostname, and one line per port you want to be served over Tor. Example config :↑ This will allow users over Tor to reach your onion service on port 80 (http), and redirect these requests to port 80 on the local machine, where Apache or Nginx will handle the requests.
If your service depends on the hostname provided, you need to configure it explicitely unless the protocol differentiates the address to reach the server and the virtual host to be reached.
The first case is best demonstrated by Wordpress, which generates pages on each request based on site settings defining the baseURL. To allow Wordpress to be served over different domains, one needs to add dynamic baseURL to their
wp-config.php:Jabber, on the other hand, usually has a way on the client-side to specify the address you would like to connect to without regards to the hostname in your JabberID. For example, the conversations.im client on Android will let you specify an onion address to connect to.
Security concerns
Restricting access to local IPs for some services or administrative parts is not safe in such a setup. The requests passing through Tor would arrive on your service (for instance your web server) as local requests. If you need such configuration and can't rely on HTTP auth or such, then you probably need to setup some form of isolation (container/jail) to ensure requests coming from Tor have a specific address/interface that can be filtered out on the service level when needed.
Riseup also has great docs on general security concerns and best practices when dealing with onion services.
Implementation
I've taken a look at alternc-certbot. It seemed to me like a good place to start looking. However the documentation on plugins integration (for example regarding hooks) feels a little incomplete to a complete newcomer.
I do not use (yet) Alternc on a daily basis and do not feel like trying it out on my own just to implement this Tor thing. But if there is another hackathon soon, i'll be glad to drop by Paris (i'm not far) and hack around as i can (i'm no expert). Please note that although i would like to contribute this feature, i don't feel like maintaining a package in the long run.
Onion services v3
The Tor project recently announced the new harvest of onion services : v3. There's a ton of changes from address length to HSdir security concerns. Switching to the new onions is also not complicated as you just have to add
HiddenServiceVersion 3to your onion config in/etc/tor/torrc.Single Onion Services
The Single Onion Services implémenté avec Tor 0.2.9.8 mode (specs) allows the server to directly expose their onion service without passing through an onion circuit.
This allows to reduce latency and augment throughput when connecting to onion services, in exchange for public exposure of the server's IP address. The 'traditional' onion services scheme allows the server to reply through Tor, which is cool but in no way bulletproof anonymous.
With single onion services, we expose the onion service directly, which allows to use the onion cryptography to keep client-server communication secret and keep the client anonymous to the server because the clients reaching the onions would do so through a proper Tor circuit, which prevents server-side and ISP-level client IP logging.
So Single Onion Services are not anonymous on the server side, but they keep client-server confidentiality and client anonymity which is probably what we want when we configure an onion service to reach services that are already reachable outside of Tor.
Conclusion
I feel like it's really important for self-organized hosting coops/collectives to be able to provide support for easy-to-setup onion services, and AlternC is used in many of these structures. Is this feeling shared among the AlternC community? How do we move forward? :)