please don't kill WarnUnsafeSocks option

[starlight]

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.

[cypherpunks]

This is related to #19820 where the option was deprecated and #22060 where the option was removed.

[cypherpunks]

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.

[starlight]

Ok, thank for for explaining!

[cypherpunks]

Replying to starlight:

Ok, thank for for explaining!

Does removing the WarnUnsafeSocks option from your configuration fix the issue?

[starlight]

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.

[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 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.

[cypherpunks]

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 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.

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?

[starlight]

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.

[cypherpunks]

#22461 was merged to master so I've tried to reproduce your issue on the master branch and I'm able to reproduce it. I did find however that issue in #22461 was also reproducible so let's see what happens when it is actually fixed properly.

[dgoulet]

Missing milestone.

[starlight]

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.