If a pluggable transport is HTTP(S)-ish, I would expect nginx to be able to use SNI or a Host header (or the lack) to decide whether to serve web content or proxy to tor or the transport. I'm not sure if nginx can decide to proxy tcp based on SNI, but it would be worth reading the docs.
If this is nonsense, pardon my ignorance of tor details ;)
On 08/16/2016 01:59 PM, Lucas Werkmeister wrote:
Something like this exists: sslh[1], a "protocol demultiplexer". However, it doesn't explicitly support Tor, and I'm not sure if it's possible to distinguish between Tor packets and other TLS traffic using the options it offers[2].
On 16.08.2016 19:50, Green Dream wrote:
I don't think you will be able to bind two daemons to the same TCP port (443).
Maybe you could have something else listening on TCP port 443 and passing the requests onto both places?
You might be able to put a single reverse proxy in front on that port, and have that proxy send the requests to the correct daemon on the backend, but I have no idea how to actually set that up. Most common reverse proxy software (like nginx) isn't designed to understand or handle Tor or pluggable transports like obfs4.
There may be some application aware ("layer 4") firewalls that could do something like this too, but I don't think it would be straightforward. Also I'm not sure inspecting Tor packets (in order to determine they're Tor packets) is a good idea... or if that could even work since the packets will be obfuscated.
Just thinking out loud... but this seems like a difficult to implement idea.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays