[tor-onions] Onion-routing of The Free Software Foundation Europe

[Jacob Hrbek]

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, kreyren at 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 at 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 at lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
>> _______________________________________________
>> tor-onions mailing list
>> tor-onions at 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).
>