Onion-routing of The Free Software Foundation Europe
As a member of The Free Software Foundation Europe (web team) [<https://fsfe.org/>](https://fsfe.org/) i would like to formally request help with implementing onion-routing for our websites and gitea instance. The current effort is being tracked at https://git.fsfe.org/FSFE/fsfe-website/pulls/1756 with my public tracking on https://github.com/Kreyren/kreyren/issues/60 where any relevant information is greatly appreciated! -- - Krey
On 1/21/21 9:27 PM, Silvia wrote:
just got response from system-hackers. The load balancing is also considered important, proposals for the implementation are appreciated where we are currently looking at implementation using onion-balance [<https://gitlab.torproject.org/asn/onionbalance>](https://gitlab.torproject.org/asn/onionbalance). -- - Krey
On 1/21/21 9:27 PM, Silvia wrote:
Exciting to see fsfe moving to onions. How can we help you guys with this?
Currently the main problem is with implementation as there is an issue with certificates using TLS-over-onions (Not economical for non-profit foundation) where it seems that using reverse proxy with currently used Apache or implementing EOTK is the way to go there? More options and way to configure EOTK (alec seems to be currently busy and unable to answer) appreciated. Also brainstorm for the implementation as a whole would be appreciated the services seems to be mostly running in jail/VM which is favorable to be preserved for security reasons (e.g. in scenario where there is a major bug discovered in the wild to reduce the impact of one service on the system). So i am currently unsure whether we want to: 1. run one tor daemon per system in jail/VM to provide the routing from exposed ports from the services e.g. https://git.fsfe.org/kreyren/fsfe-planet/src/branch/onionz/docker-compose.ym... 2. implementing tor daemon within these jails/VMs with the service srv/service1 (exposing port 12447) srv/service2 (exposing port 12448) and setting tor as HiddenServiceDir /var/lib/tor/service1 HiddenServicePort 12447 127.0.0.1:12447 HiddenServiceDir /var/lib/tor/service2 HiddenServicePort 12447 127.0.0.1:12447 3. implementing tor daemon on the router assuming all services being routed through a routing server, but i am concerned about sanitization as if there is a bug in tor that could expose user traffic to bad actors. (currently being discussed) 4. Implementing xen (https://en.wikipedia.org/wiki/Xen) which currently not favorable as it would require lots of work on the backend. 5. Other? FWIW i would also like to provide something like https://onion.debian.org so that the website list is available to the end-user. -- - Krey
Hi Jacob, On 2021-01-22 12:21, Jacob Hrbek wrote:
Yes EOTK uses a TLS certificate. The idea behind this is that if the certificate belongs to fsfe, visitors of the onion service can be sure that the onion has been setup by fsfe. The certificate is not needed for any other reason than that. If you are concerned about how people discover your onion you can use the onion-location header so that people visting fsfe.org over tor get the onion available button on the url bar and can get redirected to the onion (https://community.torproject.org/onion-services/advanced/onion-location/).
EOTK is a tool that setup a few options for you in nginx and install required packages, but you can setup the onion also manually. Here for example you will find a gist of the nginx config of the propubblica onion: https://gist.github.com/mtigas/9a7425dfdacda15790b2
I am not sure about the exact architecture here, but generally you need a master onion where you run onion balance and use it to scale horizontally with different backends (https://onionbalance-v3.readthedocs.io/en/latest/v3/tutorial-v3.html). If you are concerned about DOS attacks you can also implement some more advanced web server configs. One of them is using captchas, another is to use cookies to filter out scripted clients. The idea in this case is that the web server sends the client a cookie and ask the client to verify it. Usually scripted clients don't set cookies so the verify fails and you find out that the client is malicious. Nginx uses openresty and lua to implement captchas. This solution is usually highly scripted. With regards to cookies I can recommend this library from cloudflare for openresty https://github.com/cloudflare/lua-resty-cookie. I am sure there are equivalent solution in apache.
There is a tool called onionscan (https://onionscan.org/) that can help you find vulnerabilities on your onion. This also test things like bugs in your web service that might expose users data and information that you might prefer to keep secure. I also assume that the fsfe onion isn't interested to be anonymous so you might consider setting up a 1-hop onion in this case (https://support.torproject.org/glossary/single-onion-service/). Let me know if you need more help. Cheers, -hiro
participants (3)
-
Jacob Hrbek -
Silvia -
Silvia/Hiro