Onion-routing is now officially deployed on fsfe.org with HTTP header onion-location pointing to http://fsfeorg3hsfyuhmdylxrqdvgsmjeoxuuug5a4dv3c3grkxzsl33d3xyd.onion
Peer-review is appreciated for code in https://git.fsfe.org/fsfe-system-hackers/onionproxy ^-^ On 1/27/21 9:57 PM, krey...@rixotstudio.cz wrote: > On 1/27/21 1:22 PM, Hiro/Silvia wrote: >> Hi Jacob, >> >> On 2021-01-26 20:14, Jacob Hrbek wrote: >>> On 1/23/21 8:59 PM, Silvia Puglisi, Ph.D. wrote: >>>> Hi Jacob, >>>> >>>> On 2021-01-22 12:21, Jacob Hrbek wrote: >>>>> 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? >>>> 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/). >>>> >>>>> More options and way >>>>> to configure EOTK (alec seems to be currently busy and unable to answer) >>>>> appreciated. >>>> 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 >>>> >>>>> 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.yml >>>>> 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 >>>>> >>>>> >>>> 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. >>>> >>>> >>>>> 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? >>>> 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 >>>>> FWIW i would also like to provide something like >>>>> https://onion.debian.org so that the website list is available to the >>>>> end-user. >>>>> >>>>> >>>>> _______________________________________________ >>>>> tor-onions mailing list >>>>> tor-onions@lists.torproject.org >>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions >>> I am sorry for delay had to process lots of informations. >>> >>> The onion-location HTTP header is already tracked. >>> >>> Added propublica configuration in tracking as example configuration, thanks! >>> >>> One-hop non-anonymous onion service noted in tracking. >>> >>> OnionScan noted in tracking and recommended to be adapted as Continuous >>> Integration. >>> >>> Personal tracking updated in >>> https://github.com/Kreyren/kreyren/issues/60 peer-review appreciated. >>> >>> About the (D)DoS -> i was told that they are not a concern over onion >>> routing due to the hard delay used for encryption. Can you confirm? >>> Overall the (D)DoS is part of a threat model as FSFE has been (D)DoSed >>> in the past where the main concern is Gitea as the static pages require >>> an unreasonable amount of resources to be taken down atm. >> So onion service DoS is a bit different than normal DoS, because the >> target in this case is the tor daemon. So while the website will still >> be reached on the normal internet in the case of onion service DoS it >> will be the onion that will not be reached. >> >> Check out this blog post to have a better idea: >> https://blog.torproject.org/stop-the-onion-denial >> >>> About Apache -> This is currently used by the webserver and needs to be >>> implemented with priority in >>> https://git.fsfe.org/fsfe-system-hackers/webserver-bunsen/src/branch/master/files/apache2-sites >>> (currently tracked in >>> https://git.fsfe.org/fsfe-system-hackers/webserver-bunsen/pulls/7). Any >>> relevant information to the implementation is appreciated as i am >>> currently struggling with making the TLS-over-onion work there where >>> apache should strip the TLS when the website is accessed over onions. >>> Any relevant information appreciated. >> I am not particularly familiar with the specific Apache syntax but why >> do you want to strip the TLS? >> Can't you just specify a different configuration for the onion in Apache >> where TLS is not used? Like a different VirtualHost that use port 80 for >> the onion? >> >>> About Nginx -> Currently not an option as the website is already using >>> Apache. >>> >>> About EOTK -> I would like to implement this as an alternative >>> configuration for system hackers to have a choice and do their research >>> more efficiently and I assume that being a better implementation here as >>> we currently want to onionize gitea service which based on my experience >>> on https://git.dotya.ml requires changing of non-relative links within >>> the webapp (which can be done in nginx/apache, but seems to be painful >>> to maintain?). >> What do you mean alternative configuration? >> >> We are also working on a library of scripts for different configuration >> systems. For example: >> https://gitlab.torproject.org/hiro/terraform-onions for terraform. >> >> >>> FWIW i am also considering decentralization for the static pages where >>> the theory is to reduce the system load, make the websites less >>> vulnerable to (D)DoS and make the websites to load faster as the >>> webserver would be closer to the client in question. I am not aware of >>> sane configuration for this over onions, but any relevant info appreciated. >>> >> Do you mean serving the static pages from different mirrors? >> I think in this case you might want to consider using a v3 onionbalance >> master onion and implement a few fronts and then add all their onion >> addresses to onionbalance's configuration and run it. If DoS over onion >> is a big concern for you I think running 2/3 fronts is a good idea. >> >> Let me know if this helps. >> >> Cheers, >> -hiro >> >>> _______________________________________________ >>> tor-onions mailing list >>> tor-onions@lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions >> _______________________________________________ >> tor-onions mailing list >> tor-onions@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions > How realistic is (D)DoS over onion on FSFE? Afaik onion-service (v3) > should have a mitigation for that? > > If the (D)DoS over onion on the tor daemon is a concern then: > 1. How to prevent Onion (D)DoS on static pages? > 2. How to handle (D)DoS on the Gitea instance? The Proof-of-work is > currently not an option as the access to that is granted only to the > supporters so i guess the concern would be git pulling? > 3. The login prompt on https://id.fsfe.org/authorization seems to be a > concern where captcha + rate limitation per IP seems a sufficient solution? > > > What do you mean alternative configuration? > > Afaik the system hackers are currently working on a solution using > apache where i understand that EOTK would be independent from apache as > a standalone solution? > > > https://gitlab.torproject.org/hiro/terraform-onions > > I don't have access to view that so waiting for an account atm > > About decentralization the proof-of-concept is > https://thedecentralizedweb.com/ (not necessary that this solution would > be used) where the current theory of implementation is allowing anyone > to provide a mirror of the website to join the decentralized stack so > that from the point of view of the user the website is the same without > any noticable changes, but reachable from multiple machines to do load > balancing and routing optimization. > > The current idea is using self-deployed DNS server that would do the > load balancing with some logic to verify that the served website has not > been altered from the main one where the onion-balance with few tweaks > might be a good solution for onion services, but i don't know how > painful it would be to implement it to allow painless integration of > mirrors atm. > > About apache i think i made it to work the way i want atm, will let you > know about the result as i do more research and based on the input from > system hackers (that are in charge of the implementation). > _______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions