Opened 2 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 2 years ago by starlight

Component: - Select a componentCore Tor/Tor
Version: Tor: unspecified

comment:2 Changed 2 years ago by cypherpunks

Version: Tor: unspecifiedTor: 0.2.9.2-alpha

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

comment:3 Changed 2 years ago by 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.

comment:4 Changed 2 years ago by starlight

Ok, thank for for explaining!

comment:5 in reply to:  4 Changed 2 years ago by cypherpunks

Status: newneeds_information

Replying to starlight:

Ok, thank for for explaining!

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

comment:6 Changed 2 years ago by starlight

Resolution: not a bug
Status: needs_informationclosed

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 Changed 2 years ago by 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.

comment:8 in reply to:  7 Changed 2 years ago by cypherpunks

Resolution: not a bug
Status: closedreopened

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?

comment:9 Changed 2 years ago by 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.

comment:10 Changed 2 years ago by cypherpunks

Status: reopenednew

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

comment:11 Changed 2 years ago by dgoulet

Milestone: Tor: unspecified

Missing milestone.

comment:12 Changed 2 years ago by nickm

Keywords: anti-deprecation tor-client needs-design added

comment:13 Changed 2 years ago by nickm

Keywords: regression? added

comment:14 Changed 2 years ago by 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.

Note: See TracTickets for help on using tickets.