Currently we are generating a random string aka “secret path” for the URI we are using the WebTunnel behind. But wouldn’t it be better to mask the WebTunnel behind some existing URI?
For example if someone has a website with the following URIs reachable through HTTP
and the WebTunnel would be hidden somewhere in the middle
https://www.someshop.com/products/toys/
it would be less noticeable, I think.
Also currently if you open the URI from the bridge line in an ordinary browser, you get an 502 Bad Gateway HTTP response code and the corresponding error page displayed.
When hidden behind an existing URI, the ordinary page would show up when opened via HTTP and a WebTunnel bridge connection would be established when used in the bridge line.
That would require some additional server configuration, but that’s another topic…
Assuming that by modifying the Torrc file and the Web Server, the SecretPath can be hidden in the middle of two paths of the URL as you indicate, what improvement is there?
Supposedly no one knows that SecretPath, what % probability is there that they know the exact path?
If they know it, it doesn’t matter if it is at the root of the domain or two levels ahead.
If they know it, they will block the URLs as they do in countries like Russia.
If you have a website and the main URL serves content, even if it is a blog explaining nonsense, there is no way for them to know the PATH to see the 502 Bad Gateway from Nginx or the 500 from Apache.
They will only see a 404 not found as if you write a thousand different things after the domain /
In my opinion I don’t see any improvement or additional protection from doing it this way and it will complicate the configuration.
If a hypothetical case is that they do Brute Force to find out the Path that is practically impossible due to the length and characters, similar to someone who wants to crack a password and if they try, defenses such as Fail2ban can be implemented and block 1 week after 10 attempts and receive a 404 for example, which is the error when that path does not exist in the URL.
If they know the exact one it is because your bridge has been exposed.
That is my opinion, always respecting your initiative but I am still interested in discussing the topic if more people want to contribute their point of view or if you want to refute my argument.
Wasn’t it advertised in the blog post that the URI was supposed to be reachable?
In fact, WebTunnel is so similar to ordinary web traffic that it can coexist with a website on the same network endpoint, meaning the same domain, IP address, and port. This coexistence allows a standard traffic reverse proxy to forward both ordinary web traffic and WebTunnel to their respective application servers. As a result, when someone attempts to visit the website at the shared network address, they will simply perceive the content of that website address and won’t notice the existence of a secret bridge (WebTunnel).
Ok so from this it seems that you need to configure the server to do that, like you said.
Agree with your thoughts, url for the bridgeline and also a page that appears if the url is used from a browser. Unsure of technicalities . Im not sure if the tunnel bridge server componet of the operation would need looking into a change. Is there a reason to there being a secret string or could it be a url? Definitely if theres no good reason to the string than a webpage or folder url. So the result would have a dual purpose, a proxy address and a webpage, I would think you could add into the apache config for it to redirect to home if it’s accesed via 443 and to the proxy for 15000
We are talking about two different protocols http|websocket.
Websocket is still an application, so it will always depend on the Webserver. You cannot present a web page from a Websocket application and webtunnel uses port 443 with proxypass for this reason, because you upgrade a connection to websocket.
It makes no sense and nothing can be done by modifying the frontend that would be the Webserver.
The big problem with the bridges is that a censor can request the bridge lines like a regular user can do it. And in the bridge line there is all information needed for being able to block the bridge. Specifically for the WebTunnel bridge it would be better to have a dynamic IP address. So the domain wouldn’t change in the bridge line, but the IP address behind it would.
Any ideas related to this?
The server-side config is not a big deal here. If the upgrade to the websocket doesn’t happen (which is the case when you get a 502 response), you are still on HTTP and the webserver can catch the error and instead of forwarding the error to the client (browser) it would serve its regular page.
Could you cloudflare the domain to obtain contact to the transfer the cliebt to the webtunnel. contact made via cloudflare then client transfered to the static IP of the webtunnel
Yes, it can be done very easily with a RewriteRule. But then, when they find the “supposed” Path that is impossible without brute force and that there are mechanisms to mitigate that, when they present the Regular Page but with another Path they see a 404 for example? What difference is there or improvement?
URLs cannot be blocked, because there is no such thing in TCP/IP.
URLs can be available on a higher level protocol, but since higher level protocols are TLS encrypted nowadays, no way for a censor to obtain the HTTP request line.
What can be blocked is the IP address.
I will test the following approach now:
Dynamic DNS combined with distributed proxies a la snowflake.
To give another example, you have a CDN with x IP, if the IP is blocked all the domains behind it stop working (many domains from different people are behind the same IP on a CDN.
When traffic is TLS encrypted, “the man in the middle” won’t even get to know, whether TCP/IP is carrying an HTTP request/response there or something else.
Even because it’s encrypted…
WAF is useless when traffic is encrypted.
The path of the URL is in the HTTP header, which is also encrypted, so no chance to block a path.
Currently it’s possible to block a domain name, because the DNS requests are mostly still unencrypted.
But there are already solutions on the way like “DNS over TLS” and “DNS over HTTPS”, which make blocking a domain impossible.
So the only useful information you can get for being able to block traffic is the IP address and the port number which are located in the TCP/IP packets and are unencrypted.
Yes, but here the IP address is being blocked, not the domain name. And it’s rather the IP address behind a domain name, not the other way around. DNS requests for the domain are still possible, but although you can get the IP address of the CDN, the IP address is not accessible for communication.
This is supposed to be solved by ECH, which Cloudflare enabled in it’s network initially, but had to drop it due to some problems.
You can read more about ECH from Mozilla and specially Cloudflare. Same for SNI.
And this is not theoretical, SNI is widely used to block access by major providers, even in countries where freedom is guaranteed. As an example, many ISP in Spain block access to many websites that serve illegal content by court order.
