Should make websocket url sub path configurable

[jimmygc]

The current subpath of cloak is hardcoded as "/", but this should be configurable to make it possible to proxy cloak flows under a subpath of nginx server.

[beanslel]

I've been thinking about this as well, but I wonder how useful it would be? To the outside world, Cloak already looks like a regular web server. So whether you have Cloak reverse proxy to an nginx server, or you hide Cloak behind the nginx server on a custom path, there shouldn't really be a difference because in both cases an external observer will only see the nginx server, right?

I suppose there is a difference in the IP. If you put Cloak behind nginx, your redirection domain name can point to the same IP as the Cloak server, which might help in reducing detection. But then again, since you're probably going to be hiding Cloak behind a low-traffic personal or fake website, I don't know effective this would be.

EDIT: About the IP thing: on second thought, you could just have Cloak redirect to nginx on the same machine, then your IPs are also the same and it would essentially accomplish the same thing as a custom path.

[alexander-potemkin]

Use case that I can see is a DPI systems, that follow the original client's call and if they don't see proper web server, they block an access.

For example:

• Client make a call to the Server:443
• DPI follow this call to the Server:443

If what DPI founds is not a regular web site (and I assume human check could be used as well), than an access is blocked.

Since HTTP Header fields are SSL protected, this could be another way to put apart client and DPI/censors, for example:

• Client make a call to the Server:443, which is handled by nginx
• nginx verify - if there is a special - secret field with some specific numbers on it - could be some random string pre-shared on both server & client - then this request goes to cloak
• if not - it's a DPI or a human-censor - it's redirected to some home page and nginx serve all those requests by itself, working as a regular web server

Possibly it could be implemented right now already by some other way, @beanslel ?