onion site wanted #50

Please setup an onion site so Tor users can avoid the exit node bottleneck. Notice that Notabug has done this.

interesting idea. Any contributors?

It can't be done from user side. Only the server owner can.

https://2019.www.torproject.org/docs/tor-onion-service.html.en#zero

Only a few git services support Tor. If you support it, that'll be really cool!

(I'm Tor contributor and relay owner.)

e.g.

apt install tor
mkdir /hidden/codeberg_tor/
nano /etc/tor/torrc

HiddenServiceDir /hidden/codeberg_tor/
HiddenServicePort 443 127.0.0.1:443

https://(your onion).onion/ == https://codeberg.org/

@not_cloudflare
Would that require us to become an "exit node"?
Or just an endpoint for traffic to codeberg.org?

A quick research says that we do not have to become an exit node, so personally I am open to the idea.

Hosting onion service is easy. You have to install Tor[1] and edit "torrc" file. Even Facebook, New York Times, and CIA have onions.

You don't have to become a relay(middle node, exit node).

Here's a list of WeSupportTor. If codeberg become accessible over Tor, I will use it & add you to the list.

https://trac.torproject.org/projects/tor/wiki/org/projects/WeSupportTor

http://onion is safe because onion connection is encrypted.
https://onion is more safe, but unnecessary.
You can assign any subdomains, such as http://codeberg.generatedonionname.onion/
v3 onionname(long onion name) is secure than v2(short onion name).

[1] https://2019.www.torproject.org/docs/debian.html.en#ubuntu

@not_cloudflare: Would you like to contribute an example of the config as PR, for example against the etc/ template folder in https://codeberg.org/Codeberg/build-deploy-gitea/src/branch/master/etc/?

(these files are directly deployed into /etc/, after templates for ${HOSTNAME_FQDN} etc have been resolved)

Tor is a server, not gitea.
(below should work for debian system)

e.g.

---request---> server [{Codeberg Tor} <===localhost===> {Codeberg WWW server}]

---request---> Tor(redirect to 127.0.0.1:80) ======> WWW(listen 127.0.0.1:80)

easy guide: https://www.reddit.com/r/TOR/comments/8tyrye/how_to_create_onion_website_on_web_server_which/

TLDR Example:

0. Create a directory for private key (mkdir /var/dontshareme/codebergonion/)

1. "apt install tor"  <--- https://2019.www.torproject.org/docs/debian.html.en

2. "nano /etc/tor/torrc"

3. Add 3 lines:

HiddenServiceDir /var/dontshareme/codebergonion/
HiddenServicePort 80 127.0.0.1:80
HiddenServiceVersion 3

4. "service tor restart"

Tor will connect to the network and generate your .onion hostname(domain).
Don't upload /var/dontshareme/codebergonion/ contents
because these are private keys!

5. You'll find your .onion in /var/dontshareme/codebergonion/.

6. Open http://(your onion).onion/ on Tor Browser and enjoy!

Here's my test server's torrc (I've hidden some lines but it will be useful):

And manual. https://2019.www.torproject.org/docs/tor-manual.html.en

Log err /dev/null

AvoidDiskWrites 1
CookieAuthentication 1

DataDirectory ????????????
GeoIPFile ????????????
GeoIPv6File ????????????

DirReqStatistics 0
ExtraInfoStatistics 0
HiddenServiceStatistics 0

ExcludeNodes default,CIA,NSA,{us}

ReachableAddresses *:443
ReachableAddresses reject *:*

HiddenServiceDir ????????????
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 465 unix:/var/lib/mailer2/usocket.sox
HiddenServiceVersion 3

Plain vanilla debian, no 3rdparty apt sources. All local services are routed through haproxy (we want to publish the infrastructure deployment files too, but didn't have the time for a thourough review yet).

Is this still relevant after (partially?) blocking Tor due to abuse?

@hunger

We are current not blocking tor in any way. And we never did. Not one single second.

@ashimokawa: I read something about abusive account creation via tor and at least some discussion to block it and must have over-interpreted this.

Sorry for that.

I’m interested in providing Codeberg as onion site. I do have experience running various parts of the TOR network so I’m able to help.

nice! What would be needed from our side?

Some kind of access to the infrastructure code. Esspecially important the /etc dir (of the server not of Gitea like pointed out here #50) in such a way that I can open a PR or something similar.
I also need read access to enough infrastructure code so I can setup a test system to ensure the resulting configuration will actually work.

Running tor on main server is a no-go for obvious reasons. Dedicated VM forwarding port 80/443 might be an option?

You could for example use createVM.sh in https://codeberg.org/Codeberg/build-deploy-gitea as starting point, happy to help if needed.

youre right its probably better not to have TOR on the main machine.
The VM pointer helps I`ll probably start some time next week.

@hw @ashimokawa https://blog.torproject.org/more-onions-porfavor

Running tor on main server is a no-go for obvious reasons.

I think there may be a misunderstanding here. What's the problem with running Tor on the main server?

It can’t be done from user side. Only the server owner can. #50

Just to clarify: Can be done by a user, but owner provided onion link is prefered for obvious reasons and to avoid limitation like having only read access.

Would that require us to become an “exit node”? #50

Not required for a hidden service afaik

http://onion is safe because onion connection is encrypted.
https://onion is more safe, but unnecessary. #50

Just to clarify:

http://<random-things-here>.onion is safe as Tor is encrypting everything it can

http://clearweb-website.com is not safe as the trafic from the exit node is exposed to the exit node provider and to the clearweb

https://clearweb-website.com is generally considered not unsafe, but can be used for a fingerprinting and tracking for websites that doesn't have a lot of Tor users (The idea of torbrowser is to have a huge crowd of people with the same browser as a counter-measure to fingerprinting).

We are current not blocking tor in any way. And we never did. Not one single second. #50

That is not secure enough for tor users as we have to depend on an exit node to connect to the clearweb to reach this website, but generally acceptable.

Now to demistify the setup

Basically you download and install tor and add following lines:

############### This section is just for location-hidden services ###

## Once you have configured a hidden service, you can look at the
## contents of the file ".../hidden_service/hostname" for the address
## to tell people.
##
## HiddenServicePort x y:z says to redirect requests on port x to the
## address y:z.

#HiddenServiceDir /var/lib/tor/hidden_service/
#HiddenServicePort 80 127.0.0.1:80

#HiddenServiceDir /var/lib/tor/other_hidden_service/
#HiddenServicePort 80 127.0.0.1:80
#HiddenServicePort 22 127.0.0.1:22

In codeberg's case that would be:

HiddenServiceDir /var/lib/tor/codeberg
HiddenServicePort <gitea_port> 127.0.0.1:<gitea_port>

which should be all that is needed for tor users to access the website from tor.

Your onion url will be then stored in /var/lib/tor/codeberg/hostname

Recommending doing a peer-review in irc.oftc.net/#tor for official support.

Referencing my configuration: https://github.com/RiXotStudio/server-setup/blob/master/src/sefunc/00-tor.sh

> It can’t be done from user side. Only the server owner can. https://codeberg.org/Codeberg/Community/issues/50#issuecomment-4136 Just to clarify: Can be done by a user, but owner provided onion link is prefered for obvious reasons and to avoid limitation like having only read access. > Would that require us to become an “exit node”? https://codeberg.org/Codeberg/Community/issues/50#issuecomment-4140 Not required for a hidden service afaik > http://onion is safe because onion connection is encrypted. > https://onion is more safe, but unnecessary. https://codeberg.org/Codeberg/Community/issues/50#issuecomment-4144 Just to clarify: `http://<random-things-here>.onion` is safe as Tor is encrypting everything it can `http://clearweb-website.com` is not safe as the trafic from the exit node is exposed to the exit node provider and to the clearweb `https://clearweb-website.com` is generally considered not unsafe, but can be used for a fingerprinting and tracking for websites that doesn't have a lot of Tor users (The idea of torbrowser is to have a huge crowd of people with the same browser as a counter-measure to fingerprinting). > We are current not blocking tor in any way. And we never did. Not one single second. https://codeberg.org/Codeberg/Community/issues/50#issuecomment-49785 That is not secure enough for tor users as we have to depend on an exit node to connect to the clearweb to reach this website, but generally acceptable. --- Now to demistify the setup Basically you download and install tor and add following lines: ```conf ############### This section is just for location-hidden services ### ## Once you have configured a hidden service, you can look at the ## contents of the file ".../hidden_service/hostname" for the address ## to tell people. ## ## HiddenServicePort x y:z says to redirect requests on port x to the ## address y:z. #HiddenServiceDir /var/lib/tor/hidden_service/ #HiddenServicePort 80 127.0.0.1:80 #HiddenServiceDir /var/lib/tor/other_hidden_service/ #HiddenServicePort 80 127.0.0.1:80 #HiddenServicePort 22 127.0.0.1:22 ``` In codeberg's case that would be: ``` HiddenServiceDir /var/lib/tor/codeberg HiddenServicePort <gitea_port> 127.0.0.1:<gitea_port> ``` which should be all that is needed for tor users to access the website from tor. Your onion url will be then stored in `/var/lib/tor/codeberg/hostname` --- Recommending doing a peer-review in irc.oftc.net/#tor for official support. Referencing my configuration: https://github.com/RiXotStudio/server-setup/blob/master/src/sefunc/00-tor.sh

Running tor on main server is a no-go for obvious reasons. Dedicated VM forwarding port 80/443 might be an option? @hw

Elaborate on obvious reasons?

Running tor on main server is a no-go for obvious reasons. Dedicated VM forwarding port 80/443 might be an option? @hw

Elaborate on obvious reasons?

All attacks on Codeberg came via Tor in the past. Any DDOS/attack on this channel would harm the entire platform if running in the same machine.

To clarify once again: if one or more contributors volunteer to sponsor/setup/run the required infrastructure, we will happily endorse this. It is just that nobody raised his hand yet to commit.

EDIT: Upon peer-review the rate limits might be only for relays will update once clarified
EDIT2: BandwidthRate is used for this, adapted

All attacks on Codeberg came via Tor in the past. Any DDOS/attack on this channel would harm the entire platform if running in the same machine.

@hw I believe that you are misinformed about the subject, there were lot of DDoS attacks in 2019 due to the bug discovered in Tor itself[1] which has been allegedly fixed so these attacks should be drastically reduced by now as they are much more difficult and much more resource intensive to perform.

As said in general performing DDoS/DoS from Tor to a hidden service and/or clearweb is more resource intensive compared to just using clearweb as Tor has to encrypt the traffic multiple times and route it through three relays so theoretically to perform a successful DDoS/DoS from Tor you would need to set up multiple tor clients sandboxed with cherrypicked ExcludeNodes i.e using curl https://onionoo.torproject.org/details 2>/dev/null | jq -r '.relays[] | select(.observed_bandwidth <= 1310720) | .or_addresses' | grep -oP "^\s+\"(\w+\.\w+\.\w+\.\w+\:\w+)" | sed "s/^ \"//gm" | tr '\n' ',' (Tool from https://github.com/Krey-s-Tor/torrc/blob/master/src/ExcludeSlowRelays.conf) to exclude slow tor relays that would be limiting the Tor DDoS/DoS then set up a loop that runs something alike pidof tor | xargs sudo kill -HUP to generate a new routes which based on my unreliable and questionable experiment (so the experiment should be verified) would take 100mbps upload into 8mbps attack in which case it's much more efficient to perform the attack from a clearweb not to mension that such changes to the Tor are going to make the attacker fingerprintable and sacrifice anonymity.

But if you are still concerned about Tor halting your system then you can rate limit it by using:

# Bandwidth limiters
BandwidthRate 125 KB # Throttle traffic to 125KB/s 1000Kbps)

So even if attacker takes down Tor (very unlikely) you can still have working system and if that it not enough to you then the application itself should be optimized on DDoS/DoS i.e the registration which torproject suggest[1] to make proof-of-work which is for example implemented on Hackint.org[4].

And if that is still not enough to you i would recommend Linux kernel with MuQSS scheduler from weebo dentist CK which shown[5][6] to be much more difficult to made halt and to be more efficient in handling the load on systems with more then 4 threads at the cost of generating more heat (optimizable) and requiring more electricity compared to Complitely Fair Scheduler (CFS). Based on my experience MuQSS is more economical in commercial application as it allows the system the have a reliable scheduler as CFS likes to halt and get confused too much.

I've also linked an utility to test the system agains tor DDoS/DoS[3]

References

EDIT: Upon peer-review the rate limits might be only for relays will update once clarified EDIT2: `BandwidthRate` is used for this, adapted > All attacks on Codeberg came via Tor in the past. Any DDOS/attack on this channel would harm the entire platform if running in the same machine. @hw I believe that you are misinformed about the subject, there were lot of DDoS attacks in 2019 due to the bug discovered in Tor itself[1] which has been allegedly fixed so these attacks should be drastically reduced by now as they are much more difficult and much more resource intensive to perform. As said in general performing DDoS/DoS from Tor to a hidden service and/or clearweb is more resource intensive compared to just using clearweb as Tor has to encrypt the traffic multiple times and route it through three relays so theoretically to perform a successful DDoS/DoS from Tor you would need to set up multiple tor clients sandboxed with cherrypicked `ExcludeNodes` i.e using `curl https://onionoo.torproject.org/details 2>/dev/null | jq -r '.relays[] | select(.observed_bandwidth <= 1310720) | .or_addresses' | grep -oP "^\s+\"(\w+\.\w+\.\w+\.\w+\:\w+)" | sed "s/^ \"//gm" | tr '\n' ','` (Tool from https://github.com/Krey-s-Tor/torrc/blob/master/src/ExcludeSlowRelays.conf) to exclude slow tor relays that would be limiting the Tor DDoS/DoS then set up a loop that runs something alike `pidof tor | xargs sudo kill -HUP ` to generate a new routes which based on my unreliable and questionable experiment (so the experiment should be verified) would take 100mbps upload into 8mbps attack in which case it's much more efficient to perform the attack from a clearweb not to mension that such changes to the Tor are going to make the attacker fingerprintable and sacrifice anonymity. But if you are still concerned about Tor halting your system then you can rate limit it by using: ``` # Bandwidth limiters BandwidthRate 125 KB # Throttle traffic to 125KB/s 1000Kbps) ``` So even if attacker takes down Tor (very unlikely) you can still have working system and if that it not enough to you then the application itself should be optimized on DDoS/DoS i.e the registration which torproject suggest[1] to make proof-of-work which is for example implemented on Hackint.org[4]. And if that is still not enough to you i would recommend Linux kernel with MuQSS scheduler from weebo dentist CK which shown[5][6] to be much more difficult to made halt and to be more efficient in handling the load on systems with more then 4 threads at the cost of generating more heat (optimizable) and requiring more electricity compared to Complitely Fair Scheduler (CFS). Based on my experience MuQSS is more economical in commercial application as it allows the system the have a reliable scheduler as CFS likes to halt and get confused too much. I've also linked an utility to test the system agains tor DDoS/DoS[3] ### References 1. Bug in tor allowing DDoS https://trac.torproject.org/projects/tor/ticket/29607 2. Referenced from torproject to handle DDoS on hidden services https://blog.torproject.org/stop-the-onion-denial 3. Tool used to perform the DDoS attack through Tor https://github.com/r3nt0n/torDDoS 4. Proof-of-work is for example utilized on hackint.org https://www.hackint.org/transport/tor 5. Reference to liquorix kernel https://liquorix.net/ 6. Benchmark of CFS vs MUQSS https://openbenchmarking.org/result/2005044-NI-SMALLPT1752&hgv=kernel+5.3.14%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss&rmm=kernel+5.3.14%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss&hnr=1&hni=1&swl=1&rmm=smallpt1%2Csmallpt4%2Ctest%2Ctest2%2Ctest3%2Ctest4%2C5%2C6%2C7%2C8%2Ctest9%2C10%2CPrecision+Boost+Overdrive%2CPBO+5.5-tkg%2Cpbo3%2CGamemode%2Casync%2Cmodesetting+attempt%2Cschedutil%2C4.0GHz%2Cfsync+kernel%2CArch+Linux%2CManjaro-TKG-5.5-PDS%2CArch+with+fsync+kernel+5.4.3%2CArchLinuxZenPBO%2CNew+paste%2Czenstates+oc%2CLower+PBO%2CArch+5.4.8%2C4G%2C4075%2Cnoacpi-pbo%2CDeepcool%2Cnoacpi-5.6%2C5.6-tkg-pds-acpi%2C5.6-tkg-acpi-nmon%2C4100-5.6%2C5.6-tkg-acpi-pbo%2C4150%2Cbmq%2Cbmq2%2CArcoLinux%2CArcoLinux+4100%2CarcoPBO%2CNew+arco%2CArco4100%2Carco4075%2C3600x+pbo1%2C3600X+PBO+2+3200MHz+RAM%2C3600X+X570+Taichi%2C3600X+Zenstates%2C4250+OC%2C3600X+%40+4250MHz&hgv=kernel+5.3.14%2CRyzen+2600X%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss%2C5.6%2Cfancontrol%2CVanilla+Manjaro+5.6-rc2&ftt=muqss&ftb=5.6&hnr=1&hni=1&sgm=1&swl=1&sdt=1&rmm=smallpt1%2Csmallpt4%2Ctest%2Ctest2%2Ctest3%2Ctest4%2C5%2C6%2C7%2C8%2Ctest9%2C10%2CPrecision+Boost+Overdrive%2CPBO+5.5-tkg%2Cpbo3%2CGamemode%2Casync%2Cmodesetting+attempt%2Cschedutil%2C4.0GHz%2Cfsync+kernel%2CArch+Linux%2CManjaro-TKG-5.5-PDS%2CArch+with+fsync+kernel+5.4.3%2CArchLinuxZenPBO%2CNew+paste%2Czenstates+oc%2CLower+PBO%2CArch+5.4.8%2C4G%2C4075%2Cnoacpi-pbo%2CDeepcool%2Cnoacpi-5.6%2C5.6-tkg-pds-acpi%2C5.6-tkg-acpi-nmon%2C4100-5.6%2C5.6-tkg-acpi-pbo%2C4150%2Cbmq%2Cbmq2%2CArcoLinux%2CArcoLinux+4100%2CarcoPBO%2CNew+arco%2CArco4100%2Carco4075%2C3600x+pbo1%2C3600X+PBO+2+3200MHz+RAM%2C3600X+X570+Taichi%2C3600X+Zenstates%2C4250+OC%2C3600X+%40+4250MHz&hgv=kernel+5.3.14%2CRyzen+2600X%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss%2C5.6%2Cfancontrol%2CVanilla+Manjaro+5.6-rc2&ftt=muqss&ftb=5.6&hnr=1&hni=1&sgm=1&swl=1&sdt=1&rmm=smallpt1%2Csmallpt4%2Ctest%2Ctest2%2Ctest3%2Ctest4%2C5%2C6%2C7%2C8%2Ctest9%2C10%2CPrecision+Boost+Overdrive%2CPBO+5.5-tkg%2Cpbo3%2CGamemode%2Casync%2Cmodesetting+attempt%2Cschedutil%2C4.0GHz%2Cfsync+kernel%2CArch+Linux%2CManjaro-TKG-5.5-PDS%2CArch+with+fsync+kernel+5.4.3%2CArchLinuxZenPBO%2CNew+paste%2Czenstates+oc%2CLower+PBO%2CArch+5.4.8%2C4G%2C4075%2Cnoacpi-pbo%2CDeepcool%2Cnoacpi-5.6%2C5.6-tkg-pds-acpi%2C5.6-tkg-acpi-nmon%2C4100-5.6%2C5.6-tkg-acpi-pbo%2C4150%2Cbmq%2Cbmq2%2CArcoLinux%2CArcoLinux+4100%2CarcoPBO%2CNew+arco%2CArco4100%2Carco4075%2C3600x+pbo1%2C3600X+PBO+2+3200MHz+RAM%2C3600X+X570+Taichi%2C3600X+Zenstates%2C4250+OC%2C3600X+%40+4250MHz&hgv=kernel+5.3.14%2CRyzen+2600X%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss%2C5.6%2Cfancontrol%2CVanilla+Manjaro+5.6-rc2&ftt=muqss&ftb=Arch+5.4.8&hnr=1&hni=1&scalar=1&sdt=1&rmm=smallpt1%2Csmallpt4%2Ctest%2Ctest2%2Ctest3%2Ctest4%2C5%2C6%2C7%2C8%2Ctest9%2C10%2CPrecision+Boost+Overdrive%2CPBO+5.5-tkg%2Cpbo3%2CGamemode%2Casync%2Cmodesetting+attempt%2Cschedutil%2C4.0GHz%2Cfsync+kernel%2CArch+Linux%2CManjaro-TKG-5.5-PDS%2CArch+with+fsync+kernel+5.4.3%2CArchLinuxZenPBO%2CNew+paste%2Czenstates+oc%2CLower+PBO%2CArch+5.4.8%2C4G%2C4075%2Cnoacpi-pbo%2CDeepcool%2Cnoacpi-5.6%2C5.6-tkg-pds-acpi%2C5.6-tkg-acpi-nmon%2C4100-5.6%2C4150%2Cbmq%2Cbmq2%2CArcoLinux%2CArcoLinux+4100%2CarcoPBO%2CNew+arco%2CArco4100%2Carco4075%2C3600x+pbo1%2C3600X+PBO+2+3200MHz+RAM%2C3600X+X570+Taichi%2C3600X+Zenstates%2C4250+OC%2C3600X+%40+4250MHz&hgv=kernel+5.3.14%2CRyzen+2600X%2C5.5-tkg%2C5.5-rc%2CArch+5.5-tkg%2Cmuqss%2C5.6%2Cfancontrol%2C5.6-tkg-acpi-pbo%2CVanilla+Manjaro+5.6-rc2&ftt=muqss&ftb=5.6

To clarify once again: if one or more contributors volunteer to sponsor/setup/run the required infrastructure, we will happily endorse this. It is just that nobody raised his hand yet to commit.

^^^^^^^^^^^^^^^^^^^^^^^^ once again: this. ^^^^^^^^^^^^^^^^^^^^^^^^^^

Right now it's just extra burden of an additional project nobody had the time to pick up yet: as soon a volunteer Codeberg e.V. member steps up and takes responsibility for set-up and maintenance of a properly isolated VM running the onion protocol translation, we can do this :)

Like i am willing to fork https://github.com/rixotstudio/server-setup (namely https://github.com/RiXotStudio/server-setup/blob/master/src/sefunc/00-tor.sh) set up for codeberg's usage if wanted (this would be set as an isolated busybox instance), but making Tor in VM makes no sense to me for reasons provided.

Please justify usage of VM and check if proposed solution is sufficient for codeberg.

@kreyren

Putting this inside a VM would allow us to hand over the administration task to someone else without giving access to the main server.

@ashimokawa Why though? Tor doesn't require babysitting if you are not a relay operator (which you should if you have a spare bandwith where the relay administration is also maintainance friendly).

Basically just configuring it once and letting the system package manager to keep it up to date is enough in my mind.

I would think that keeping it inside a VM container and outsourcing it is a really bad idea in terms of privacy as then tor would have to rely on the security of the VM container and it's configuration and would probably expose the traffic to the container maintainer which is generally unwanted as the service should be always maintained by the upstream and as it's a VM container it requires much more processing power.

Relevant: https://github.com/go-gitea/gitea/issues/12876

@ashimokawa Why though? Tor doesn't require babysitting if you are not a relay operator

Basically just configuring it once and letting the system package manager to keep it up to date is enough

As someone who takes interest in onion services and in particular has seen Debian's smooth rollout of them, I must affirm @kreyren's point that running an onion service is primarily one-time setup and I suspect that there's misunderstanding, or conflation with the concept of Tor relays.

Because onion sites don't use TLS, there'd be no way to distinguish a phishing Codeberg onion service from the genuine one if it were not operated by the same entity. In fact you'd be letting an outside party have your secret key to the .onion pseudo-domain name.

The overhead of the Tor daemon is much lesser than any web server, because as the hidden service operator you're only the last hop. I believe the Tor daemon can even use Unix sockets to connect to supporting services, but that might've been a dream.

Lastly, onion-ifying Codeberg may go beyond the website. Take things one step at a time, but SSH over Tor would be appreciated as well. (Since onions are encrypted end-to-end, telnet would actually be safe enough.)

Edit: Here are a couple brief primary sources. Here's the complete instructions to start a service, and here's a post about the Tor Project's #MoreOnionsPorFavor campaign. This explicitly called for users to contact their favorite websites and explains the rationale of providing more privacy-preserving and secure options.

Your questions would also be very welcome on the tor-onions list.

Take things one step at a time, but SSH over Tor would be appreciated as well. (Since onions are encrypted end-to-end, telnet would actually be safe enough.)

Can recommend SSH over tor as well i use it daily and it's great ^-^

Note that there is a delay on SSH over tor (in general tor adds delay of around 120ms) for which you might need to adapt your client if you are using it interactively and i woudn't recommend it for things that need fast responsivness i.e using emacs this way, but it can also be made work on bases of emulating the terminal locally and then sending the commands to the remote.

Would be great for SSH clonning and submitting merges though! and very welcomed!

I could also recommend it for the mailserver as on clearweb there is an issue with people sniffing the traffic to know where you are sending the e-mails and to whom which is generally unwanted in commercial use for business reasons and commonly abused for targeted advertising.

@kreyren report tor gateway integration upstream ... wont help anyone

this has to be configured by instance admins/maintainers ...

yes, not part of gitea

@kreyren report tor gateway integration upstream ... wont help anyone @6543

Disagree as the concern was mainly about (D)DoS which Gitea is seemingly vulnerable to atm for example nothing prevents bad actors:

from setting up a browser macro to create X amount of accounts at the same time and denying the registration process
in uploading X amount of GB per second and overwhelming the server which would deny: closing, merge requests, resolving of merge requests and other git related functions
from creating X amount of repositories per second which would deny probably the main server
spamming the issues which would probably deny the server's ability to submit messages in tickets
Etc..

See https://github.com/go-gitea/gitea/issues/12876 where upstream just panics irationally about the subject of (D)DoS and does it's best to close the issue as fast as possible..

this has to be configured by instance admins/maintainers ... @6543

Agree, but @hw mentioned a concern about (D)DoS (which is unlikely and not realistic to be performed through Tor after a bug that allowed the execution efficiently has been fixed) so i am trying to provide the required information to make Gitea less susceptible to it.

[...] (D)DoS which Gitea is seemingly vulnerable [...]

(D)DOS protection currently handled in haproxy and fail2ban

Note: The (D)DoS tests performed locally using sandboxing and limiting available system resources to Gitea sandbox which might not represent the same behavior in the wild.

nothing prevents bad actors [...]

Yes, there will always be good folks and bad guys. We need to find a good balance so that the latter cannot harm the former, without restricting general use. In the past this worked very well. Let's do the best to keep it like this for the future!

@kreyren just panics irationally ...

I would not say that, the issue tracker is just not subject to broad conversations
https://discourse.gitea.io/ is the platform you are looking for

@hw Fail2ban can be avoided using a dynamically allocated IP adress from the ISP (some people are their own ISP so this is really easy for them to change) or using proxies or Tor.

haproxy can be allegedly overwhelmed as well depending on the amount of proxy servers (and their state) that do the load balancing.

In my mind the best defense agains (D)DoS is to adapting the software to sanitize the tasks that can be abused for the (D)DoS.

For example: if someone tries to create more then X accounts per minute then set a timeout for that region and process only 100 registration request per Z amount of time. So that end-users trying to make an account would be waiting in line for the server to process their registration request which seemed to work well in the wild.

I am sure every sound contribution to gitea the improves application-level service robustness will be highly welcome, both at codeberg and gitea!

About fail2ban there are apparently a paid services that provide a user-friendly environment to change the IP adresses within miliseconds so if codeberg is high value target do bad actors this would be an option for them.

:) we can always think of worse scenarios ... just if we focus exclusively on what-could-be instead of what-is we will get nothing done ;)

Again: a properly done PR solving actual issues is always welcome!

I am sure every sound contribution to gitea the improves application-level service robustness will be highly welcome, both at codeberg and gitea! @hw

Disagree that gitea upstream wants them for reasons provided, would be willing to make tracking in Codeberg/gitea to handle these concerns, but i would process them with low priority as these are currently not that important to be implemented and codeberg doesn't seem to be a target for bad actors. If that's fine with you? ^-^

Ideally would like to focus on implementing Tor for now.

I would not say that, the issue tracker is just not subject to broad conversations
https://discourse.gitea.io/ is the platform you are looking for @6543

Noted, should be probably adjusted in github template for issues and contributing file then as there is currently no way of knowing the development process in gitea as a new contributor..

Also it's kinda insane to resolve these in a forum as the merge requests should have tracking to the issue where the feature was discussed for reference if needed and the forum doesn't seem to be a good place to resolve code quality issues.

But IMHO upstream that bans the contributors without reasoning is not worth my time investing so i would still prefer to put these in Codeberg/Gitea for you to handle the upstream.

just if we focus exclusively on what-could-be instead of what-is we will get nothing done ;) @hw

So what is preventing you from deploying tor based on informations provided in #50 ? :p

So what is preventing you from deploying tor based on informations provided in #50 ? :p

extra setup+maintenance effort someone has to volunteer for

I volunteer

#!/bin/sh
# shellcheck shell=sh # Written to be POSIX-compatible

# Quick-script created by Jacob Hrbek <kreyren@rixotstudio,cz> under GPLv3 license <https://www.gnu.org/licenses/gpl-3.0.en.html> in 18/09/2020-EU 09:01:31 CEST

set -e

die() { printf '%s\n' "$2"; exit "$1" ;}

# Root check
[ "$(id -u)" = 0 ] || die 3 "Insufficient permisson, reinvoke as root"

# Check if we have uname to identify the kernel
command -v uname 1>/dev/null || die 1 "Command 'uname' is not available"

# Define kernel in KERNEL variable
KERNEL="$(uname -s)"

# Define distribution in DISTRO variable
if [ -f /etc/os-release ]; then
	DISTRO="$(cat /etc/os-release | grep "^ID=.*" | sed "s/ID\=//")"
	[ -n "$DISTRO" ] || die 1 "Unable to determine the distribution used"
elif [ ! -f /etc/os-release ]; then
	die 1 "Standard file '/etc/os-release' is not available"
else
	die 255 "os-release unexpected"
fi

# Get The Onion Router!
case "$KERNEL/$DISTRO" in
	"linux/debian" | "linux/ubuntu" | "linux/devuan")
		apt-get update || true
		apt-get install tor || exit 1
	;;
	"linux/fedora" | "linux/RHEL")
		dnf install tor || exit 1
	;;
	"linux/gentoo")
		emerge --sync
		emerge net-vpn/tor
	;;
	*) die 26 "Unimplemented combination of kernel '$KERNEL' and distribution '$DISTRO'"
esac

# Configure the tor for codeberg
case "$KERNEL/$DISTRO" in
	"linux/*")
		cat <<-EOF > /etc/tor/torrc
			# Provide Codeberg as hidden service
			HiddenServiceDir /var/lib/tor/codeberg/
			HiddenServicePort 3000 127.0.0.1:3000
		EOF
	;;
	*) die 26 "Unimplemented combination of kernel '$KERNEL' and distribution '$DISTO' to find torrc"
esac

it's not a one-time effort (monitor, adjust throttling if necessary, fight spammers through the channel etc)

Concluded throttling not neccesary atm, can be adjusted using BandwidthRate as mentioned in #50.

How do you want to handle the monitoring?

How do you want to fight spammers?

EDIT: Added reference on BandwidthRate

I don't think I'm understanding why an onion service would increase the risk of DoS or abuse. If an attacker wanted to do that over Tor, couldn't they connect over the clearnet (codeberg.org) anyway? An onion service would actually improve on this, since it would add three additional hops.

☝️

I don’t think I’m understanding why an onion service would increase the risk of DoS or abuse... @jscott

Note that explained in: #50

TLDR: i doubt that Tor used for (D)DoS is a viable option for clearweb nor onions as it needs way more processing power to perform the task.

FWIW i've helped to set up hidden service for https://git.dotya.ml currently available on http://2crftbzxbcoqolvzreaaeyrod5qwycayef55gxgzgfcpqlaxrnh3kkqd.onion

There are some issues with gitea configuration atm (gitea not replacing clearnet link with hidden) and droneCI (DroneCI blocking hidden as second provider but that seems to be pebcak), but seems to work quite well.

If codeberg is going to have onion address, please make sure it is a v3 onion addresses, v2 onion addresses are getting deprecated next years and i associate them with honeypots

Any news on this?

I don't think I'm understanding why an onion service would increase the risk of DoS or abuse. If an attacker wanted to do that over Tor, couldn't they connect over the clearnet (codeberg.org) anyway? An onion service would actually improve on this, since it would add three additional hops.

It's a shift of risk. A clearnet site is vulnerable to a small number of Tor exit nodes (insignificant) and the whole clearnet (significant, but attacker has to be a little more sophisticated to have a botnet). An onion site is immune to clearnet attack, but the attack surface is exposed to all Tor relays not just exit nodes.

IMO it makes sense to have both a clearnet site and an onion site. An attack can be engineered to hit either, but taking both down would take more motivation. So in principle it's overall more robust to have both.

FWIW i recently contributed to setting up an onion routing for the Free Software Foundation Europe, this might help you in deployment of the onion-services here https://github.com/Kreyren/kreyren/issues/60 which is peer-reviewed by The Tor Project.

FWIW outsourcing the onion-router in VM for maintenance by 3rd party is still foolish and insanity imho.

Sounds interesting.

Is spam via Tor still considered an issue? How are the chances that this might increase when providing easier access via the onion routing? If this is minimal, I think there are high chances to see an onion site soon.

Is spam via Tor still considered an issue? @fnetX

Depends on what kind of spam:

(D)DoS -> afaik practically and theoretically not possible due to the onion-induced delay of 100~350ms
Spam on issues -> Always a threat even over clearweb.

How are changes this might increase when providing easier access via the onion routing? @fnetX

I don't understand this question

If this is minimal, I think there are high chances to see an onion site soon. @fnetX

Based on informations provided it is minimal and the implementation was proposed in https://codeberg.org/Codeberg/build-deploy-gitea/pulls/44

I don't understand this question

Sorry, reworded for clarification: I just wanted to have some evaluation if there's a chance that spam will become significantly more common or harder to tackle or anything when providing a .onion site.

Sorry, reworded for clarification: I just wanted to have some evaluation if there's a chance that spam will become significantly more common or harder to tackle or anything when providing a .onion site.

I think the situation is exact the same as with clear net, the only difference is, you wont get the IP of an User, but this a user can avoid today too (just use tor with exit nodes ...)

the only difference is, you wont get the IP of an User @6543

To clarify you will get IP of a user, but it's more difficult to track where the user is (as the traffic is encrypted multiple times and routed through 3 relays each being in a different part of the world) and the end-user can change the IP on demand + the enhanced security.

I've made a proposal to GitHub about onion-routing that explains this in detail which was peer-reviewed by The Tor Project https://github.com/github/feedback/discussions/2843

Note that users who use onion-routing over either Tor or LOKI/OXEN can already access the website, this just makes it to use the last hop as an exit node.

New idee (I think): we can actually use this to mitigate DDoS attacks - block Tor access on the clearweb with a 302 Found redirect to our Onion address, add a tiny VM with enough allowed traffic as a Tor router & limit the bandwidth/amount of simultaneous requests from the Tor router to the main server.

You can promote oniin sites via header to torbrowser https://www.bleepingcomputer.com/news/software/tor-browser-95-lets-websites-promote-their-onion-addresses/

@momar That's a good idea but there's a complication: the Tor network will drop onion v2 support in October. Codeberg might be tempted to go onion v3 now, but Debian Stretch (oldstable) does not support onion v3 and yet Stretch's end of life is June 2022. So if Tor users are redirected to an onion v3 URL, this will be a dead-end for some users. I suggest redirecting to an onion v2 url up until the day Tor Project forces onion v3 on everyone (which Tor Project will do prematurely with reckless disregard).

After Tor project kills off onion v2, users of Debian Stretch would be blocked from Codeberg during the last 9 months of official Debian support. There are some workarounds but Codeberg has to decide whether it's a fair tradeoff to force some users to work out that they must manually install a recent version of Tor Browser and use no other browser during that time.

Privacy International used to redirect Tor users from clearnet to their onion site, but no longer. Might be interesting to find out why.

Privacy International used to redirect Tor users from clearnet to their onion site, but no longer. Might be interesting to find out why.

They switched to Onion-Location, which prompts the user or automatically redirects them to the onion site (depends on config). Source

Between oct. 2021 and june 2022, I'd say onion-location makes the most sense because the user is ultimately in control over whether the v3 onion is visited. Perhaps it would make sense to be able to quickly switch to @momar's approach during moments of attack, and perhaps permanently after june 2022 when it's less likely that a Tor user is onion v3 incapable.