Ran a small onion site for a couple years and the nice part is you never touch a public IP or a cert. Downside is onion v3 addresses are impossible to share verbally and the latency makes anything chatty feel broken. Static pages only, honestly.
Nice thing is you skip port forwarding entirely, which matters a lot if your ISP has you behind CGNAT. Curious how people handle uptime though, since a hidden service going down isn't something you notice until someone tells you.
Besides accessing your page are random people able to use your server as an exit node? Am I thinking the right thing... I met someone in Switzerland that was hosting anonymous exit nodes to some anonymous network and he said that it was a pain having to explain what was happening to the police.
Exit node are an entirely optional part of the Tor network. If you run a relay or a hidden service you are not forced to participate in the exit node side of things. It's also not recommended to combine these roles because it could have security implications for your hidden service.
Imagine if normal people could install a single normal application and just run a website from a folder. CLI makes it more difficult than hosting a normal website. Typing commands you don't understand doesn't seem all that of a great idea.
Besides using a separate port, I would also suggest running the hidden service on a non-127.0.0.1 bind address, just in case you ever host something else on that port and forget to disable the hidden service:
HiddenServicePort 80 127.13.37.1:8080
listen 127.13.37.1:8080;
This way, strangers won't be able to connect to a service bound to 127.0.0.1, should you ever decide to re-use the port and forget to disable the hidden service.
You'll also need to use separate ports and/or bind addresses if you host multiple hidden services and don't want people to correlate them - if nginx doesn't match the Host header, it will serve whichever site comes first alphabetically.
My open source project (https://github.com/du82/nonograph) spawns a Tor hidden service with Onion-Location advertising by default, and on the Docker container its always on and self-healing
1. If you want to improve page load speed you need to buy a HTTPS certificate so you are not limited to HTTP/1.1. Multiplexing in HTTP/2 is important for getting sites to load fast.
2. You can set the HiddenServiceExportCircuitID configuration to pass the circuit id to your web server for telemetry or anti abuse purposes. Otherwise your logs will say that all users are coming from the same IP.
Fascinating, onion services are always encrypted by the tor network but still tunnel "cleartext" http inside that, and there are no CAs that issue free of charge certificates for .onion domains, and therefore there's no free of charge way to get http/2 on onion services without self signing.
Which raises the question: why not just trust self-signed certificates on onion services? From my brief look it seems to be because the Tor project views the primary purposes of HTTPS on onion services to be other things rather than just http/2 support: http/2 isn't even mentioned on their page about https for onion services (https://community.torproject.org/onion-services/advanced/htt...). Unfortunate.
I personally would support automatically trusting self signed https certs since their key is typically secured under the same safety as the hidden service's key. And even when they are not the browser has no warning when you get downgraded to HTTP on an onion compared to a regular site.
Trying to push hidden services to stay on HTTP is going against what the rest of the web is doing and as a minority of web traffic it really should be aligned to the rest of the web and also require HTTPS. Yes, it's technically wasteful, but reduces both work and security risk by keeping security models aligned with the rest of the web.
What I really love about Onion sites is that if they are big enough, performance engineering really becomes Tor-specific. A few examples:
- Making assets embedded as base64 (img src the header logo as base64, all CSS should be inline, etc.).
- Leveraging CSS as much as possible (if you use animations and transitions, use CSS as much as possible for these, avoid JS for them).
- Make sure your website is mostly rendered on the backend. If you're to have JS, your website should work without it.
- Security becomes REALLY fun, as in, avoid XSS, CSRF, SQL Injection attacks and any other injections as much as possible.
As someone summarizes in another comment[0], keep the chattiness as minimal as possible. By chattiness I understand they mean, pack as much data as you can in the same Keep-Alive connection. Avoid making new HTTP requests as much as possible, as each one might get assigned to a new Onion route making things slow.
If you can ship your website to the browser in a single connection, you've won.
I've always been impressed by performance of these big Onion sites, they really push the limits of software engineering creativity, given these constraints and nature of Tor.
The one thing I learned from hosting superkuhbitj6tul.onion (from a home computer) for ham radio and science stuff for about a decade was that EVERYTHING ON A .ONION IS EPHEMERAL. When the tor project correctly decided that for high security torv2 no longer was anonymous enough they unilaterally wiped out every torv2 .onion site that existed. Every link that was made between these sites came to an end in 2021 when they released a tor client without support for torv2 onions and tore the web to pieces.
Know this: the "dark web" is not for people who just want to own your domain name. It's for SECURITY and that use case is going to drive all their decisions. And if it wipes out every community in the entire tor dark web? So be it. And they'll do it again. Don't build your communities on the sand that is the dark web. You won't like the result.
Thanks for sharing! Happy to get feedback :)
Ran a small onion site for a couple years and the nice part is you never touch a public IP or a cert. Downside is onion v3 addresses are impossible to share verbally and the latency makes anything chatty feel broken. Static pages only, honestly.
You have to keep chattiness low, but a lot of SSR stuff works fine. Dread uses SSR, and even nags you if you have JavaScript enabled.
Nice thing is you skip port forwarding entirely, which matters a lot if your ISP has you behind CGNAT. Curious how people handle uptime though, since a hidden service going down isn't something you notice until someone tells you.
Agreed yeah. Mine has been up with no issues so far for ~half a year.
(There are solutions for CGNAT - https://david.alvarezrosa.com/posts/self-hosting-behind-cgna...)
What is the benefit of building the same website twice with different hostnames instead of using relative links to content on the same domain?
Fair point. Very small things like RSS, canonical link or og:url or microformats use absolute URL
To make sure once in the .onion, you never leave the .onion
Besides accessing your page are random people able to use your server as an exit node? Am I thinking the right thing... I met someone in Switzerland that was hosting anonymous exit nodes to some anonymous network and he said that it was a pain having to explain what was happening to the police.
That'd be an exit relay, not doing that atm, just in case
Running a Tor exit node is a manual process. Running a hidden service like a website, or chat server doesn't involve anything like that.
No
Exit node are an entirely optional part of the Tor network. If you run a relay or a hidden service you are not forced to participate in the exit node side of things. It's also not recommended to combine these roles because it could have security implications for your hidden service.
You probably want to add the Onion-Location header to the clearnet site so Tor Browser can automatically inform the visitor about it: https://community.torproject.org/onion-services/advanced/oni...
Good call, I'd missed that. Adding it now, thanks.
Done now https://github.com/david-alvarez-rosa/homelab/commit/b495cbe...
Good thought
Imagine if normal people could install a single normal application and just run a website from a folder. CLI makes it more difficult than hosting a normal website. Typing commands you don't understand doesn't seem all that of a great idea.
If you don't understand what a command does, go learn it.
For us that's fine. It's quite a hill to climb for non technical folks. Even AIs holding their hand will have to do a lot of explaining.
Besides using a separate port, I would also suggest running the hidden service on a non-127.0.0.1 bind address, just in case you ever host something else on that port and forget to disable the hidden service:
This way, strangers won't be able to connect to a service bound to 127.0.0.1, should you ever decide to re-use the port and forget to disable the hidden service.
You'll also need to use separate ports and/or bind addresses if you host multiple hidden services and don't want people to correlate them - if nginx doesn't match the Host header, it will serve whichever site comes first alphabetically.
It's also possible to use a Unix socket, which can have a descriptive pathname like /var/run/my-service.sock: https://stackoverflow.com/questions/69313114/using-nginx-to-...
My open source project (https://github.com/du82/nonograph) spawns a Tor hidden service with Onion-Location advertising by default, and on the Docker container its always on and self-healing
A few more tips.
1. If you want to improve page load speed you need to buy a HTTPS certificate so you are not limited to HTTP/1.1. Multiplexing in HTTP/2 is important for getting sites to load fast.
2. You can set the HiddenServiceExportCircuitID configuration to pass the circuit id to your web server for telemetry or anti abuse purposes. Otherwise your logs will say that all users are coming from the same IP.
https://blog.cloudflare.com/cloudflare-onion-service
Fascinating, onion services are always encrypted by the tor network but still tunnel "cleartext" http inside that, and there are no CAs that issue free of charge certificates for .onion domains, and therefore there's no free of charge way to get http/2 on onion services without self signing.
Which raises the question: why not just trust self-signed certificates on onion services? From my brief look it seems to be because the Tor project views the primary purposes of HTTPS on onion services to be other things rather than just http/2 support: http/2 isn't even mentioned on their page about https for onion services (https://community.torproject.org/onion-services/advanced/htt...). Unfortunate.
I personally would support automatically trusting self signed https certs since their key is typically secured under the same safety as the hidden service's key. And even when they are not the browser has no warning when you get downgraded to HTTP on an onion compared to a regular site.
Trying to push hidden services to stay on HTTP is going against what the rest of the web is doing and as a minority of web traffic it really should be aligned to the rest of the web and also require HTTPS. Yes, it's technically wasteful, but reduces both work and security risk by keeping security models aligned with the rest of the web.
Can you buy one of these in XMR?
Not directly.
What I really love about Onion sites is that if they are big enough, performance engineering really becomes Tor-specific. A few examples:
- Making assets embedded as base64 (img src the header logo as base64, all CSS should be inline, etc.).
- Leveraging CSS as much as possible (if you use animations and transitions, use CSS as much as possible for these, avoid JS for them).
- Make sure your website is mostly rendered on the backend. If you're to have JS, your website should work without it.
- Security becomes REALLY fun, as in, avoid XSS, CSRF, SQL Injection attacks and any other injections as much as possible.
As someone summarizes in another comment[0], keep the chattiness as minimal as possible. By chattiness I understand they mean, pack as much data as you can in the same Keep-Alive connection. Avoid making new HTTP requests as much as possible, as each one might get assigned to a new Onion route making things slow.
If you can ship your website to the browser in a single connection, you've won.
I've always been impressed by performance of these big Onion sites, they really push the limits of software engineering creativity, given these constraints and nature of Tor.
--
[0]: https://news.ycombinator.com/item?id=49872320
EDIT: Formatting of bullet points.
Are these simply good ideas regardless of tor?
With CDNs of today, they are not so much relevant for the clearnet.
The one thing I learned from hosting superkuhbitj6tul.onion (from a home computer) for ham radio and science stuff for about a decade was that EVERYTHING ON A .ONION IS EPHEMERAL. When the tor project correctly decided that for high security torv2 no longer was anonymous enough they unilaterally wiped out every torv2 .onion site that existed. Every link that was made between these sites came to an end in 2021 when they released a tor client without support for torv2 onions and tore the web to pieces.
Know this: the "dark web" is not for people who just want to own your domain name. It's for SECURITY and that use case is going to drive all their decisions. And if it wipes out every community in the entire tor dark web? So be it. And they'll do it again. Don't build your communities on the sand that is the dark web. You won't like the result.