Putting onion services behind a third-party TCP proxy
Hi all, When deploying an onion service, I noticed some problem that the ip address of my machine that runs tor daemon is exposed to the Tor network which is vulnerable to the DDoS attack if someone knows my ip address. So I'm thinking putting the tor daemon behind some third party TCP proxy that will protect me from this kind of DDoS attack. What do you think if I want to implement a feature that forward all the onion service traffic to the TCP proxy before going to the Tor network? The protocol that I'm thinking is TCP Proxy Protocol [1] [1] https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
Hi,
On 15 Aug 2019, at 05:10, Pop Chunhapanya <pop@cloudflare.com> wrote:
When deploying an onion service, I noticed some problem that the ip address of my machine that runs tor daemon is exposed to the Tor network which is vulnerable to the DDoS attack if someone knows my ip address.
You can reject all inbound connections to your onion service using a simple firewall rule. Onion services are tor clients: they only make outbound connections.
So I'm thinking putting the tor daemon behind some third party TCP proxy that will protect me from this kind of DDoS attack.
What do you think if I want to implement a feature that forward all the onion service traffic to the TCP proxy before going to the Tor network?
The protocol that I'm thinking is TCP Proxy Protocol [1]
[1] https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
You could try the existing HTTPSProxy torrc option? HTTPSProxy host[:port] Tor will make all its OR (SSL) connections through this host:port (or host:443 if port is not specified), via HTTP CONNECT rather than connecting directly to servers. You may want to set FascistFirewall to restrict the set of ports you might try to connect to, if your HTTPS proxy only allows connecting to certain ports. Tor also allows an intelligent firewall to filter circuits using a field in haproxy protocol format, see HiddenServiceExportCircuitID for details. But you probably won't need this advanced feature. T
So I'm thinking putting the tor daemon behind some third party TCP proxy that will protect me from this kind of DDoS attack.
What do you think if I want to implement a feature that forward all the onion service traffic to the TCP proxy before going to the Tor network?
The protocol that I'm thinking is TCP Proxy Protocol [1]
[1] https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
You could try the existing HTTPSProxy torrc option?
*HTTPSProxy* host[:port]
Tor will make all its OR (SSL) connections through this host:port (or host:443 if port is not specified), via HTTP CONNECT rather than connecting directly to servers. You may want to set *FascistFirewall* to restrict the set of ports you might try to connect to, if your HTTPS proxy only allows connecting to certain ports.
Tor also allows an intelligent firewall to filter circuits using a field in haproxy protocol format, see *HiddenServiceExportCircuitID* for details. But you probably won't need this advanced feature.
I feel that HTTPSProxy is too expensive. As far as I know, it needs to do (1) tcp handshake, (2) tls handshake, and (3) http connect. If I can use haproxy, it would be just one tcp handshake. Could I propose another option for haproxy? I can do it myself. You just review and merge :) Haxxpop
Hi Haxxpop,
On 15 Aug 2019, at 16:53, Pop Chunhapanya <pop@cloudflare.com> wrote:
So I'm thinking putting the tor daemon behind some third party TCP proxy that will protect me from this kind of DDoS attack.
What do you think if I want to implement a feature that forward all the onion service traffic to the TCP proxy before going to the Tor network?
The protocol that I'm thinking is TCP Proxy Protocol [1]
[1] https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
You could try the existing HTTPSProxy torrc option?
HTTPSProxy host[:port] Tor will make all its OR (SSL) connections through this host:port (or host:443 if port is not specified), via HTTP CONNECT rather than connecting directly to servers. You may want to set FascistFirewall to restrict the set of ports you might try to connect to, if your HTTPS proxy only allows connecting to certain ports.
Tor also allows an intelligent firewall to filter circuits using a field in haproxy protocol format, see HiddenServiceExportCircuitID for details. But you probably won't need this advanced feature.
I feel that HTTPSProxy is too expensive. As far as I know, it needs to do (1) tcp handshake, (2) tls handshake, and (3) http connect. If I can use haproxy, it would be just one tcp handshake.
Could I propose another option for haproxy? I can do it myself. You just review and merge :)
Sure, I suggest you use this torrc option format: TCPProxy protocol host:port Tor will use the given protocol to make all its OR (SSL) connections through a TCP proxy on host:port, rather than connecting directly to servers. You may want to set FascistFirewall to restrict the set of ports you might try to connect to, if your proxy only allows connecting to certain ports. There is no equivalent option for directory connections, because all Tor client versions that support this option download directory documents via OR connections. The only protocol supported right now 'haproxy'. This option is only for clients. (Default: none) The haproxy protocol works in the following way: when the feature is enabled, the Tor process will write a header line on every outbound connection. The header is in the following format: "PROXY" [ "TCP4" | "TCP6" ] SourceIPAddress DestinationIPAddress SourcePort DestinationPort "\r\n" There is a single space after each item, except for the last item, which is followed by a CRLF. After parsing a correctly-formatted PROXY line, the haproxy connects to DestinationIPAddress:DestinationPort, and forwards all subsequent data to the destination. Any data sent by the destination is forwarded by haproxy to the Tor client. The HAProxy version 1 proxy protocol is described in detail at https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt I don't think you'll need to implement a TCPProxyAuthenticator option. T
On 16 Aug 2019, at 04:52, Pop Chunhapanya <pop@cloudflare.com> wrote:
Hi Tim,
The only protocol supported right now 'haproxy'. This option is only for clients. (Default: none)
I think TCPProxy option is more generic than HTTPSProxy, Socks4Proxy and Socks5Proxy. Why don't we also allow https, socks4, and socks5 instead of just haproxy?
That's possible, but it's not required as part of the patch. If we wanted a fully generic option, we should probably call it something like ORConnectionProxy or OutboundORProxy. I'd like to see what Nick thinks when he's back next week. T
Hi Tim,
TCPProxy protocol host:port
Tor will use the given protocol to make all its OR (SSL) connections through a TCP proxy on host:port, rather than connecting directly to servers. You may want to set FascistFirewall to restrict the set of ports you might try to connect to, if your proxy only allows connecting to certain ports. There is no equivalent option for directory connections, because all Tor client versions that support this option download directory documents via OR connections.
The only protocol supported right now 'haproxy'. This option is only for clients. (Default: none)
The other point that I want to make is that haproxy has 2 versions. I think it's better to also put the version number in the protocol name like 'haproxy1'. However I saw you already used 'haproxy' in the HiddenServiceExportCircuitID option. Best, haxxpop
On 20 Aug 2019, at 13:31, Pop Chunhapanya <pop@cloudflare.com> wrote:
Hi Tim,
TCPProxy protocol host:port
Tor will use the given protocol to make all its OR (SSL) connections through a TCP proxy on host:port, rather than connecting directly to servers. You may want to set FascistFirewall to restrict the set of ports you might try to connect to, if your proxy only allows connecting to certain ports. There is no equivalent option for directory connections, because all Tor client versions that support this option download directory documents via OR connections.
The only protocol supported right now 'haproxy'. This option is only for clients. (Default: none)
The other point that I want to make is that haproxy has 2 versions. I think it's better to also put the version number in the protocol name like 'haproxy1'. However I saw you already used 'haproxy' in the HiddenServiceExportCircuitID option.
I would be happy with "haproxy" and "haproxy2". But minimal patches are good - let's not implement features that no-one is using. T
On Wed, 14 Aug 2019, Pop Chunhapanya wrote:
I feel that HTTPSProxy is too expensive. As far as I know, it needs to do (1) tcp handshake, (2) tls handshake, and (3) http connect. If I can use haproxy, it would be just one tcp handshake.
AIUI, there wouldn't be a (2). -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `- https://www.debian.org/
On 8/14/19, Pop Chunhapanya <pop@cloudflare.com> wrote:
When deploying an onion service ... the ip address of my machine ... is exposed to the Tor network... DDoS ... if someone knows my ip address.
Only your tor client, and your guard, knows your ip. Unless you're up against a malicious guard, that's not a problem, and if you are, firewalling doesn't help anything there because you can't prevent a real "DDoS" or any other modulation from partitioning or otherwise giving away your onion. Tor cannot defend against that class of attack. Note that in a proper "onion only" configuration, a box should have no inbound ports open. There is something confusing with your wording. If these replies don't help, please rephrase your question. And or sanitize and post your torrc config and invocation commandline.
participants (4)
-
grarpamp -
Peter Palfrader -
Pop Chunhapanya -
teor