Hello, listers!
Is it possible to configure on own physical server a https Web server (for ex., Apache) at port 443 and obfs4 or meek bridge at same static global IP address and same port 443?
It's something like SNI, not for two TLS web sites with different domain names at same IP but for web site on web server and TOR bridge. If this is possible it will be good masking for bridge because on others' requests this server will reply as simple https web server. As i understand, it will be difficult for observer without keys to distinguish encrypted bridge traffic from TLS-encrypted web traffic.
If this is possible, can anyone tell about configuration manual/hits for this?
WBR, Alan Hiew.
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.
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].
[1]: http://www.rutschle.net/tech/sslh.shtml [2]: https://github.com/yrutschle/sslh/blob/v1.18/example.cfg#L37-L47
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
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
On 16.08.2016 14:26, Alen Hiew wrote:
Is it possible to configure on own physical server a https Web server (for ex., Apache) at port 443 and obfs4 or meek bridge at same static global IP address and same port 443?
I've set up something like this for normal tor node (not obfs), see nginx site config details here: https://ghostbin.com/paste/9rnw9
The important thing is that you have a different advertise port (80 in my case) and listen port (9080) configured in your tor settings; and that your website can only be reached by domain name, not by typing in the IP address directly into the browser, but this shouldn't be a problem normally.
Note that in my case it is for dirPort and an exit node, not a bridge, so you probably have to tweak the settings. But the differentiation based on whether a dns hostname is requested (open website in browser) or not (Tor traffic) is working.
tor-relays@lists.torproject.org
-
Alen Hiew -
Green Dream -
JovianMallard -
Lucas Werkmeister -
simon