Opened 3 years ago
Last modified 2 years ago
#22572 new defect
please don't kill WarnUnsafeSocks option
Reported by: | starlight | Owned by: | |
---|---|---|---|
Priority: | Medium | Milestone: | Tor: unspecified |
Component: | Core Tor/Tor | Version: | Tor: 0.2.9.2-alpha |
Severity: | Normal | Keywords: | anti-deprecation tor-client needs-design regression? |
Cc: | Actual Points: | ||
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description
The message
The WarnUnsafeSocks option is deprecated, and will most likely be removed in a future version of Tor. Changing this option makes it easier for you to accidentally lose your anonymity by leaking DNS information (If you think this is a mistake, please let us know!)
now appears when starting tor since a version upgrade.
I am a expert user of Tor and have several script that issue torsocks dig +tcp
commands performing forward and reverse DNS queries. Have set WarnUnsafeSocks
to 0 to eliminate the spamming of my logs with warnings about explicit IP addresses passing through SOCKS.
The option is useful and should be retained.
Child Tickets
Change History (14)
comment:1 Changed 3 years ago by
Component: | - Select a component → Core Tor/Tor |
---|---|
Version: | → Tor: unspecified |
comment:2 Changed 3 years ago by
Version: | Tor: unspecified → Tor: 0.2.9.2-alpha |
---|
comment:3 Changed 3 years ago by
Looking at the code (see buffers.c:1325) the warning is only given if the SafeSocks
option is enabled. According to the manual SafeSocks
is disabled by default.
So unless the default is changed there should be no warnings.
comment:5 Changed 3 years ago by
Status: | new → needs_information |
---|
Replying to starlight:
Ok, thank for for explaining!
Does removing the WarnUnsafeSocks
option from your configuration fix the issue?
comment:6 Changed 3 years ago by
Resolution: | → not a bug |
---|---|
Status: | needs_information → closed |
Yes, works ok. Set WarnUnsafeSocks=1
via control channel in the client daemon, verified that it took and then ran the script that analyzes an IP address via several forward and reverse DNS queries using torsocks dig +tcp
commands. No complaints in the log. Version 0.2.9.11.
Thank you.
comment:7 follow-up: 8 Changed 2 years ago by
Not so fast! It's been awhile since this was a bother and I forgot that the log spamming occurs on an control channel event monitoring stream. With WarnUnsafeSocks=1
this log is still flooding with pointless messages when DNS queries are purposefully sent over a Tor connection. I have restored WarnUnsafeSocks=0
and my position remains that the setting is useful at least up to and including 0.2.9.x. I have not tested 0.3.0.x versions.
comment:8 Changed 2 years ago by
Resolution: | not a bug |
---|---|
Status: | closed → reopened |
Replying to starlight:
Not so fast! It's been awhile since this was a bother and I forgot that the log spamming occurs on an control channel event monitoring stream. With
WarnUnsafeSocks=1
this log is still flooding with pointless messages when DNS queries are purposefully sent over a Tor connection. I have restoredWarnUnsafeSocks=0
and my position remains that the setting is useful at least up to and including 0.2.9.x. I have not tested 0.3.0.x versions.
The code referred to in comment:3 sends out the controller message no matter the value of SafeSocks
. I'm assuming this is to prevent configuration options from hiding events from the controllers.
Because this is now about the controller message it sounds like a duplicate of #22461. Can you check if your issue is a duplicate of #22461? If it's not a duplicate, can you give some more information about your setup in order to reproduce the issue?
comment:9 Changed 2 years ago by
Seems to me the issues are related, but a difference exists. Bug #22461 talks about making SOCKS5 requests of a naked IP address. In this case I sometimes direct DNS requests to Google DNS.
Here DNS payloads are traversing SOCKS which contain naked IP addresses, and apparently it does not matter if the DNS server is specified via IP address or DNS name.
For example
$ torsocks dig +tcp +short @google-public-dns-a.google.com google-public-dns-b.google.com 8.8.4.4
still produces
650 STATUS_CLIENT WARN DANGEROUS_SOCKS PROTOCOL=SOCKS5 ADDRESS=8.8.8.8:53
If one submits the request in more usual fashion
$ torsocks dig +tcp +short @8.8.8.8 -x 8.8.4.4 google-public-dns-b.google.com.
the result is one 650 warning, not two.
with WarnUnsafeSocks=0
no 650 warnings appear.
comment:10 Changed 2 years ago by
Status: | reopened → new |
---|
comment:12 Changed 2 years ago by
Keywords: | anti-deprecation tor-client needs-design added |
---|
comment:13 Changed 2 years ago by
Keywords: | regression? added |
---|
comment:14 Changed 2 years ago by
The motivation for removing the option (to prevent people from harming themselves inadvertently) is evident and sensible. For me it would work if a prefix to the socks isolation username or password acted as a flag to suppress the warning. Perhaps "UNSAFE" or similar blatant indication. The purpose of the script where this happens is issuing arbitrary DNS queries anonymously--no chance I will accidently request my own addresses unintentionally.
Or, don't worry about it. I prefer logs clear of distracting noise (so I don't miss important messages) and have demoted several daemon messages to info or debug level in my builds. I can hack this one as well. But spam is spam and it invariable harms the signal-to-noise ratio on any channel.
This is related to #19820 where the option was deprecated and #22060 where the option was removed.