This site is now reachable over Tor as a hidden service, at a .onion address that resolves only inside the Tor network. Tor relays and encrypts your traffic as …
117 comments
- 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.
There's also a problem of site fronting. Anyone could run a proxy pretending to be you, for arbitrary reasons (not even necessarily the obvious forging and credential stealing). Every site, even a personal blog, has dozens of parasitic fronts, either actively malicious or dormant. You need off-site ways to tell users what is the real address, and provide a smoke test for them (often a part of the address as a picture, for example in a captcha).
>avoid JS for them
Using any JS defies the point and makes your site instantly suspicious.
How can you do this without relying on the normal web? Let’s say you use a normal website to show the onion link, if the website gets taken down, you lost your user-trusted mean to do that.
I thought the whole point of Tor is that I (and only I) am able to serve traffic at a .onion URL that I have generated. How could someone else get in front of that?
Relyinging the least possible on js, and using CSS for animations sounds like good engineering to me
I wrote about it in 2600 almost ten years ago (already?!). A copy of my article can be found here: https://pablorauzy.fr/outreach/2600/how-to-run-a-tor-hidden-...
If you have an Onion copy of your website, don't forget the Onion-Location http header which will automatically redirect Tor Browser users to the onion version of the website even if they visit it at the clear web address.
If it interests people, I also have a follow up article about I2P: https://pablorauzy.fr/outreach/2600/how-to-run-an-i2p-hidden...
http://pablo2httpff4vogufavlmbxw4jkgb3amnywex2xdnchpztkdu2lu...
And for the OP's site
onion-location:
http://dhevt6e4rtgbtr3jh53xrpwmgtilkah6nyjujocsspssrsexc7omx...
Question: Can the .onion sites withstand HN front page traffic
I really believe the single threaded BusyBox httpd running on a low end mini PC in my bedroom will stand hosting my static web site without any trouble.
NB. The question poses a hypothetical. No one is suggesting that HN allows stories (submissions) with .onion URLs or that .onion URLs would receive the same amount of traffic as "clearnet" ones
For example, a NYT article using an .onion URL rather than a "clearnet" URL
> 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.
You can monkey-patch scripts around Tor service activation, but I haven't been able to get my Tor+nginx setup to work reliably after updates/service restarts when using unix sockets.
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.
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.
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.
Read the full thread on Hacker News →
Related stories
- Hacker News · 5 points · 8 days ago
- Hacker News · 2 points · 9 days ago
- Self-Hosting Behind Cgnatdavid.alvarezrosa.comHacker News · 4 points · 9 days ago
- Self-Hosting Behind Cgnat – Be Libredavid.alvarezrosa.comHacker News · 5 points · 10 days ago
- Self-Hosting Behind CGNATdavid.alvarezrosa.comLobsters · 60 points · 9 days ago
- The Tension Between Self-Hosting, Ownership, and Corporate Brandingcommunity.vikunja.ioHacker News · 1 points · 5 days ago