Onion-routing for The Free Software Foundation Europe

[Kreyren]

On the web meet-up at 19/01/2021 18:00~21:00 CET the web team agreed 5/0 to support onion-routing for The Free Software Foundation Europe's websites.
The support is now being forwarded to the system hackers team that will take care of the implementation where this issue hopes to make the implementation easier for them.

The onion-routing is currently expected for the following websites:

• https://fsfe.org (https://git.fsfe.org/FSFE/fsfe-website)
  • https://git.fsfe.org (Gitea Instance)
  • https://test.fsfe.org
  • https://wiki.fsfe.org
  • https://community.fsfe.org
  • https://lists.fsfe.org
  • https://pdfreaders.org
  • https://freeyourandroid.org
  • https://ilovefs.org
  • https://drm.info
• https://publiccode.eu (https://git.fsfe.org/pmpc/website)
• https://status.fsfe.org/
• https://planet.fsfe.org/ (https://git.fsfe.org/fsfe-system-hackers/fsfe-planet)
• https://reuse.software/ (https://git.fsfe.org/reuse/website)

Note the maintenance overhead and efficiency of the implementation is a concern.

(D)DoS is a concern - The services are generally static websites to they can handle large (D)DoS attacks, but that doesn't apply to gitea that was taken down this way recently.

We want to provide both clearweb and onion services.

• Preferable with TLS-over-onion, but that is not needed.

The websites are using Let's Encrypt TLS certificate.

---

HTTP header onion-location

Tor Browser Bundle (TBB) will (depending on the user configuration) show a button

Or redirects automatically when the websites provides an onion service.

Configurable in TBB's about:preferences#privacy using:

Relevant: https://tb-manual.torproject.org/onion-services/

---

Load balancing (Help-wanted)

Current requirement by system hackers.

Onion-balance https://gitlab.torproject.org/asn/onionbalance?

---

FSFE webserver

This is the FSFE webserver used to serve the websites https://git.fsfe.org/fsfe-system-hackers/webserver-bunsen

---

1. Issue - Certificate

Since the clearweb is providing a certificate this is a concern for the onion service which currently seems to require a payment of 2000 USD/year for EV certificate on onion top-level domains.

NOTE: The clearweb version depends on encryption for security and privacy reasons.

Why do we need Extended Validation Certificate?

FIXME

Solution 1: EOTK wizardry? (alecmuffett/eotk#86)

(BEST) Solution 2: Reverse proxy such as apache, nginx, openbsd's relayd to strip the TLS?

This is assuming following configuration of the FSFE servers:

onion/http reverse proxy <-> https backend

Where the fsfe.org seems to be using Apache based on https://fsfe.org/contribute/web that should be painless to implement.

References:

1. https://www.jamieweb.net/blog/forwarding-tor-hidden-services-to-another-server-across-the-internet/

Solution 3: Same Origin Onion Certificate (SOOC) https://github.com/alecmuffett/onion-dv-certificate-proposal/blob/master/text/draft-muffett-same-origin-onion-certificates.basic.md

This solution is in works and not yet implemented.

Solution 4: Buy EV certificate for onion top-level domain

Not an option as it's not economical for non-profit organization (seems to cost 650~2000 USD/year?)

Relevant: letsencrypt/boulder#4620

<More options appreciated!>

2. Issue - Denial of Service over Onion

TBD

Reference: https://blog.torproject.org/stop-the-onion-denial

---

The importance of non-anonymous service

We want the onion-service accesible by public so it should be set as non-anonymous one-hop service, see https://support.torproject.org/glossary/single-onion-service/

Rationale to implement onion-routing

community/community#2843

Example configuration

Propublica: https://gist.github.com/mtigas/9a7425dfdacda15790b2 (nginx)

Sanity-checking

There is a tool called onionscan that will process the website to look for issues https://onionscan.org/

RECOMMENDATION: Implement as Quality Assurance

Relevants

1. Tutorial for OnionBalance https://onionbalance-v3.readthedocs.io/en/latest/v3/tutorial-v3.htm
2. Info on apache configuration https://www.jamieweb.net/blog/forwarding-tor-hidden-services-to-another-server-across-the-internet/

[NetworksAreMadeOfString]

+1 for alecmuffett's EOTK which (IIRC) can handle all the hairy rewrites where something is served from the .onion but has a href for the clearnet site etc.

I've had a quick look at the source of e.g. https://fsfe.org/ and the URLS look to be relative so you don't need to run TLS on the .onion as you can have you https clearnet site serve an onion-location header for a http onion and it should all work fine (so long as you configure your vhosts appropriately so they don't issue a HSTS or a redirect etc).

If your Tor daemon and httpd are not on the same host then this approach cannot be recommended without additional transport security between the nodes (e.g. assumptions made around secure cookies and the equivalence of HTTPS/.onion).

FWIW When I last purchased a .onion EV it was only about £250-£300 from Digicert (by way of the now defunct CertSimple) but this is still quite a chunk of cash.

How many webservers are involved in running the current websites? Can they run the Tor daemon locally?

[Kreyren]

+1 for alecmuffett's EOTK which (IIRC) can handle all the hairy rewrites where something is served from the .onion but has a href for the clearnet site etc. @NetworksAreMadeOfString

Can you eleborate on the implementation using EOTK? I was discussing the implementation with alec, but it seems that he's currently busy and unable to answer.

FWIW the websites seems to be explicitly using relative links so there shoudn't be any references to the domains with exception for the gitea instance https://git.fsfe.org that currently requires nginx changing the links in https://git.dotya.ml (where i was helping with implementation). Hoping for a more maintainable way to manage it here. O.o

If your Tor daemon and httpd are not on the same host then this approach cannot be recommended without additional transport security between the nodes (e.g. assumptions made around secure cookies and the equivalence of HTTPS/.onion). @NetworksAreMadeOfString

The websites are managed by team "System-Hackers" (https://git.fsfe.org/fsfe-system-hackers) who didn't made a decision on the implementation yet, but i understood that they want everything running in a jail (e.g. chroot) or in a VM.

So i think it's a sane to implement these in this spirit e.g. my current effort https://git.fsfe.org/kreyren/fsfe-planet/src/branch/onionz/docker-compose.yml.

FWIW When I last purchased a .onion EV it was only about £250-£300 from Digicert (by way of the now defunct CertSimple) but this is still quite a chunk of cash. @NetworksAreMadeOfString

Yep, but still it's not very economical for non-profit foundation and i want to keep the cost low ideally.

How many webservers are involved in running the current websites? Can they run the Tor daemon locally?

List of websites is provided in OP where it's a lot of services where system efficiency and security is a concern.

---

FWIW i've requested more information from system hackers they are expected to provide more info shortly.

[Kreyren]

Effort to implement this in the webserver tracked in https://git.fsfe.org/fsfe-system-hackers/webserver-bunsen/pulls/7, currently waiting for decision from system hackers.

[Kreyren]

Proposals to adapt apache server in bunsen to provide an onion service by stripping TLS over onions appreciated.

Came up with http://ix.io/2MY9 so far, but i lack the research atm.

[Kreyren]

if you want a non-anonymous onion, you need 'SocksPort 0' too to turn the SocksPort off -- Anonymous

[Kreyren]

Implemented