Cloudflare breaks the HTML form for Tor users.

[EdOverflow]

Someone brought it to my attention that the form does not work for Tor users because of Cloudflare's WAF rules. We load the JavaScript files from Cloudflare's CDN which is causing trouble for some users. On top of that, the user experience on securitytxt.org for Tor users is severely impaired due to the Captchas they have to solve.

Some options:

• (If possible) Configure Cloudflare to be more lenient towards Tor users;
• Create a .onion fork of the securitytxt.org website.

I am open to other suggestions.

cc: @jamieweb might know more on this subject.

[jamieweb]

As far as I can see, the full securitytxt.org domain is fronted by Cloudflare, however the only file that I can see being loaded from the Cloudflare CDN is bulma.css.

There are a few things to try to increase the leniency towards Tor users:

• Enable Cloudflare's 'Onion Routing' which will cause legitimate Tor users' traffic to be routed through a Cloudflare Onion Service rather than a traditional exit node (at least after the first request). This works by issuing an Alt-Svc header to transparently redirect users away from the securitytxt.org domain on the real internet, instead taking them through one of Cloudflare's onion services.

• Add a Cloudflare firewall rule to reduce the security threshold for Tor users. In Cloudflare, Tor users are identified by the T1 country code, so you can add a rule that applies specifically to this, and it will target all known Tor exit nodes. Cloudflare updates the list of known exit nodes every 15 mins.

Hosting your own Hidden Service for the securitytxt.org site is also a great idea. You could use a tool such as mkp224o to brute-force a vanity URL, and then host the Hidden Service on a low-priced VPS or Raspberry Pi.

As securitytxt.org is a website where your anonymity as the site operator is probably not that important (as it has your real name all over it anyway), you could just use Apache/Nginx as a proxy to forward requests to the Hidden Service across the internet to the real securitytxt.org site. This way you don't actually have to host another copy of the site specifically for Tor users.

Hope this helps. :)

[EdOverflow]

Thank you, @jamieweb. I got this response from the original bug reporter via email:

Thanks, I'll be sure to follow the ticket's progress.

I do not have a GitHub account to contribute to the issue directly, but I read jamieweb's response:

Enable Cloudflare's 'Onion Routing' which will cause legitimate Tor users' traffic to be routed

Kind of loaded what "legitimate" means here in the case of Cloudflare, given their previous and current attitudes toward Tor.

This works by issuing an Alt-Svc header

Ignoring the above, there is still the issue of this not working across browsers. I do not use the Tor Browser at all; I use Firefox ESR and Privoxy currently, and I don't know if either will interpret and act upon that header correctly.

Hosting your own Hidden Service for the securitytxt.org site is also a great idea.

Probably the best idea in this case, can run on the same host even.

anonymity as the site operator is probably not that important[,] proxy [requests] across the internet to the real securitytxt.org site. This way you don't actually have to host another copy of the site specifically for Tor users.

I, uh... drawing a blank here. Tor daemon supports non-anonymous hidden services where the site operator can opt to have a zero-hop onion. Tor also points directly to the raw site endpoint, not sure what the need for additional indirection is here. Hell, if you have Tor on a different box for whatever reason (useful in LAN contexts especially) then you can point to a non-local IP address, nothing's stopping you.

(You have permission to reproduce this and my previous message in full or in part, by the way. I waive both copyright and any privacy niceties to my messages in this thread.)

[jamieweb]

Regarding the Alt-Svc header, the official Tor Browser does support this, and I would imagine that the vast majority of legitimate Tor users will be coming in using the official Tor Browser, rather than using a local torsocks proxy with a third-party application.

In regards to hosting your own Hidden Service, if you're running the Tor daemon on the same host as the website itself, you can safely forward traffic from Tor to 127.0.0.1:80 and it will work fine.

However, if the website and Tor daemon are running on different hosts, specifying a non-local IP address as the forwarding address for the Hidden Service will cause the traffic to be transmitted 'as-is'. As onion sites usually run using HTTP, this means that plaintext HTTP traffic would be transmitted over the internet or your local network, which of course isn't good. The only exception to this is if the protocol you're using has its own encryption/authentication built-in, e.g. SSH or HTTPS (the latter of which is unlikely for an onion site).

What I have described above is the reason for needing a local web server to use as a proxy, allowing for the traffic to be securely transmitted between the Tor daemon and remote web server. See my article here for more details including a demonstration with Wireshark captures: https://www.jamieweb.net/blog/forwarding-tor-hidden-services-to-another-server-across-the-internet/